#62 - You're Never Coding Alone, How to Be a Good Team Coder - Fernando Doglio

[00:01:17] Episode Introduction

[00:01:17] Henry Suryawirawan: Hello again, to all my listeners. Hope that you are doing great today. Welcome back to another new episode of the Tech Lead 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 Tech Lead Journal 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 techleadjournal.dev/patron, and support me in my journey to produce great episode every week.

My guest for today’s episode is Fernando Doglio. 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. Two anti-patterns, in particular, that Fernando advised us to avoid our over-engineering and 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 advices 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 what 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.

[00:04:33] Introduction

[00:04:33] Henry Suryawirawan: Hey, everyone. Welcome back to another new episode of the Tech Lead Journal podcast. Today, I have with me a guest named Fernando Doglio. He’s actually start writing his book called “Code Well With Others” with a subtitle “Be An Effective Team Player”. I think today we are going to cover tips and tricks for all developers 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 we’ll 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 or in a team, or even open source projects, how much different it could be as a programmer? So, Fernando also wrote a number of books, technical books. Things like related to NodeJS 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 Tech Lead Journal.

[00:05:28] Fernando Doglio: Right. Thank you. Hi everyone, very excited to be here. I can’t wait to get started, honestly. Thank you.

[00:05:34] Career Journey

[00:05:34] Henry Suryawirawan: So Fernando, maybe for people who don’t know you yet, maybe you can introduce yourself, maybe sharing about highlights or turning points in your career.

[00:05:41] Fernando Doglio: All right. Well, like you say, I’m Fernando Doglio. I’m originally from Uruguay. Although I’m right now, living in Spain, in Madrid. I have been part of the industry for around 18-19 years. I started working as most developers do, as a web developer. I started with JavaScript and HTML, CSS. Eventually moved to the back-end. A few years later, around five or six years later, I moved into big data world. And started also marrying my experience with web development coupled with the architecting of big data platforms, and how to scale an application past the single computer essentially. Fell in love with big data. Fell in love with big data architectures, and right now I’m managing a data engineer practice for the company I work for.

[00:06:27] Henry Suryawirawan: So, it seems to me that your experience is varied. So you started from like a front-end developer doing web developments, go to the back-end and then now big data. 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 learnt throughout your journey? How can someone actually achieve something like you? Juggling and hopping between multiple domains?

[00:06:51] Fernando Doglio: 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 a short 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 to 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 of two people. You should at least aim for building something that will be popular, will be looked at by millions of 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’s the same. What I’m trying to say is whether you’re coding in React or work in PHP, or writing a pipeline on PySpark, it’s just code.

Normally, you start realizing that the logic may change. The language may change. But there are four or five main paradigms 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 a React developer. I’m great at React. Don’t talk to me about PySpark because I don’t know anything about PySpark. But honestly, you got to pick up some mechanics of how Spark works, but that’s learnable. The rest is just code. The moment that clicks in your head, then there’s no place for you that you can’t be, honestly. You want to go from coding React to coding robots, that’s also possible. It’s just code. That’s the main thing here. Sometimes people don’t get that. At least, people get excited and that’s something I also try to cover in my book. It’s just code.

[00:08:42] Henry Suryawirawan: So you also mentioned 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 lessons 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 like coding, what you said, maybe some kind of algorithms on how computer works, things like that is also important, right?

[00:09:05] Skills of a Software Developer

[00:09:05] Henry Suryawirawan: 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?

[00:09:16] Fernando Doglio: The book started as an article on Medium, actually. It had, I think, it was like eight or nine lessons learned through my 18 years of experience. There, I cover everything. Obviously, it was a single article covering a lot of things. So, they were just highlights of a lot of things that 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 a hundred percent with you. You hit every nail.” So when Manning approached me and told me, we read your article and we liked to expand on it. We turn that into, essentially, the blueprint of a developer’s career based on lessons I’ve learned through those 18 years. This is kind of a road trip through my list of 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, it’s part of the journey. And two, there is a 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 at the heart of everything we do as developers. When you started, you said solo developers, right? Unless you’re coding yourself for a piece of software that only you are going to use, you’re not a solo developer. Right now, we share our code in GitHub. We share it with everyone. Even if nobody’s following, even if nobody is interested right off the bat on something we’re doing, Google is there indexing everything. I mean, our code is going to get found out eventually even if we don’t want to. We may get feedback. We might get people forking our 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 wrote my code and it works for me and that’s it.

[00:11:13] Henry Suryawirawan: Interesting perspectives in the sense that even though you think you are solo developers, right? Like you’re just building POC project. But the moment that you share it either on GitHub or maybe just publish a blog post that you think others would not read, things can get picked up automatically by search engine. And maybe some random opportunities that people just randomly see your code and see that actually how well your code is written.

[00:11:34] Everyone Can be a Successful Developer

[00:11:34] Henry Suryawirawan: But maybe in the first place itself, right? I read the first chapter of the book, and you kind of like started interestingly, by saying that all of us can be a successful developer. 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 life cycle. So can you maybe share a little bit more your thought process around this?

[00:11:54] Fernando Doglio: Absolutely. So I tried 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 develop. It’s just a matter of understanding how code works from the user perspective, and what commands you need to run. 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 reading a tutorial or by watching a YouTube video. That’s all you need. What I’m trying to say in chapter one 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 be determined enough to 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. Coding comes with time. You can’t really do a certification and say, “Well, now I’m developer.” That part of learning the code, learning the paradigms, learning how syntax works. That takes time. The key traits that you have to have are others, are soft skills that if you don’t think about them, they’re not going to develop. 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 successful developer. 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 World. You’re a developer. You did it. That’s it. The rest of the hard skills is expanding all of that. You showed yourself that you’re able to learn something new and you’re going to be doing that throughout your entire career. You learned that you’re able to make a switch from whatever you were doing today, and you 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 I try to explain in chapter one.

Don’t get me wrong. I’m not saying that formal education is not needed. I taught myself how to code when I was 14. I did the whole high school and then college thing, and I dropped out of college because I had a job already, and I tried to pursue that. But eventually, I realized I actually needed that formal education later in my years. And I went back to college and finished a technical degree. Why I did that? Because definitely, I think there’s a value to formal education and there is value to a certification that you can have an understanding that software delivery life cycle completely. But you don’t need them to get started, and that’s kind of what chapter one covers.

[00:14:47] Tips to Work Well in a Team

[00:14:47] Henry Suryawirawan: So, then in your case, after you have gone through all this experience, learning by mistakes, like what you mentioned, what do you think are some of the biggest tips for software developers to think about whenever they want to be able to work well in a team setup?

[00:15:01] Fernando Doglio: So the first thing they need to understand that they’re not alone. Whatever they’re doing and the decisions that they’re taking around their code will affect others. That’s also the main point around the topic. If you’re a perfectionist and you want to get your code perfect, which is something that doesn’t exist, really, you’re affecting the timeline of your project. If there is a dependency of another task, for instance, another developer is waiting for because you haven’t finished yet, you’re affecting their work. If you’re not careful enough, and you’re not writing a unit test for instance, or paying the right attention to unit tests and 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 others. That’s also the main point.

There are multiple topics I cover here regarding trying to over-engineer a solution, right? I mean, who of us haven’t really fallen 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.

[00:16:35] Avoiding Overengineering

[00:16:35] Henry Suryawirawan: So on the last topic where you mentioned over-engineering, I think most of the developers love to do this in 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?

[00:16:55] Fernando Doglio: You have to be objective. I mean, the main problem you have, and the main reason why 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 that we have to build. And then we think, well, this is good, but I can do it better and I can do it better. This is great. I have the perfect solution. I’ll just implement it. I’ll take as much time as I need. You never thought about, well, what about the others? What do the others actually need? That’s the main thing. 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 their head above the laptop and look out. We’re just so focused on what we’re doing, the code we’re writing, that we forget to look around us. We might have a 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 to it, you might come back the other day and hate it. If you draw, if you paint, that’s also a common issue. You think you did something amazing, and you come back the other day and just throw it away because it sucks. The same is with our ideas. We 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’re just thinking 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-engineering. It’s more like avoiding over-engineering at all. Try to look at it from another perspective, not just yours.

[00:18:29] Henry Suryawirawan: So when you mentioned 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?

[00:18:43] Fernando Doglio: Absolutely. I mean, it’s all that and everything else, except your problem. The timeline is going to be affected if you can’t deliver it on time. 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 version and the rest of the team.

The requirements gathering as well. If you’re jumping from solution to solution, bigger and bigger, if that turns out to be over-engineered, you may even be making assumptions about future requirements. To bring an example, you have to build like a login page or the login service for your app. You have a lot of alternatives. There are a lot of variations from simple user password validation 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, or don’t state the fact that, for instance, you need single sign-on, then why are you implementing that? Are you assuming that’s going to be needed because in the future you’re going 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 going to need this? Because in the future, we’re going to build that. Your manager, your tech lead, whoever, might come back and say, well, actually, you know what, that’s a great idea. Let’s do that, and let’s adjust the timeline because we need extra time. That’s not overengineering. But if you don’t do that, you don’t validate that, you just assume so, you’ve overengineered a solution that should have been a lot simpler. That’s the point.

[00:20:30] Focus on Working Code First, Then Optimize It

[00:20:30] Henry Suryawirawan: And this is also kind of like related with another tip of yours, which is to focus on working code first. So when you start working on solving a problem, you should probably aim to make it work first. Maybe you can elaborate more on this point.

[00:20:42] Fernando Doglio: Absolutely. That also speaks to not only over-engineering but also early optimization. That’s another trap that we like to fall for. Getting everything perfect and working in the best possible way that it 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 is any bottleneck where it is, and then optimize. So if you’re going the other way around, if you put in the cart in front of the horses, then you’re assuming that you’re going to have problems. You’re assuming where the problems are going to be, and you’re assuming how 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 solves a problem. I don’t care if it looks good, if it works great, does it solve the problem? The main questions you’ll have to ask. If it does solve the problem, then start making it prettier, clean it up into multiple modules or whatever. And then, once that’s ready, and the code is readable by others and the code is useful and reusable even, then start measuring it. Does it perform correctly? Does it 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 code doesn’t really exist. There’s always going to be something that throws your whole set of assumptions. The moment you don’t see that, when you stop seeing that, you’re stuck in an infinite loop. Always optimizing something that doesn’t really need to be optimized.

[00:22:15] Henry Suryawirawan: 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 test? Any kind of experience you have here on how should people measure their code first before they optimise?

[00:22:34] Fernando Doglio: That’s very varied. I mean, I can’t really give an example of one way that will work for everyone. Because you have environments where writing an algorithm that can run in your laptop is big enough of a test or good enough of a test to understand if it’s performing or not. But if you’re working on microcontrollers or if you’re building something that is super time sensitive, then you probably need to run on the environment that it’s going to be deployed, to be a hundred percent sure that it knows how to deal with all the intricacies of that environment. If you’re building something that needs to be distributed, then you need to understand how it runs for a set of nodes or initial cluster configuration, 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 measure 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 are, 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 end counter at the end of that whatever function you’re trying to test, and see how many seconds that took? How many 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 varied. It’s unique to your context.

Again, no generic example here. But that is what you need to understand. You need to understand that, one, you’re going to measure it. Two, what KPIs you have to measure? And then Three, try to find a way to measure those KPIs without affecting the performance so much that the mere effort of measuring affects the performance. That’s another big thing. But if you manage 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 threshold, then great. You’ve made it. Otherwise, start tweaking based on that. But if you have that, you have half the battle won because you’re ready. You’re basing everything you do from now on, on reality. You’re not assuming anything and that’s major.

[00:24:46] Writing Readable Code

[00:24:46] Henry Suryawirawan: And you have mentioned a couple of times about readable code. Code that is maintainable. I think this is also one big part of being a good team player for any developers out there is that your produced 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 code understandable by others?

[00:25:07] Fernando Doglio: I always like to say that code needs to run on 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, the 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 an 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 a million times. If we can’t even rely on our memory to understand what we did, how can we really expect others who have not gone through the ideation process for that algorithm to actually understand that 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 might solve a problem with just a single line, but might need to be mentally parsed. 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 code. And that means most of the times, we’re mentally parsing the code and mentally executing it to understand how that works, or how the 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’re going to spend looking at a block of code if you want to modify it in the future. It’s not that hard, honestly. I mean, a well-written comment might solve all that problem. So things like commenting 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 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 will be like looking at two pages from the same author. You know how that author writes, and you know where to find the key bits of information already because it follows the same standards. That’s the why you have to also think about humans when writing code, and make it readable for them.

[00:27:55] Henry Suryawirawan: I love the way you explained it in 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, it 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 coined the phrase “mentally parse it”. I know there are some jokes like, maybe the amount of WTF when people reading your code. Might be one gauge of like mentally parsing it so hard. Right? Thanks for the analogy here.

[00:28:26] Tips on Technical Interviews

[00:28:26] Henry Suryawirawan: Another chapter in the book, I think you cover a lot about technical interviews. For example, the first is from the employer’s point of view, right? What we should look at in terms of assessing candidates, whether they could play well with others?

[00:28:40] Fernando Doglio: So yeah, the interview process is very interesting and filled with interesting insight that both parties get. I like to think of the interview process as 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 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 buzzwords, 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, Vue, Angular, JavaScript, you’re not telling me actually what you did with them. I might think that you’re just putting in things because they sound about right. But at the end, you might have read a few articles about React, played or done a few POC with Vue, and have been working for a few months with Angular. That’s actually what I want to know. So you got to the interview, but you incorrectly set the expectations on the interviewer. And that person’s going to be really disappointed with your profile. When if you had set the expectations right from the get-go, that person would have tackled the whole interview differently. Maybe would have been impressed with your actual knowledge.

So, that’s a big thing. Especially if you take it further, lying in your resume, which is also something that sometimes developer tends to do. It’s a big no-no in my opinion. Because you might get lucky, and you might get an interviewer who doesn’t really care about one particular aspect that you lied about, and will not even ask about. 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 crashed just because you took it a bit further. So that’s also something that from an interviewer’s 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 buzzword 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 point of view that can be seen essentially.

[00:31:25] Henry Suryawirawan: Interesting. And what about from the interviewee aspects? So you mentioned in the chapters, few examples that actually interviewees should not say, or should not show it whenever they go through this technical interview, right?

[00:31:38] Fernando Doglio: Well, saying something like, “I’m a 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’t really pick up Vue or Angular or any other JavaScript framework? I mean, this is JavaScript we’re talking 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. But saying I’m a React developer or a Java developer, then what does that mean? You can’t really pick up another language? Can you pick another language within a reasonable amount of 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 like, well, I work only on Linux because Linux is the best development environment, and Windows sucks. Yes, every piece of technology is going to be better than others in different contexts, but that doesn’t mean you can’t make it work. I love working on Linux for any development tasks, 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’t really open your mind to others?

That’s also a big problem to me when an 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 a hundred times better. Are you telling me you’re not going to make the switch just because you love React? You’re going to 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 other things that you’ve never seen before. There are probably other things. The list could be a bit longer, but yeah, that’s the main.

[00:33:49] Henry Suryawirawan: Thanks again for reminding us not to put ourselves in the box, and always to try our best to solve the problems given, even though you don’t know the technical jargon, you don’t know the algorithm, you don’t know the buzzwords. As long as the principles how you use the thought process to solve the problem. I think that probably is the most important thing that the interviewer is looking for.

[00:34:07] Tips for Writing Technical Books

[00:34:07] Henry Suryawirawan: So Fernando, I’ve looked at your profile, right? You seem to have written a lot of books, actually. I think if I count correctly, four already published about NodeJS 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 there are some people who wonder themselves, right? I want to write a book, but never seem to be able to get it done. So maybe you can share your experience in this.

[00:34:32] Fernando Doglio: Well, yeah, absolutely, and I was one of them as well. The main thing that has to happen is that you have to understand that anyone that writes a book is not an expert of that technology when they’re starting to write the book. So there’s this misconception that a lot of authors are experts and they know everything about their subject. That doesn’t necessarily have to be true. It may have been some situations that that’s absolutely correct. But many times it’s just not. They’re just good at researching, you know, and learning. Personally, the first book I wrote about REST API design for NodeJS, I started that book with that misconception. I was sure I knew everything about REST, and that I was able to write a book because of that. Through the process of expanding the chapters I had planned, and through the process of researching and learning 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 that also taught me that I don’t have to be the expert to write the book. I just need to understand how to do proper research, and then how to explain that research essentially, in a interesting manner. That’s not easy at all.

I’m not saying it’s easy or simple. It just the moment you realize that you don’t have to be the expert. You start thinking, well, then I can do research. I’m always learning about new things. Then I can try to explain things. Even if you’re now writing blog posts or articles and you’re afraid of taking that next step into a book, 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. Understand that you’re capable of doing it, that you don’t have to be that experienced 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 no 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’ve made up your mind and say, well, I’m going to write a 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 trying to come up with the idea of what’s 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 of content. 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 worked with and I’ve 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 these publishers will not really care about them or about their book ideas because they’re not big Twitter celebrities or big names in the development industry. And again, that is not the case. They care about the content. If you don’t have a big following or if you’ve not worked on big process before, that’s not a problem at all. Most of them are super open to helping authors, new authors, and walking you through the whole process. So it’s actually a lot less painful than a lot of people think.

[00:38:13] Henry Suryawirawan: Wow. Thanks for all these insights. So there are a few key things that I picked up here. The first is that, of course, you don’t need to be 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. At 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 the publisher if you have a 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.

[00:38:58] Fernando Doglio: Correct. Some publishers may ask for, like, a single written 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 lot 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’ll write it. You’ll be the author of the book, and you’ll take care of writing all the contents. But there are going to be at least one, some publishers have a lot more, reviewers of your work. Technical reviewers and other types of editors that will give you feedback way before that chapter gets delivered to the public. 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 filters, you’ll get feedback in the way you explain things in the actual topics that you cover. So, you’ll be able to polish that chapter through that process, so by the time it 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 a lot of people realize is there for you.

[00:40:36] Henry Suryawirawan: Yeah, that’s also a very key thing. I was about to ask, what if I didn’t know how to write properly? Or my English sucks, for example. So thanks for reminding this, that actually you are not alone, right? There will be people along the way that can help to review or edit some of the stuff that you wrote. At the end of the day, it’s a teamwork. Again, even though you are a single solo author, right? There are a number of people helping you along the way.

[00:40:56] 3 Tech Lead Wisdom

[00:40:56] Henry Suryawirawan: So thanks Fernando for this time. I really love our conversation and learning a lot from you. But unfortunately, we have to end the conversation due to time. But before I let you go, I normally ask one question for all my guests, which is to share your three technical leadership wisdom so that people can learn from this wisdom.

[00:41:13] Fernando Doglio: All right. Okay. So three. The main thing would be, and I usually recommend this for leaders and non-leaders actually, everyone is to leave your problems at the door. This was a piece of advice I got in, I think, it was my first job. 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’t really stop thinking about personal problems and start thinking about work problems. If you are able to make that separation, that split, 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 that 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. There’s this confusion. You think that you’re there because you’re responsible for every single decision, the project, and that’s not the case. You have a whole team around you that is doing and is working on the exact same project that you are. They will probably have a lot of better ideas than 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 valuable interaction inside a project is when someone disagrees with the leader, because they probably have a better way of doing it. They might be right or not, but that disagreement will spark a 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 that you 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 backgrounds, and not every culture is okay with disagreeing with leaders or disagreeing with authority figures. So it’s sometimes a bit harder than others to make sure that whoever 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 the previous 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 technical knowledge of the team. You’re not 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 other people on the team have. You probably have the best soft skills, you have better planning skills, but you’re not necessarily the most technical of them. So it ties 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 technical decisions 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 a very different type of task, and just understanding where that space is for you. Leaving the rest of the responsibility to a team.

[00:45:28] Henry Suryawirawan: Wow. 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 a bit… So Fernando, it was a lovely conversation. When can people expect to see your book? Like the “Code Well with Others”?

[00:45:44] Fernando Doglio: So, yeah, the book’s already available in Manning’s Early Access Program, the MEAP. So they can already get it, look for it on Manning’s 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 are already finished. But it’s not on MEAP 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 their feedback, and then we’ll 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 MEAP program, you’ll get updated every new chapter, every time a new chapter is released. Otherwise, in the next few months, the full book will be available through the website and other common channels.

[00:46:35] Henry Suryawirawan: Looking forward for that. Good luck with the process. So hopefully we can be able to see the book soon.

[00:46:40] Fernando Doglio: Thank you for having me. I mean, it was really fun and entertaining.

– End –