hey. Ricky, great question! I think I mention the importance of communication throughout the book, but I really make a point of it by the end, chapters 7 and 8. During chapter 7 I cover the importance of communication with your team and your manager in multiple places. As for the “business”, I do cover the subject of talking with clients from a consultant point of view. I do not cover the importance of effective communication with the business inside the company, if that’s what you were asking for.

Thanks Fernando, that’s good to know.

Hi James, thanks for the question! I honestly can critique those books since I haven’t read them. While I do have some chapters that cover coding and best practices, the focus of my book is not “just that”. So I do go into some details about best practices in general, and in regards to unit testing, but then I keep going into other topics.

And as for your question of whether or not best practices evolve over time, I tend to agree there. Different architectural patterns either created, or re-discovered over time, and that brings light into different ways of tackling the same problems.

when it comes to soft. development I would never say “there is one way to do this right” about anything really.

Thank you!

Hey Di_hash! Great questions!

1. It’s actually both, I do cover some tech points, but most of them are not technical, the focus is the overall journey of a developer.
   
2. The main one would be communication. I neglected it thinking I should only focus on my tech skills. Eventually I realized that without being a good communicator, I would not be able to grow in my career.
   
3. Yeah, I’d say that this is one of the core principles at the center of my book.
   
4. Well, I certainly hope so! 🙂 Of course, it’s all up to you, reading the book alone will not make you better, you have to interiorize the teaching, and apply the lessons. It will definitely help you jump a few years ahead of everyone else at you same level, that’s for sure.

Thank you, i appreciate your clarifications

thank you for the great questions!

Hey Saba, that’s a tough one. Mainly because the way I deal with “gatekeeping” is by ignoring it, but I understand not everyone can do it. My advice would be to keep reaching out to people until you find a positive support group. Internet is filled with developers looking to help others, some even specialize and create a lot of content and have a lot of advice for people switching careers into tech, if you run into gatekeepers, just turn around and keep looking.

And if you don’t know where to look for these people, I would suggest reaching out to content creators that produce content around your areas of interest and asking for supportive communities, they’re probably exposed to multiple ones.

1. This one is a tough one, because it depends on what you mean by “future”. I think on the long run, AI will definitely affect our jobs. Not replace us, mind you, but at least it will change the way we code. Allowing us to keep moving up on the abstraction layers, like you put it.
   
2. As for staying up-to-date with all the frameworks out there. that’s impossible, and I don’t think it should be anyone’s aim. Instead, you should aim to master the basics. No matter what your industry or area of expertise is, you should aim to understand the core of programming, and then you’ll see that picking up new frameworks becomes second nature. Focus on understanding how different paradigms work, learn about data structures and algorithms… learn about architectural patterns. The language is irrelevant and the framework even more. Once you know what MVC is (for example), you’ll start seeing it everywhere.

there is no magic formula for a balanced work-life scenario. Sadly. Everyone has different burnout limits, and I think it’s important to be aware of them.
The main thing is to remember that you’re need other things in your life other than your work to be happy, and that it’s OK to not know everything.
At the rate at which new technologies are developed, it’s impossible for a person to know everything and to have experience with everything, so you have to be able to draw that limit and say “here, I’m good here”, and learn to enjoy things other than coding, that way hobbies can take you out of your “work” mental space.

Hey Moritz, thanks for the question. I guess we could say 90% of the book is based on personal experience but there are other areas where I just present my ideas on how it could be improved. Problems like gatekeeping are very visible if you’re active on any social network where many developers interact with each other, you can see so many people trying to help others and some developers trying to prevent them from moving forward by imposing their own ideas of whats “right” or “wrong”.

In the case of gatekeeping, I tried to show what I think are the best ways to move around it and most importantly, to be aware of it, because sadly internet is not filled with developers helping developers.

Hey Hyoson, thanks for the question. I wouldn’t recommend my book to this person. I didn’t write it with that kind of profile in mind, and if they’re already leading teams with no intention on becoming a developer, then the book really wouldn’t do them any good.
That said, bridging the gap between a non-technical lead and team members is hard, because sometimes it might seem like they speak completely different languages. The lead will usually have concerns about timeline, product delivery, reaching milestones, and if they’re not technical they will have to trust their team when it comes to tech issues (like generating/spending time fixing tech debt, time estimations, bug reports and many other areas). This person will have to actively look for advice from the team, or at least, from the senior members of the team.
From the PoV of the team members, they’ll also have to try and find a way to have an open dialog and accept that this person’s experience leading teams, even though they lack tech skills, might help them be an effective leader regardless. Sometimes tech folk tend to not show the same level of considerations or respect to non-tech leaders than what they would show to a senior technical person who becomes a leader. That has to change, if this person is leading the team, they deserve the benefit of the doubt.

At least that’s how I would try to approach the situation from either end.

I appreciate your thoughts on the matter! There is indeed some tension in our group due to the issues you mentioned and it hasn’t been addressed directly yet, which I think it should.

yeap definitely, all cards on the table , that’s the way I like to do it anyway.

great questions!
Let me start in reverse order:

1. Writing did the trick for me. I started writing articles online, and that helped with my english and my ability to explain complicated concepts in simple ways.
   
2. I’m not sure I understand this one, if by “high quality in your production code” you mean MY actual code, I can’t, but that’s because as a tech lead I don’t code. It’s been my experience that as a tech lead I’m too busy with others managing tasks (estimations, client management, team management, etc) to be able to have enough time to code myself. Considering all the tasks I have at hand, it would be irresponsible to put coding tasks on my backlog as well, I wouldn’t be able to deliver them on time.
   
3. I would say they’re not technical. Communication and empathy are two big ones on my book. Tech people tend to be really bad at those, some of them like machines more than people, so they don’t focus on developing their communication skills, specially early on. Being able to interact with them in a way they feel heard, and then turn around and talk to the business in a way they understand what’s happening is a key skill any lead should have.
   
4. I’m not sure I understand this question either, can you elaborate a bit more? Maybe have a sample scenario?

Fernando Doglio thank you for your answers. Seems like I wasn’t very precise in writing down my questions 😉

• Concerning question 3, yes, probably the lead does not code anymore. However, he/she will have to ensure that the products are running at all times, that there are no bugs and that the code stays maintainable. It seems to be that many junior developers are struggling with these objectives. How can you help junior developers grow and get better and avoid creating a mess in your products on the way?
  
• Concerning question 1, as an example, if your organisation has a data science team and a team with developers. The data science team creates models which produce predictions that should be displayed in a web application with a nice user interface. The web application is created by the developers. The data science team provides an API for the developers to use. For this purpose, a lot of data has to be shared between the teams. For example, how should the predictions be presented? Also the model might change over time, the inputs and outputs might have to be adjusted from time to time which needs to be communicated between the teams. How would you manage the interaction/communication between the teams. Or would you design the whole setup differently?

Hey Dustin, great question! Interestingly enough, I cover this topic on chapter 1 of the book. The whole premise for the book is that the skills that make up a successful SWE are not technical. In fact, they’re mostly soft-skills. Technical skills differ from project to project, but you’ll always be dealing with people.

Hey Ajay, great question. I would suggest starting to create technical content. My go-to would be written content, but if the aim is to stay close and up-to-date with code, you can do anything you like. Through this process you’ll be able to play around and get to know the latest trends in tech and you’ll have to become great at explaining concepts and transmitting that information to others.
This way, you get to see and experience new technologies without having to spend months working with them. If you have enough experience as a developer in general, that should give you all the tools you need to keep being a great leader and avoid falling behind trends your team is not using right now.

thank you 🙂