by Will Larson29 Dec 2022 ★★★★★
Why I read this book: A colleague recommended it to me as a good guide for navigating the corporate life as a developer.
How I read this book: I listened to the audiobook version while doing various chores around the house. I tried to focus on the chapters that contained the “theory,” but I allowed myself to listen more loosely to the chapters with the interviews.
What I liked about it:
I’m glad that books like this exist. Even if one isn’t aiming to become a staff engineer, this book is a good guide on how to orient oneself professionally. It talks about different ways to be a senior software engineer (mostly tech lead vs. specialist) and I think it’s useful to understand as early as possible which works best for you. It also paints a picture of what responsibilities look like later in a career.
I have two stories in my professional life where I failed rather miserably. One was about trying to hype up my peers about setting up our monitoring system and fighting false positives. The other was about building a complex piece of software that I didn’t realize was this complex when getting into it. Even though there was no direct advice on handling such problems in the book, the overall flow described in, for example, “Manage technical quality” made me realize what I did wrong in those cases. I’m used to rather small tasks where I can just start coding straight away, but some problems require a lot more preparation, communication, and planning in advance.
While listening to the audiobook, I googled the author and found his blog at https://lethain.com/. It has several good posts on it. Some of my favorites are “Hard to work with” and “Lessons not worth learning.”
The book came to me at an interesting time. I’ve been down with a cold on and off for more than a month now. I sometimes took sick days and sometimes tried to work through it, which left me quite drained mentally. Finally, I took a week off to move between apartments, and throughout all the chores of moving, I listened to this book. It usually put me in a certain mood as I started to think about my work and my relationship to it, and the relationship that the people interviewed in the book seem to have with a very similar line of work. I haven’t come to any meaningful conclusion yet, but the thing that caught my attention the most was that a lot of the staff engineers interviewed in the book talked about finding the type of work (within software engineering) that energizes you. As the author points out in another good blog post of his, things that bring us joy sort of create more time in the day as we wouldn’t be able to do more things if we’re in a bad mood or feeling drained.
I liked that the staff engineers interviewed in the book are rather diverse. They shared their experience of how being part of a minority affected their career path. For most of them, it was impostor syndrome. Someone described it as “only feeling ready to do something when you’re absolutely sure that you’ll be able to.” This is definitely a problem I have, too, and it was nice to hear someone assure me that it’s also okay to take on projects I have no idea how to implement at first.
I like that the book is also available as a website. I wanted to revisit some chapters I couldn’t properly concentrate on in audio format and was pleasantly surprised that I didn’t have to buy a paper copy to do it. I also saw that the author has another book, “Infrastructure Engineering”, in the works, and there is already a website for it at https://infraeng.dev/. It seems to have an outline for the entire book and only some chapters filled in. This is a very interesting way to work on a book.
What I disliked:
One of the things that prevents me from wanting to advance in my career is the fear that having more and more responsibility would ruin my work-life balance, as I would constantly be so stressed that I couldn’t stop working or thinking about work. I wish this topic had been addressed in the book in some way.
What other resources the book pointed me to:
- All the interviews list the staff engineer’s name in the title, which makes it easy to look them up. I think I’ll research them more in depth later, but the one person who caught my attention was Keavy McMinn, as she writes about the process of approaching complex problems.
- Many people praised Lara Hogan. I added her book “Resilient Management” to my to-read list.
- One of the staff engineers mentioned reading the Programming subreddit to stay up to date with what is happening in software engineering. This wasn’t the first time I heard someone say that, but now I finally took the time to download the Apollo app for browsing Reddit on iOS and will try to make a habit of it.