Seeing a lot of praise for Gergely Orosz’s “The Software Engineer’s Guidebook”, I was pleased when I found the book under the Christmas Tree. Unfortunately, in my opinion, it does not live up to the hype. The book, not the tree.
I’m not sure who’s the target of this book. It consists of a “career fundamentals” intro, four chapters, and a conclusion. Each chapter is intended for an engineer being on a specific level, starting with “the competent software developer” and ending with “role-model staff and principal engineers”. If you’ve spent more than a year or two as a programmer on an at least mediocre team, you should already know everything that the former describes - testing the code, thinking about the edge cases, refactoring, or configuring the IDE. If you are a competent staff+ engineer, the first two or three chapters may bring no value to your day-to-day work.
That’s the general problem of “TSEG”. Whenever it tries to focus on the technical aspect of the programming job, it just falls short. There are multiple paragraphs on tests, flaky tests, and testing pyramids (or DDD), but they can be treated as an incentive for further reading at most. I felt like I was reading through filler material when I stumbled upon the “frequently used tools”. Another example - tech debt. What’s the author’s advice for tackling it? Well, just write code that’s easy to read, make time to clean up the code, etc.. This feels a bit too shallow for me. And it was a part of the “Well-Rounded Senior Engineer” chapter.
If you’ve been a follower of Orosz’s well-established newsletter, “The Pragmatic Engineer”, you may feel like you’ve already read some parts of the book or seen some figures. Not that it’s bad per se, but some might expect the book to be original content only, especially if you paid for both the newsletter and the book.
After the above criticism, I have to note that there are some gems in the “TSEG” that make it worth reading through. These are mostly parts describing the social aspect of the tech job - mentoring, stakeholder management, or one-on-one meetings. They consist of useful taxonomies and classifications, hell, there are even ready-to-use recipes on how to keep people in the loop on a project or conducting an introductory mentoring meeting. This, I suspect, may not be common knowledge among fellow engineers, but it may (and will!) come in handy one day, and “TSEG” makes a brilliant reference. Pick any chapter on team dynamics or politics and it should be a worthwhile read. This contrasts the previously mentioned refactoring bits of advice.
There’s one “social” aspect, important for more experienced engineers, that should have been described more thoroughly - I’m talking about burning out. The whole book gives a notion of the necessity of constant self-improvement, countered by the “give yourself a break sometimes” paragraph literally on the last page of the book (excluding the acknowledgments).
I haven’t canceled my newsletter subscription or sold the book as they are both valuable sources of knowledge. However, I’m underwhelmed with “The Software Engineer’s Guidebook” content. It’s a guidebook targeting engineers, so I expected more depth in the technical chapters, but these provided me with little to no added value. These are just the filler before you get to the main course, i.e. collaboration, teamwork, team dynamics, etc.