This is not the first book of Gergely Orosz, author of The Pragmatic Engineer newsletter, but this is the most general one so far. Before this one, he wrote books that targeted much narrower topics, such as how to write a scalable mobile app, or how to write the best CV, something I both used and reviewed earlier on this blog.
While the subtitle of The Software Engineer’s Guidebook is Navigating senior, tech lead, and staff engineer positions at tech companies and startups, the book is clearly not only for people in the later stages of their careers. This book is useful for junior or medior engineers as well because they can learn about how their jobs would change in later stages and what patterns will help them to excel in those positions. They will learn about what patterns will help them get there.
The first 2/3 of the book will definitely help everyone to get better as an engineer and the last parts will rather help you understand what your team leads, and staff engineers do and what are their priorities. I used the word engineer on purpose. I don’t think this book help you become a better coder. There are more suitable books for that purpose, but this book is rather about how to be a successful engineer people want to work with.
The structure of the book
Let’s have a look at how the book is structured.
The first part - which is the second longest one in the book - is about developer career fundamentals. In this part, the author covers different career paths, different kinds of tech companies and how to thrive in those different environments, how promotions go and why to switch jobs.
In the second part, he writes about the competent software developer, who gets things done, who knows how to code well and how to get there and who uses the right tools to be efficient.
In the third part, the well-rounded software engineer is in focus. At that stage of your career, getting things done the right way is not enough. More and more collaborative and architectural work will be expected from you. Of course, this can vary based on the type of tech company you work in.
The fourth part covers the responsibilities of a tech lead. Of course not only the responsibilities but also lots of pieces of advice about how to project management better, how to deal with the stakeholders and even though as a team lead, you’re not a people manager, it’s better if you understand how the team is structured and how the dynamics work out, even if you’d need the help of the EM to deal with certain situations.
Before the conclusion, in the fifth and longest part of the book the role of staff or principal engineer is covered which is way beyond coding. While staying in touch with the code as a staff+ level engineer is important, you’ll also have several tasks in the realm of architecture and strategic alignment.
Three key ideas
This book is very diverse and dense. It tries to cover a bit so many different aspects of your job, such as how you should manage your career (and your manager), what to pay attention to when you write code or how to approach testing. Each of these topics could fill books. Moreover, it doesn’t only cover one job, but at least two if not more. I think that the job of a junior and senior engineer is very similar, even though there are obvious differences. But in my opinion, there can be a bigger difference between the tasks of a senior and a staff+ engineer or a team lead.
Hence, I also find it difficult to write a well-rounded review of the book. It’s often not about giving advice, but just sharing information about how different kinds of companies, environments work. I’m not saying that it’s a problem, it’s very useful, but it makes it more difficult for me to pick three ideas.
So I decided to share 3 ideas in the book that are sometimes also the names of chapters, but they are running through the book in a deeper level.
Own your career
Maybe this sounds obvious, yet I met so many people who didn’t do much for their career, but they complained that their manager doesn’t do this or that for them. It’s you who are in charge.
One thing I learned from The Software Developer’s Life Manual by John Sonmez back in time and this book also brings up is to make a work log. At the end of the year, or whenever when you have to provide a self-evaluation, it’s difficult to remember back at all those problems you solved. Unless you take note of them. If you keep a work log, like a diary where you list all the important things you achieved during a given week, you’ll be able to write a much better self-evaluation and therefore you have a better chance to have a more favourable performance review.
Another paramount thing to do - though it might sound frightening at first - is to ask for feedback. Even if you don’t have to. Even outside of performance review time. After a critical meeting, you might reach out to some people who you trust to share their views on how you ran the meeting. Or after a project (milestone) you might also ask the others to share their opinion on your work. Try to ask specific questions to help your colleagues give you feedback. Oh and also act on the feedback. You don’t have to take everything, you don’t have to agree with everything, and you can even express that, but if you keep asking for feedback and you don’t change anything, people will stop giving you feedback and probably they will also find you a bit rude.
It’s also important to make your manager an ally. They should see you as a person who delivers and is clear on your goals. If you need something, information you cannot figure out or some help, ask for help. But don’t just be someone who only asks. Try to understand your managers pain points and struggles and help them. It will greatly improve your relationship if you can proactively help them.
But probably most importantly…
…get things done!
If you take on a task, finish it! “Deliver it with high enough quality and at a decent pace.” Ideally you should regularly work on impactful activities.
I remember that when I was earlier in my career, I was convinced that people were aware of the great job that had done. Well, maybe it was not so great, but even more importantly, they were often not aware of my achievements - including my manager - and that of course didn’t help in the performance reviews. You have to actively and shamelessly communicate about your achievements. Something that might feel unusual in many cultures and it can be even stressful in the beginning. Maybe even later…
Always try to underpromise what you’ll do and then overdeliver on a timely manner and take the opportunity to overcommunicate what you just did.
At the beginning of this section, we mentioned the word impactful. But what is impactful? That’s hard to tell, but don’t forget that you’re goal is not to write some nice shiny piece of code. The real goal is to solve the business’ problem so that it can achieve its goals, which is making money if we talk about for-profit companies.
In order to do that…
…be a product minden engineer!
You cannot be one if you don’t understand what business your employer operates in. You have to understand how money is generated.
To become a product minden engineer, you have to both identify and understand your customers, what are their needs and what satisfies them. After all, why do they use your product?!
If you can have 1-on-1s with product managers, or with people from the business that will help! They might be surprised at first because not many engineers are interested, but generally, they are happy. If you can talk even to the customers, that’s simply grand!
By understanding these aspects, you can become the person who doesn’t simply solve problems, but also finds them! A major difference between senior and staff engineers!
Conclusion
The Software Engineer’s Guidebook is a great asset to any engineers library. If you’re a junior or medior engineer, I’m sure that you’ll learn about many concepts that can accelerate your growth. If you are more of a senior person, you might think first that oh well, you know these things well. Still, I think there is value in the book. First of all, it helps to organize your knowledge. Second, it will probably make you think and revisit certain patterns you follow. But I’m almost 100% sure that you’ll also read about ideas that are completely new to you. A recommended read.
Connect deeper
If you liked this article, please
- hit on the like button,
- subscribe to my newsletter
- and let’s connect on Twitter!
