Coding well with others or being a team player is at the heart of
everything. We do as a unless you're coding
yourself for a piece of software that only you're going to use
your not a solo developer right now.
We share. Cody, get how we share it with
everyone even if nobody's following even if nobody's
interested, right off the bat on something, we're doing Google's
their index and everything. I mean our coats on it, find out
eventually. Even if we don't want to we may
get fever. Feedback week, my get people
fucking a code and using it. So we need to understand what it
means to be part of that Community.
Even if you don't want to and code in a way that helps,
everyone, it's not just about ironic or any works for me, and
that's it. Hey everyone.
My name is Henry Surya Barragan. And you're listening to the
tekhelet Juno, the show will be bringing you the greatest
technical leaders practitioners and thought leaders in the
industry to discuss about their Journey ideas and practices that
we all can learn and apply to build a highly performing
technical team and to make an impact in your personal work.
So let's dive into our Journal. Hello again, to all my
listeners. Hope that you are doing great
today. Welcome back to another new
episode of the Tecla Journal podcast.
As always. Thank you for tuning in and
listening to this episode. If you're new to this podcast,
don't forget to subscribe and follow technology, you know, on
your podcast app and social media on LinkedIn, Twitter and
Instagram. And if you love the podcast,
support the show by subscribing as a patron at package, you
know, dot f / Patron. And support me in my journey to
produce great episode. Every week.
My guest for today's episode is Fernando, dog, Leo, Fernando is
the author of skills of a software developer and he has
over 18 years of experience in the software industry from web
development, to Big Data, and so on.
And by the way, throughout the conversation, I mentioned the
book title as code well with others, however, since then the
book title has been updated to skills of a software developer.
/. So hopefully you all do not get
confused about the two different titles in this episode.
Fernando shared some insights from his book on how we can all
be a successful software developer.
He highlighted that software development is mostly a team
effort and he shared a few tips on how we can be a great team
player and work well with others, including the importance
of writing readable code to Auntie patterns in particular
that Fernando advisors to avoid are over it.
Nearing an early optimization. So make sure that you listen to
his reasoning so that we do not fall into the Trap of both in
our work. Next Fernando also shared some
practical tips on technical interviews and what we should
avoid writing in our resume, towards the end.
Fernando gave his tips to aspiring authors, who want to
write a technical book. He himself has written five,
technical books, including the recent Manning book and I asked
him what advice he has for some of us.
Who would also like to write a book.
He gave really great advisors, and cleared some common
misconceptions and mental blocks that may stop a lot of aspiring
authors from writing, and Publishing their books.
I enjoyed my conversation with Fernando listening to his tips
for becoming a successful software developer.
And in particular, his insightful advice on how to
become a book author. And if you also like this
episode, leave a rating and review on your podcast app or
share some comments on the social media on.
Do you enjoy from this episode? Those reviews and comments are
one of the best ways to spread this podcast to reach more
listeners. And it is my hope to have more
people benefiting from all the episodes in this podcast.
So let's get our episode started right after our sponsor message.
Are you looking for a new cool swag tekhelet Journal.
Now, offers you some swags that you can purchase online.
These wax are printed on demand based on your preference and
will be delivered safely to you all over the world.
Where Shipping is available. Check out all the cool swag is
available by visiting technology.
Know that death / shop and don't forget to break yourself.
Once you receive any of those tracks.
Hey everyone, welcome back to another new episode of the
technology on our podcast today. I have with me, Our Guest named
Fernando do glue. He's actually start writing his
book called coat, well, with others.
With a subtitle, be an effective team player.
I think today, we are going to cover tips and tricks for all.
The lapis out there in order to be aware of how you should
behave, or, how should you treat yourself differently when you
work with others? Because probably will also
discuss about the difference between a solo developer, which
probably some of you are doing and also team player developers
when you work in a company on the team or even open source
projects, how much different it could be as a programmer.
So Fernando also wrote a number of books and nickel books things
like really good node.js and all that.
So we will probably also get some tips from Him on how we can
start writing, technical books. So, Fernando looking forward to
have this conversation with you today.
Welcome to the technician. All right.
Thank you. Hi, everyone.
Very excited, be here. I can't wait to get started
honestly. Thank you.
So Fernando, baby for people who don't know you yet.
Maybe you can introduce yourself.
Maybe sharing about highlights or turning points in your
career. All right.
Well, the exam from a little earlier.
I'm originally from your way. Although I'm right now, living
in Spain, in Madrid. I have been part of the
industry. Or around 18, 19 years.
I started working as most developers to, as a web
developer. I started with JavaScript and
HTML CSS eventually move to back in a few years later, around
five or six years later. I moved into a big day toward
and started also Mari. And my experience with web
development, couple with the architecting of Big Data
platforms and how to scale at application past the single
computer essentially fellow We Big Data.
Hello. We picked it architectures and
bring our marriage, you know, deletion you practice for the
company? You work for.
So it seems to me that your experience is varied.
So you started from like a front-end developers doing web
development, go to the back end and then now be cater.
It seems for some people. Actually, they might not even
fantasize doing all these three different things at the same
time. So maybe can you give us some
lessons learned throughout your journey?
How can someone actually achieve something like you juggling and
hoping between multiple? Domains.
Well, definitely part of why I've been able to do it because
I've been at it for a while. I mean, 18 years, not sure time.
So it takes time to go from one place to the other.
That's for sure. But I think the key here is at
least understand that everything is related.
I mean, when you're working on the front end of web application
nowadays, it's not like you're just building a static website
for a small company up to people.
You should at least aim for building, something that will be
popular. I would be looked at by. -
people will have high traffic that translates to a back-end,
that is also capable of dealing with that amount of traffic and
that translates to a whole architecture.
So it's all related and the moment you start realizing that
everything is the same. What I'm trying to say is
whether you're coding in react, or working PHP or riding a bike
line on by Spark, It's just cold.
No more. Your style realized that the
logic may change the language may change, but there are four
five main paradigm. That you're going to be actually
having to learn and applying and that's all you had to care
about. The rest is just coding.
Anyone can pick up coding. I mean, it's a matter of time.
So I think the main problem with people going through that
journey and trying to go from one area to The Other Extreme is
that people put themselves in boxes and say, well, I'm on
reactivated. I'm great at react.
Don't talk to me about by spark because I don't know anything
about by Stack, but honestly, you gotta pick up some mechanics
of helps. Mark works, but that's
learnable. The rest is just code.
The Mummy that clicks in your head.
Then there's no place for you that you can be honestly you
want to go from coding react to coding robots.
That's also possible. It's just cold.
That's the main thing here. Sometimes.
People don't get that. At least people get it started,
and that's something. I also try to cover him a book.
It's just cold. So, you also mention a one key
thing that I took away from your explanation, just now, which is
about Paradigm and putting yourself in boxes.
So, I think the Since here is that we should not putting
ourselves in a certain Paradigm saying that, okay.
We are just a web developer. For example, I think
understanding the fundamentals and Basics, which is that coding
or you said, maybe some kind of algorithms on how a computer
works. Things like that is also
instruction, right? So, which brings us to the book
itself? Why do you write about this
topic codes? Well, with others, do you find
problems in the industry or in your career that people do not
code? Well with others, the book
story, as a miracle on medium, actually it had I'd like to
think he was like eight or nine Lessons Learned through my 18
years of experience. There.
I cover everything obviously. It was a single article covering
the other thing so they were just highlights of a lot of
things are now in the book, but it covered things.
Like from usual, bad coding practices to problems with
dealing with teams and remote teams, things like that.
The article got a lot of big nice reception essentially, a
lot of experienced coders saying, I agree 100% with you.
You hit every nail When mining approached me and told me you
were ready. Radical.
And we like to expand on it which turned out into, as you
see the blueprint of app developers career based on
lessons. I've learned through those 18
years. This is kind of our road trip to
my Lisa mistakes. If you will, I made a lot of
them through 18 years. So I'm just trying to show one
that everyone makes them if you're making mistakes is part
of the journey and to Larry set better way of doing some things
and a better way to look at some situations coding.
Well with others or being a team player is kind of a be heart of
everything we do as a when you say you said solo vertebras
right? Unless you're coding yourself
for a piece of software that only you're going to use your
not a solo developer right now. We share call you get how we
share it with everyone even if nobody's following even if
nobody's interested, right of the bat on, something will Doing
Google's their induction everything.
I mean our code is going to get find out eventually even if we
don't want to, we may get feedback week might get people
for king or code and using it. So we need to understand what it
means to be part of that Community.
Even if you don't want to and code in a way that helps,
everyone it's not just about I run my code and it works for me
and that's it. Interesting perspectives in the
sense that even though you think you are so low developers, write
like you're just building EOC project, but the moment that you
share, RIT either on GitHub or maybe just publish a blog post
that you think others will not read things can get picked up
automatically by changing and maybe some random opportunities
that people just randomly, see your code.
And see, that actually how well your code is written, but maybe
in the first place is. Alright, I wrote the first
chapter of the book and you kind of like started interestingly by
saying that all of us can be a successful developers.
There are certain things that we don't actually need to be so
concerned about. So things like bachelor degree
or understanding about software development.
My life cycle, so can you maybe share the Dismal your thought
process around this? Absolutely.
So I try to start attacking some of the classic misconceptions
that people have around developers and what they need to
become one. Like I said before anyone can do
it. It's just a matter of
understanding how God works from the user perspective and what
commands, you need to work. You don't need to go to college
to understand that you don't need like a paid certification
to understand that you don't need to understand how the whole
software development life cycle goes, what you have to learn.
To code, just write words that make sense so that they can be
executed. You can pick it up by reader
tutorial or by watching a YouTube video.
That's all you need. What I'm trying to say in
chapter 1 is that instead of focusing on those skills that
you have to learn to become a successful developer.
You should realize that if you want to be a successful
developer, you have to understand that you're going to
be learning through the entire process.
You have to understand that you're going to be having
problems to solve and we determinant of 2.
We'll go home one day with a problem.
You couldn't solve, and come back tomorrow and start again or
try again. It's not a set of hard skills
that you have to learn in order to become a successful
developer. The hard skills come with time,
Claudine comes with time. You can really do a
certification and say, whoa. Now.
I'm a believer that part of learning the colder in the
paradigms learning, how syntax works that takes time.
The key traits that you have to have.
Our orders are soft skills that if you don't think, About them,
they're not available. If you don't take the process of
going through the development of an application as a learning
process, personally, you have to worry about the right thing to
eventually make it as a sexually available and none of them are
technical. That's my point there.
If you want to pick up development right now, it's
fine. Just go, watch a YouTube video.
Write your hello work. You're a developer.
You did it. That's it.
The rest of the hard skills is expanding like that.
You showed yourself that you're able to To learn something new.
Are you going to be doing that throughout your entire career?
You learned that your able to make a switch from whatever you
were doing into this. And they have to be flexible
through your entire career, unless you want to just focus on
one branch of development. And then when that Branch dies,
you're out of a career. So, that's the things that try
to explain in chapter 1. Don't get me wrong.
I'm not saying that formal education.
I don't need it. I taught myself how to code when
I was 14. I did the whole high school net.
College thing and I dropped out of college because I had a job
already and I try to pursue that but eventually realized I
actually needed that formal education related in my ears and
I went back to college and finish a technical degree.
Why did that? Because definitely think there's
a value to formal education. And there is a value to a
certification that you can have an understanding that some of
the Venom life cycle completely, but you don't need them to get
started, and that's kind of what chapter 1 covers.
So then in your case after you have Anshu, all this experience
learning by mistakes. Like what humans?
Share? What do you think are?
Some of the biggest tips for somebody will pursue think about
whenever they want to be able to work well in a team set up.
So the first thing they need to understand that they're not
alone, whatever they're doing and they'll see, she said,
they're taking around their cold water colors.
That's also the main point around the topic.
If you're a perfectionist, I you wanna get your code, perfect,
which is something that doesn't exist.
Really, you're afraid. In timeline of your project if
there is a dependency for no task.
For instance. I do their Duty priests waiting
for because you haven't finished yet.
You're a faith in their work. If you're not careful enough and
you're not writing unit tests for instance, or paying the
right attention to, you need to send doing it.
The proper way you might end up, delivering something that is not
stable enough and others will work on top of that.
So everything's connected in the sense that if you don't do your
part, well, then everything else will fall apart even If you
think yeah, you're a small part of it because you're just
getting started. Junior developer.
Who doesn't know better. Whatever.
You may think that your situation is.
Your work is directly affecting other stats.
Also, the main point there are multiple topics that cover here
regarding trying to over engineer a solution.
Right? I mean who of us haven't really
fall for that trap before and fell in love with a solution
that is super complete and covers every angle of it.
And when you actually need it practically you could have
solved that problem in two days. You Actually took two weeks, but
you cover everything that wasn't needed, you affected.
The timeline of the project you delivered late and everyone
depending on that was late as well.
That's the kind of thing. I try to explain here and show
how it affects others decision. So on the last topic where you
mentioned over-engineering, I think most of the developers
love to do this and one way or the other right, either
consciously or unconsciously. We always like to chase
something that we think is a Perfection, you mentioned that
there are ways around overcoming this problem.
So what are the ways or tips for people not to fall into the Trap
of over-engineering? You have to be objective.
I mean, they may problem you have.
And the more reason why it we fall for that trap is because we
fall in love with our own Solutions, we forget about the
rest and we think about just the solution.
I'll have to build and then within wall, this is good, but I
can do better and I could do better.
This is great. I have the perfect solution.
I'll just implement it. I'll take as much time as you
need. You never thought about well.
Well, whatever. The others want to do, yours
actually need that submitting. You have to look at the
solution. You're trying to implement from
the big picture. I like to say that sometimes
developers don't raise the head above the laptop and look out.
Were just so focused on what we're doing.
The co-writing that we forget to look around us.
We might have bunch of developers or teammates waiting
for us to finish. So, I think that the main tip
here is, if you're writing, if you do something you create
something, you let it stay for a day and then come back.
It, you might come by the other day.
I hate it. If you draw if you paint thats
also a common issue, you think you did something amazing and
you come back the other day and just try way because it sucks
the same is with other ideas. You will need to look at it
objectively and even if you have to walk away and get back to it
for a day, you might see that you're not actually thinking
about the big picture. You just think about your
particular solution, your particular problem and you're
not caring about anyone else. I think that's the biggest tip.
I have for overcoming over Vision.
Earring is more like avoiding a Visionary at all.
Try to look at it from another perspective.
Not just yours. So when you mention about
objectivity, right, maybe, can you refer to some examples?
Is it like referring to requirements?
Is it referring to the deadlines?
Or is it referring to some other factors that you think can
provide more objective Baseline for developers?
Absolutely. I mean, it's all done and
everything else except your problem.
The timeline is going to be affected if you can deliver it.
And you usually have a small window time preset for you to
finish that solution. If you think that you have a
better alternative, but it'll take longer.
Then that's definitely going to affect everyone.
Especially if you don't even consider how that's going to
affect everyone else and even speak about it.
You're going to have a big effect on the rest of the
Prussian, the research team, the requirements Gathering as well.
If you're shopping from solution to solution, bigger and bigger.
If that turns out to be over engineer you Might even be
making assumptions about future requirements to protect example,
you have to feel that cataloging page or the login service for
your app. You have a lot of alternatives
are a little variations from simple user password valuation,
against a database, all the way through single sign-on, multiple
entities, and everything. So, where do you put that, stop?
Where you say? Well, this is complex enough.
This is big enough for the application and it's going to
work as it is right now. If you have a set of
requirements that State that are don't State.
The fact that for instance, you need single sign-on, then why
are you implementing that are you assume that's going to be
needed? Because in the future you want
to be building other applications that will benefit
from that. That's fine.
But if you're making that assumption you need to validate
that assumption because that might be the case that you say.
Well, are we gonna need this? Because in the future, we're
going to build that your manager, your Technique, where
my come by say. Well actually, you know, what?
That's a great idea. Let's do that.
And let's adjust the timeline because we needed.
Showtime, that's another operation here.
But if you don't do that, you don't validate that you just
assume. So you're over engineer a
solution. I should have been a lot
simpler. That's a point and this is also
kind of like related with another tip of your switches to
focus on working code first. So when you start looking on
solving a problem, you should probably aim to make it work
first. Maybe you can elaborate more on
this point. Absolutely.
That also speaks to not only over each day and Barrel saw
Ellie optimization. That's an old trap that we like
to fall. Getting everything.
Perfect and working the best possible way that he can work
from the get-go. That's the worst way to build
code because to optimize code to make it perfect.
You need to have measured it first.
You need to know how it performs if there's any bottleneck where
it is and then optimize. So if you're going the other way
around, if you put in the car in front the horses, then you're
assuming that you're going to have problems, you're assuming
where the problems going to be and you're assuming house.
Oh, the solution will work. You're guessing essentially and
you're not fixing anything. So, the way I like to approach
coding and problem solving in general is get a bunch of code
that together solve the problem. I don't care if it looks good.
If it works great. Does it solve the problem?
The main question you have to ask if it does so the product
then start making it prettier. Clean it up into multiple
modules or whatever. And then once that's ready, add
the code is readable by others on the code is useful and
reusable event, then. Start measuring it.
That's it. Perform correctly.
Does he have any bottlenecks? And then start optimizing it
when you're optimizing it, understand that there is going
to be a point where you have to say that's enough because the
perfect gold doesn't really exist.
There's always going to be something that throws you whole
set of assumptions. The moment.
You don't see that when you stop seeing that you're stuck in an
infinite Loop, always optimism. That doesn't really need to be
optimized. So when you say optimizing
getting a measurement and all that does it mean that you
always need to put the code itself to the front of users or
getting deployed somewhere for people to validate or actually,
you go through like some kind of performance.
There's any kind of experience you have here on how to people
measure their code first before they optimize, that's very
valued. I mean, I can't really give an
example of one way that will work for everyone because you
have environments were running an algorithm.
That can run your laptop. It's big enough of a lab test or
good enough of a test to understand if it's performing or
not, but if you're Keen on microcontrollers, or if you're
building something that is super time-sensitive that you probably
needed to run on the environment that it's going to be deployed
to be 100% sure that he knows how to deal with all the
intricacies of the environment. If you're building something
that needs to be distributed. Then you need to understand how
it runs for a set of notes or any should Master, but
figuration and then build on top of that and try to make it
bigger or smaller and go from there.
So the point is that you need to understand that one you Have to
make sure it you have to understand if performance is an
important topic for you. Then you need to understand that
you're going to measure that performance.
You need to understand what kpis or what key indicators are there
for you to look at because measuring is not just about
having a start counter at the beginning of your code and an
encounter. At the end of that whatever
function you're trying to test and see how many seconds I took
were having these in microseconds.
You need to understand. If performance, for you means
speed. Or if performance, for you means
function calls or memory used or how many threads you were able
to start. It's so quiet.
It's Unique to your context again.
No, share example here, but that is what you need to understand.
You need to resonate when you're going to be basically, to what
apis, you have to measure. And then three try to find a way
to measure those kpis without affecting their performance, so
much that the mere effort of measuring affects the
performance. That's another big thing.
But if you Managed to do that. Then you're able to actually
understand how your application works, how your code works.
You can build from there, understand if your kpis are
within a reasonable thresholds than great.
You made it, otherwise start tweaking based on that.
But if you have that, you have half the bottom one because
you're ready. You're basing everything you do
from now on or reality. You're not assuming anything and
that's major and you have mentioned a couple of times
about readable code code that is maintained.
I think this is also one big part of being a good team player
for any developers out. There is that your produce code
must be understandable by others.
Maybe you can give us some stories or experience throughout
your journey. Why is it so important for
people to make their coat understandable by others?
I always, like to say that code needs to run a computer, but be
read by humans and sometimes we forget about the second part
that goes back to my initial statement.
You're never working alone. Even if you think you are that
close. Code needs to be understandable
by you in the future or tomorrow or within the next 10 minutes.
When you write code, if you don't write it correctly, you
might not add enough context to whatever you're doing.
We're not perfect machines. We forget we have terrible
memories. So when we get back to our
algorithm that we wrote, and it's complex enough.
We might not even understand our own code, and that happens to
everyone that has happened to me.
I mean, X, if we can't even rely on our memory to understand what
we did, how can we We expect others who have not gone through
the ideation process for bag with them to, actually
understand it by just reading the code.
So, readable code means a lot of things readable code.
Can mean avoiding one liners because they might look cool or
my solve a problem. It's just a single line, but my
need to be mentally past when you're measuring, how readable
code is, you have to take into consideration, the amount of
effort that a person has to go through to understand the gold.
And that means most Most of the times were mentally parsing the
code and mentally executing it to understand how their good
works, or how this single line is parsing or transforming the
information. We need to actually make it
usable on the next line. So if we have to go through that
amount of effort just to understand it, then the code is
not readable. It might work perfectly on the
machine, but you need to also try to optimize the amount of
time you have to spend looking at a block of code.
If you want to modify in the future, it's not that hard
honestly, I mean, well read Comment, might solve all that
problem. So things like comments in the
code understanding that the code has to have a structure so that
it's easier to read, if you're not using something like, python
indentation is crucial here. If we don't pay attention to
that, then reading code becomes a lot harder.
If you're already part of a team, there are probably coding
standards that the whole team is following.
If you don't follow those coding standards, you're not writing
readable code because the reason for the coding standards is they
have nothing to do. Ooh, with the computer, the
computer will always translate, whatever you write to a piece of
code that it understands. The coding standards are for you
and other developers. If you write following the same
naming conventions, the same syntax, the same structure in
the code. It will become easier to jump
from one file that you wrote to another file written by someone
else. It'll be like, looking at two
pages from the same author, you know how that author writes.
I, you know, where to find the key bits of information already
because it's follow the same standards.
That's the way you have to also think about humans when writing
code and make it readable for them.
I'll add the way you explained the beginning, like saying that
your code will be run by the computer.
It doesn't matter how well written or not.
So well written at the end of the day will be translated to
the same binary. But also the other aspect is
that your code will be read by other people, including you
yourself in the future and I like the way you avoid the
phrase mentally, parse it, I do there's some jokes like maybe
the amount of WTF when Reading you should I think maybe one
gauge of like mentally are seeing it so hard, right?
Thanks for the analogy here, another chapter in the book.
I think you cover a lot about technical interviews.
For example, the first is from the employer point of view.
Right? What we should look at in terms
of assessing candidates, whether they could play well with
others. So, yeah, the interview process
is very interesting and filled with interesting Insight that
both bodies get. I like to think of the interview
process of us getting to know each Other.
We as developers, tend to think that, you know, I'm going to get
interviewed. I'm going to let them know me.
But through that process, you're also knowing them the
interviewer, the company you're trying to work for and the type
of communities they have. So, from the interviewer side,
and I've done this many times, you get a sense of how that
person will fit within your existing team.
If you have one or within the existing company culture, if you
will, so when going to an interview, if the person coming
is Is late or even if it's an online interview, like nowadays,
if they don't show up in time, that's a big telling aspect.
If their CV is filled with passwords.
That's also something that might not be exactly what the
interviewer wants to see if I'm looking for a web developer.
And I get a CV filled with react view, angular JavaScript.
You're not telling me I could do what you do with them.
I might think that you're just putting things because they
sound about, right? But at the end.
You might have read a few articles about react blade or
done a few boc with you and have been working for a few months.
The dangler. That's actually what I want to
know. So you got to the interview by
you incorrectly set the expectations on the interviewer
and that person's going to be really disappointed with your
profile. When, if you have set the
expectations right from the get-go, that person would have
tackle the whole interview differently, maybe whatever we
need press with your action knowledge.
So that's a big thing, especially if you Take it
farther lying in your resume, which is also something that is
sometimes only pretends to do. It's a big No-No in my opinion
because you might get lucky and you might get an interview that
sorry care about one particular aspect that you lied about and
will not even ask what? But the moment they ask and the
moment they hear you not replying confidently enough or
correctly. The whole expectation that you
set, really high is going down. The whole idea of your profile
is scratched just because you took it a bit further.
So that's also something that from up interviewer point of
view. I personally look for I only
need you to be honest during the interview.
I don't need you to be the best developer ever.
If you show me you can solve problems.
If you show me that you can explain how you would solve
those problems even without using the right technical term
even without using the right password.
At the time. I'll be happy.
It'll be a lot better for me than having this huge curriculum
from someone that is not able to talk about those things.
So, that's the main thing. I would say from an interviewer
purview that can be seen essentially, interesting and
what about, from the interviewee aspects?
So, you mentioned in the chapters few examples that
actually is interviewees, should not say or should not show it
whenever they go through this technical interview, right?
Well, saying something like I'm at react developer.
I mean, you are already putting yourself in the Box, you're not
even letting the interviewer do it for you and if they don't
need react then, Does that mean you can really pick up view or
angular or any other JavaScript framework?
I mean, this is Javascript will talk about the same language,
different Frameworks. Why are you doing that?
That's something that I think should not be part of your
resume. If you want to say I'm a
developer and I know react that's another thing.
That's a whole different way of looking at it by saying I'm a
react developer. I travel developer then what is
that mean? You can really pick up another
language. Can you pick another language
within a reasonable number? Time, I mean, what's the big
deal with it? Or why do you prefer one
technology over the other? That's another big No-No.
I mean saying things that well, I work on Linux because Linux
the best development environment and windows sucks.
Yes, every piece of technology is going to be better than
others in different context, but that doesn't mean you can't make
it work. I love working on Linux for any
development task, but I've had to do in Windows actually right
now. My computer is a Windows machine
and I sometimes have to code or Look at code and you can make it
work. So, why are you closing yourself
to the opportunity of that work? Just because you're just too of
a fan of a piece of technology that you can really open your
mind to others. That's also a big problem to me
when interviewee tells me that, I mean, you're showing me that
you're not flexible enough. Our industry is always changing.
You might be working in react right now because it's the best
framework ever and tomorrow. A new one comes up, that is 100
times better. Are you telling me you're not
going to Make the switch just because you love react you're
gonna stay behind of the state-of-the-art.
You're telling a lot without saying too many words, you're
showing a lot of bad things, if you go that route, so that's
also something that I recommend not focusing on, you might have
a list of preferred Technologies.
That's fine. But you also have to make sure
that it's clear that you're flexible that you're open enough
to pick up all the things that you've never seen before.
There are probably other things beliefs could be a bit longer.
But yeah, that's the main thanks again for it.
He has not to put ourselves in the box and always to try our
best to solve the problems even even though you don't know the
technical. Jargon.
You don't know the algorithm. You don't know the passwords as
long as the principles, how you use the top process to solve the
problem. I think that's probably is the
most important thing that the interviewer is looking for.
So, for another live, look at your profile, right?
You seem to have written a lot of books.
Actually. I think if I contract Leaf
already published about no Jazz and related to that, the other
one is the code. Well with others.
Which is another technical book so to speak.
So how do you achieve all these? Because they are some people who
Wonder at themselves or I want to write a book but never seem
to be able to get it done. So maybe I can share your
experience in this ball. I see.
Yeah, absolutely and I was one of them as well.
He maintained that has to happen is that you have to understand
that any one that writes a book is not an expert of that acting
on the ship when they're starting to write a book.
So there's this misconception that a lot of authors are They
know everything about their subject that doesn't necessarily
have to be true. It may have been some situations
as that's absolutely correct. But many times it's just not
there, just good at researching, you know, and learning
personally, the first book I wrote about rest API design for
no chairs. I studied the book with that
misconception. I was sure I knew where we can
have a rest and that I was able to write a book because of that,
through the process of expanding other chapters to have blad and
through their s of research and allowing more.
I understood that I didn't know a lot about rest.
I came out the other way, Having learned the things that I didn't
know. But I also told me that I don't
have to be the expert to write a book.
I just need to understand how to do proper research, and then how
to explain that researchers actually in an interesting
manner that's not easy at all. I'm not saying it's easy or
simple, it's just their mom and you realize that you don't have
to be the expert, you start thinking world.
I can do research. I'm always learning about new
things. Then I can try to explain
things. Even if you are now writing blog
posts or articles and you're afraid of taking that next step
into a walk. Then you already know how to do
everything. It's just a matter of creating a
bigger plan for a bigger article if you will, so, that's the
first thing I understand it. You're capable of doing it that
you don't have to be that experience or anything.
The second mental block that we tend to have is.
Well. I may be able to write it but No
one cares about it because I'm not one who's going to read it?
Who's going to care about what I have to say about this topic.
That's the second mental block that we have to go through.
When you realize that, it doesn't matter who reads it,
you're writing it for yourself, then it's just a matter of going
through, the rest of the steps that are more mechanical if you
will. So after you made up your mind
and say, well, I'm going to read the book.
I know how to write. I think I know how to write.
Maybe you never did it before. I think I know how to write a
book. I think I have the topic.
I want to talk about then. It's just a matter of trying to
find the publisher and try to come up with the idea of what
the book going to be. Like.
What am I going to say about this particular topic?
You might do that beforehand and then go find the publisher or
you might go to a publisher and say well I want to write a book
about this because I've been using it for years or because I
think it's an interesting idea. They might say, well then let's
work together. Let's create the table,
contents. Then let's create a plan for it.
And then we'll start working on it.
Many may think that they need the book written beforehand,
which is not true. They may think that there is no
way to reach out to a publisher which is also not true.
Most of the Publishers I work with and I looked at they
usually have on the website contact form email or something
some way for you to contact them and tell them about your idea.
They also think that this Publishers will not really care
about them or about their book ideas because they're not big
Twitter. See, It is our big names in the
developing industry. And again, that is not the case.
They care about the content. If you don't have a big
following or if you're not worked on big brushes before,
that's not a problem at all. Most of them are super open to
helping others in authors and walking you through the whole
process. So it's actually a lot less
painful that a little bit to think.
Wow. Thanks for all this inside.
So there are a few key things that I picked up here.
The first is that, of course, you don't need to be.
A all experts in this topic that you're writing about.
So that is maybe one misconception.
Sometimes. Also, you can do a good research
about the topics that you want to write about and also write in
an explainable manner, the findings from your research.
And also don't think about whether people will read the
book or not the end of the day. If you write for yourself and
you are the only reader I think that is also another thing that
could be an achievement by itself.
The last one is about publisher, right?
So you don't need to come up with a pre-written book as a
draft. You can also reach out to
publisher if you Topic, all these things, probably is a
possibility. So don't think that you have to
come up with a draft of, maybe 80% of the book and then share
with the publisher. Correct.
Some Publishers may ask for, like, a single reading chapter
because they want to know how you write.
If you've never done it. If you don't have any published
work, they might want to look at how you explain things or things
like that. How do you express yourself?
Because that's also key. But it's just a matter of
writing, a single chapter versus writing, 80% of the book, which
is a little higher. One thing that Is also key here
is that if you've never written anything before, you might be
afraid that you're not able to express yourself in the right
manner, you might think that your writing is boring.
You're not explaining things correctly or you're doing it too
complex. The thing also to understand is
that you're not alone in this writing process, you write it.
You be the author of the book and you'll take care of writing
all the content, but they're going to be at least one some
point. You just have a lot more
reviewers of your work. Technical reviewers and Other
type of editors that will give you feedback way before that
chapters gets delivered to a party.
So if you're not able to explain yourself correctly, if you're
thinking that you might have a technical issue with an
explanation, or you're not covering a topic long enough or
good enough. There are a lot of filters that
chapter has to go through before getting released and through all
those features. You'll get feedback in the way,
explain things in the actual topics.
Are you cover? So, you'll be able to polish
that chapter? Through that process.
So by the time he gets released, it's a lot better than the
initial draft. You're not going through that
alone and doing the research yourself and trying to find
yourself better ways to write essentially.
So that's also a huge help that not only do people realize is
there for you? Yeah, that's also a very key
thing. I was about to ask.
What if I didn't know how to write properly, all my English
sucks, for example, she so thanks for reminding this.
That actually you're not alone, right?
There will be people along the way that can help to review or
edit some of the stuff that Wrote at the end of the day.
It's a team work again. Even though you are a single
solo. Authorized.
There are a number of people helped me along the way.
So thanks Fernando for this time.
I really love our conversation and learning a lot from you.
But unfortunately we have to end the composition due to time.
But before I let you go, I normally ask one question for
all my guess, which is to share your tree technical leadership
wisdom. So that people can learn from
this wisdom. All right?
Okay. So three, the main thing will be
and I usually recommend this for leaders and not only the There's
actually everyone is to leave your problems at the door.
This was a piece of advice. I got when I think it was my
first show it clicked. You might be having a terrible
day. You might be having problems
with your family or whatever. I'm not saying they're not
important. I'm not diminishing their effect
on you. But my recommendation is, when
you have to start working, just drop them at the door.
Forget about them. Mentally block them for the
time. You have to do your work, focus
on that, get the work done. And don't let that affect you.
It's not easy, but with practice, you can get better at
it, especially to avoid. Letting that affect your
performance, might sound a bit harsh, but life is filled with
problems. And if we don't make that
separation, especially now where a lot of us are working remotely
from home. So it's a lot harder to make
that split and say. Well, now I'm going to the
office and the office is in your living room.
You can really stop thinking about personal problems and
start thinking about What problems if you are able to make
that separation that sleep, then you can just get the work done.
Be done and then go back to dealing with whatever is
affecting you in your personal life.
That's my number one tip. I give everyone that is working
in our community, the other one and this is definitely meant for
leaders. And one that I had to learn
myself is to listen and let others speak up as a leader.
You might think that you're the one making all the decisions and
your Plan. Your idea is always right, but
that doesn't necessarily have to be, I mean, that's not why
you're the leader this this confusion.
You think that you're there because you're responsible for
every single decision depression and that's not the case.
You have a whole team around you that is doing and it's working
on this exact same pressure that you are.
They will probably have a little bit ideas that you do.
So the first thing is to make sure that you're listening for
those ideas that you're creating a Safe space for them to speak
up and then that they know they are safe there and that they can
speak up and even disagree with you.
That's the most value interaction.
Inside a project is when someone disagrees with the leader
because they probably have a better way of doing it.
They may be right or not. But that disagreement will spark
the conversation. Maybe none of them were right,
but the end result of that conversation will be a consensus
of a way to solve a problem that no one has thought about so far.
So, definitely make sure. Listen.
And definitely make sure that everyone knows that they can
speak up because that's another problem.
I mean, especially in distributed teams.
We're not always dealing with people from the same cultural
background and not every culture is okay with this agreeing with
leaders or disagreeing with authority figures.
So it's sometimes a bit harder than others to make sure that
whatever is working with, you is actually agreeing with you
because they honestly think that you're correct and you're
proposing the right plan. Or they're just agreeing with
you because they don't think they can speak up and tell you
that. No you're wrong.
So creating that safe space so that everyone can feel like they
can open up and tell you what they think is key to leadership.
Finally. It's kind of tied to a point.
You have to understand that you're not there.
You're not in that position because you're the one that has
the most critical knowledge of the team, you know, the guru.
You're not the expert on everything that you're doing.
You're the leader because you have a set of skills that
probably not all of the People on the team, have you probably
have the best soft skills. You have better blending skills,
but you're not necessarily the most technical of them.
So it takes with the other one knowing that is why you also
have to make sure that you listen to your team because
maybe your plan, your tinkle is yours are not best informed.
They're not the greatest. You might have the greatest Tech
developer in your team, and you're just not listening to
that person. So definitely it's about knowing
your place. Knowing why you're there and
understand that you're not above everyone.
You're just fulfilling. Bye.
Very different type of task and just understanding where that
space is for you leaving the rest of the responsibility to a
team. Wow, a lovely wisdom indeed.
So I like the first one. Leave your problems at the door.
Although now these days working from home seems like the door.
Is that a bit attractive. So Fernando it was a lovely
conversation when can people expect to see your books?
Like the cold well with others. So yeah, the books already
available in mornings Early Access program of meat so they
kind of ready It looks very demanding site.
Get what's already available, which I think is four or five
chapters already. Like I said, you have different
filters in the process. Six chapters already finished
by. It's not on me yet because it's
going through a peer-review process first.
They're sending it to other reviewers.
That might be potential readers. They fit the profile of the
reader. They'll just look at it first.
Give me the feedback on the will adjust it if we think we need
To. So essentially, the book is out
already. You can get it.
If you get it through the me program, you'll get updated
every new chapter every time their new chapter is released.
Otherwise in the next few months.
The full book will be available through the website.
Another combo channels looking forward for that.
Good luck with the process. So hopefully we can be able to
see the book soon. Thank you for having me.
I mean, it was really fun and entertaining.
Thank you for listening to this episode and for staying right.
Till the end. If you're highly enjoyed, please
share it with your friends and colleagues who you think would
also benefit from listening to this episode.
And if you're new to the podcast, make sure to subscribe
and leave me your valuable review and feedback.
It really, really helps me a lot in order to grow these podcasts
better. You can also find the full show
notes of this conversation on the episode page at technology.
Know the death website, including the full transcript
interesting quotes and links to the resources.
Horses and mentions from the conversation.
And lastly, make sure to subscribe to the show's mailing
list on technology. No, the deaf to get notified for
any future episodes. Stay tuned for the next
technique Journal episode. And until then.
Goodbye.