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.