What do you think?
Rate this book
The Software Engineer's Guidebook: Navigating senior, tech lead, and staff engineer positions at tech companies and startups
In my first few years as a developer I assumed that hard work was all I needed. Then I was passed over for a promotion and my manager couldn’t give me feedback on what areas to improve, so I could get to the senior engineer level. I was frustrated, even bitter—not as much about missing the promotion, but because of the lack of guidance.
By the time I became a manager, I was determined to support engineers reporting to me with the kind of feedback and support I wish I would have gotten years earlier. And I did. While my team tripled over the next two years, people became visibly better engineers, and this progression was clear from performance reviews and promotions.
This audiobook is a summary of the advice I’ve given to software engineers over the years–and then some more. This audiobook follows the structure of a “typical” career path for a software engineer, from starting out as a fresh-faced software developer, through being a role model senior/lead, all the way to the staff/principle/distinguished level. It summarizes what I’ve learned as a developer and how I’ve approached coaching engineers at different stages of their careers.
We cover “soft” skills which become increasingly important as your seniority increases, and the “hard” parts of the job, like software engineering concepts and approaches which help you grow professionally.
By the time I became a manager, I was determined to support engineers reporting to me with the kind of feedback and support I wish I would have gotten years earlier. And I did. While my team tripled over the next two years, people became visibly better engineers, and this progression was clear from performance reviews and promotions.
This audiobook is a summary of the advice I’ve given to software engineers over the years–and then some more. This audiobook follows the structure of a “typical” career path for a software engineer, from starting out as a fresh-faced software developer, through being a role model senior/lead, all the way to the staff/principle/distinguished level. It summarizes what I’ve learned as a developer and how I’ve approached coaching engineers at different stages of their careers.
We cover “soft” skills which become increasingly important as your seniority increases, and the “hard” parts of the job, like software engineering concepts and approaches which help you grow professionally.
413 pages, Paperback
First published November 3, 2023
749 people are currently reading
3035 people want to read
About the author
Gergely Orosz
6 books222 followersI write The Pragmatic Engineer, the # technology newsletter on Substack. Author of The Software Engineer's Guidebook and other titles. Formerly at Uber, Skype / Microsoft and Skyscanner.
Ratings & Reviews
Friends & Following
Create a free account to discover what your friends think of this book!
Community Reviews
Displaying 1 - 30 of 106 reviews
February 27, 2024
Honestly, I am not impressed by this book - but at the same time I cannot say it was badly written or waste of time. It's just "nothing new under the sun".
Definitely, the biggest advantage of this book is that it's structured and comprehensive - especially from the career guidance perspective. It has clear separation of parts and chapters, comprehensive coverage of functions and it presents all important topics and terms inside.
However, I would be surprised though, that if the advertised subtitle - saying that senior, tech leads, and staff - will feel "navigated" after reading that book. I am under an impression that provided content is not novel for those kind of people.
At the same time, I am not surprised actually that this book was so popular and presented as a revolutionary position. I think that the lone fact of structuring the knowledge helped to "sell" that image. Plus, book can be beneficial for the people aspiring to the advertised positions. But do not look for deep dives and understanding of the presented topics - it's a guidebook and in some cases, merely a dictionary of important terms.
It feels it's only that, but at the same time - it's exactly that, and it's still being helpful as it fills out the void.
Definitely, the biggest advantage of this book is that it's structured and comprehensive - especially from the career guidance perspective. It has clear separation of parts and chapters, comprehensive coverage of functions and it presents all important topics and terms inside.
However, I would be surprised though, that if the advertised subtitle - saying that senior, tech leads, and staff - will feel "navigated" after reading that book. I am under an impression that provided content is not novel for those kind of people.
At the same time, I am not surprised actually that this book was so popular and presented as a revolutionary position. I think that the lone fact of structuring the knowledge helped to "sell" that image. Plus, book can be beneficial for the people aspiring to the advertised positions. But do not look for deep dives and understanding of the presented topics - it's a guidebook and in some cases, merely a dictionary of important terms.
It feels it's only that, but at the same time - it's exactly that, and it's still being helpful as it fills out the void.
March 9, 2024
A great example of why publishers exist.
I really like the premise of the book, but it doesn’t go into nearly enough detail or provide enough actionable advice. In ways, the book feels like the syllabus one might get at an introductory course to a software engineering career: it provides an outline for how your career might look, it just doesn’t effectively help you actually perform that career.
In that sense, I think much of the book isn’t really for senior or staff-plus software engineers, but rather for junior/mid-level engineers about senior and staff engineering roles. The book does a decent job of covering the outlines of a software engineering career, and there’s value in doing that, it’s just a different book than it’s making itself out to be.
The writing is, somehow, simultaneously too personal and not personal enough. When discussing industry practices, Gergely seems to over-bias on his own experience at Uber, and I think having one or two co-authors with other career paths, especially continuing the engineering track into staff-plus levels, could have really helped give the book more weight. At the same time, when discussing strategies, the writing is overly generic and fails to leverage his experience. He will frequently avoid giving recommendations, instead just listing a bunch of techniques and ending with a tautological “use your judgement to decide which approach is best!”
If this was making a case for self-publishing, it really does not shine. The book is not very pretty, inside or out, and full of formatting decisions hurting the readability. A publisher like O’Reilly or Stripe Publishing who have excellent track records of knowing what they’re doing when it comes to shipping engineering literature would have been really helpful at beefing the book up to production-grade.
I really like the premise of the book, but it doesn’t go into nearly enough detail or provide enough actionable advice. In ways, the book feels like the syllabus one might get at an introductory course to a software engineering career: it provides an outline for how your career might look, it just doesn’t effectively help you actually perform that career.
In that sense, I think much of the book isn’t really for senior or staff-plus software engineers, but rather for junior/mid-level engineers about senior and staff engineering roles. The book does a decent job of covering the outlines of a software engineering career, and there’s value in doing that, it’s just a different book than it’s making itself out to be.
The writing is, somehow, simultaneously too personal and not personal enough. When discussing industry practices, Gergely seems to over-bias on his own experience at Uber, and I think having one or two co-authors with other career paths, especially continuing the engineering track into staff-plus levels, could have really helped give the book more weight. At the same time, when discussing strategies, the writing is overly generic and fails to leverage his experience. He will frequently avoid giving recommendations, instead just listing a bunch of techniques and ending with a tautological “use your judgement to decide which approach is best!”
If this was making a case for self-publishing, it really does not shine. The book is not very pretty, inside or out, and full of formatting decisions hurting the readability. A publisher like O’Reilly or Stripe Publishing who have excellent track records of knowing what they’re doing when it comes to shipping engineering literature would have been really helpful at beefing the book up to production-grade.
August 4, 2025
The book is very broad and somewhat shallow. It covers pretty much everything that exists in IT world. (Programming was all about making a computer to do beeping sounds, now we have scrumbans, architecture diagrams, serendipitious meetings,etc,etc,etc... sigh)
It's hard for me to tell who is the target audience. If you're are on a junior side, the book contains too much of irrelevant for you details. If you're on a senior side, the book just spends too much time of the things you already know.
There were nuggets of interesting stuff here and there, but overall this is one of those weird ones that covers everything but for no ones interest.
It's hard for me to tell who is the target audience. If you're are on a junior side, the book contains too much of irrelevant for you details. If you're on a senior side, the book just spends too much time of the things you already know.
There were nuggets of interesting stuff here and there, but overall this is one of those weird ones that covers everything but for no ones interest.
May 10, 2024
Orosz is a popular and serious technology influencer (do you read his substack?) and this book chronicles perhaps the most fraught move an engineer might make, from individual contributor to staff+ engineer or engineering manager.
Whatever the exact title is, it's the shift from when you can be expected to go from the guy who is good at solving problems with code, to the guy who is good at knowing which problems to solve with code. A lot of the lessons boil down to "hey you, did you know that you're a person working with other people?", something which may seem obvious but which a lot of programmers need a reminder of.
On the positive side, this book is well-organized, with a checklist-friendly structure that'll help you avoid making obvious mistakes. On the less positive side, well, a lot of the advice seems obvious, and I'm not sure what specific insights I took away from it.
Whatever the exact title is, it's the shift from when you can be expected to go from the guy who is good at solving problems with code, to the guy who is good at knowing which problems to solve with code. A lot of the lessons boil down to "hey you, did you know that you're a person working with other people?", something which may seem obvious but which a lot of programmers need a reminder of.
On the positive side, this book is well-organized, with a checklist-friendly structure that'll help you avoid making obvious mistakes. On the less positive side, well, a lot of the advice seems obvious, and I'm not sure what specific insights I took away from it.
February 27, 2026
I would’ve benefitted from this book much more a couple of years ago. Most of it is very fundamental but has some good insights on how to be a “good” software engineer.
June 17, 2025
I learned the most from part one of this book, "Developer Career Fundamentals". I felt as though many of the later parts were either review for me, or I lacked the context to understand them fully. This book would be great to read at the very beginning of a software engineering career, because it explains a lot about how tech companies work and provides a "lay of the land" for what to expect.
June 6, 2024
Really great reading, following a similar approach of The Manager's Path: A Guide for Tech Leaders Navigating Growth and Change where the book covers every step in the ladder to staff+ roles, highlighting crucial competencies required to progress to next levels. Very useful for engineers wanting some guidance on what to improve no matter where they are in the individual contributor ladder.
I've recently read other books like Staff Engineer: Leadership Beyond the Management Track and The Staff Engineer's Path: A Guide for Individual Contributors Navigating Growth and Change with the wrong expectations. While they are good resources on describing in detail some of the expected competencies of staff+ engineers, they don't describe as well the progress an engineer have to do in order to get there.
So I think the author here has a really unique piece of work, just what I was looking for.
I've recently read other books like Staff Engineer: Leadership Beyond the Management Track and The Staff Engineer's Path: A Guide for Individual Contributors Navigating Growth and Change with the wrong expectations. While they are good resources on describing in detail some of the expected competencies of staff+ engineers, they don't describe as well the progress an engineer have to do in order to get there.
So I think the author here has a really unique piece of work, just what I was looking for.
November 19, 2025
If you’re an old fart like me (20+ years in software) then you likely won’t get much new out of this book. For earlier career stages it’s probably worth the money, especially if you’re new in a bigger sw company as an engineer or about to enter a bigger one.
November 23, 2023
I have been a dedicated follower of Gergely on Twitter for quite some time now, consistently finding value in his tweets and content. When I discovered that he had embarked on a self-publishing journey to deliver a book centered around software engineering, my interest was piqued. This book offers a comprehensive exploration of the subject matter, covering a wide range of topics. However, it is worth noting that it doesn't delve deeply into specific technical details, and there may be more specialized books available for those seeking in-depth technical knowledge.
Gergely's book evokes similarities to other notable works such as "The Missing README" and "The Effective Engineer." All three publications predominantly target early to mid-career engineers, providing in-depth insights into what it takes to excel in the field of software engineering. I would wholeheartedly recommend reading all three as they collectively form a thematic trio that can greatly benefit aspiring software engineers.
Gergely's book evokes similarities to other notable works such as "The Missing README" and "The Effective Engineer." All three publications predominantly target early to mid-career engineers, providing in-depth insights into what it takes to excel in the field of software engineering. I would wholeheartedly recommend reading all three as they collectively form a thematic trio that can greatly benefit aspiring software engineers.
December 16, 2023
on point, with lots of great info. As someone with 20 years in the industry (with a narrower scope and view in experience) it matches a lot of what I've seen and general recommendations that I also give to less experienced engineers and mentees. Having recently taken on a principal role, I can still capture a lot from the staff+ section and get ideas for my own practice or topics to explore. Definitely worth a read and easily a title I'll share with my mentees.
January 7, 2024
I don't read that many books for work, but this one came highly recommended from many different channels, so my interest was piqued.
It lived up to the expectations quite well.
Read it if you're a dev.
Gergely explains differences between different kinds of tech organizations, career paths, seniority levels, and how to act accordingly.
It lived up to the expectations quite well.
Read it if you're a dev.
Gergely explains differences between different kinds of tech organizations, career paths, seniority levels, and how to act accordingly.
December 3, 2023
Probably will go back to this tittle in the future.
June 1, 2024
Writing software promises a career full of intellectual challenges, never-ending learning, and collaborative projects. Yet sometimes, the career path can seem arduous and hidden, especially for those not on the management track. How can engineers lead when they’re not managing a team? In this book, Gergely Orosz shows how engineers can establish a career, progress to senior level and tech lead, and then move onto principal or staff engineering roles. None of these roles involves managing direct reports, but these positions all involve making a progressively larger impact through engineering work.
Like all books in the Pragmatic Engineering series, this guide is eminently practical; that is, it is borne out of experiences in the modern tech workplace. It addresses venues ranging from small startups to Big Tech. It discusses universally accepted expectations across companies while exploring where different companies might approach nuances uniquely.
As a software developer, this book helps coach me through situations that my manager or colleagues cannot. It gives me targets to work towards that come out of larger industry experience instead of just my particular company. It also equips me to better coach fellow developers about how to develop their careers. This coaching role is particularly important in leadership because leaders develop others first and foremost.
Those involved in software engineering comprise the primary audience for this book. It’s written for those in the field by someone with longstanding, firsthand experience in the field. Teachers and academics can benefit by understanding how to equip their students to dive into fulfilling careers. I’m not sure there’s a whole lot of room for project or program managers, but anyone who’s directly involved in the production of code should take heed as their careers take flight.
Like all books in the Pragmatic Engineering series, this guide is eminently practical; that is, it is borne out of experiences in the modern tech workplace. It addresses venues ranging from small startups to Big Tech. It discusses universally accepted expectations across companies while exploring where different companies might approach nuances uniquely.
As a software developer, this book helps coach me through situations that my manager or colleagues cannot. It gives me targets to work towards that come out of larger industry experience instead of just my particular company. It also equips me to better coach fellow developers about how to develop their careers. This coaching role is particularly important in leadership because leaders develop others first and foremost.
Those involved in software engineering comprise the primary audience for this book. It’s written for those in the field by someone with longstanding, firsthand experience in the field. Teachers and academics can benefit by understanding how to equip their students to dive into fulfilling careers. I’m not sure there’s a whole lot of room for project or program managers, but anyone who’s directly involved in the production of code should take heed as their careers take flight.
January 24, 2026
Gehört als Audiobuch
Insgesamt finde ich das ein sehr gutes Buch für jeden Programmierer. Je nach Level wird man schon einiges kennen, man wird aber immer eine gewisse Inspiration von diesem Buch bekommen können.
Notizen:
- Spezifisches Feedback einfordern regelmäßig
- Play the long games, career takes decades
- Platform (interne Kunden, sehr technisch, compute and storage provider, payment sdk provider, ci/cd,
- wartime vs peace time
- Kannst du dir das angucken? Ja, ich würde mir das gerne angucken, aber ich muss gerade x machen und das würde das nach hinten schieben.
- Review Kommentare: sollen warum sein nicht wie
- Advanced language features: e.g. multithreading, memory usage of the language, generics ( )
- Learn a second language, you also are going to better understand the strenghts and shortcomings of your first language
- learn the boring stuff of a language
- software development vs software engineering ->engineering is more, getting requirements, long term impact, make code sustainable
- If you get asked -> create documentation for the next person
- senior responsability: notice when other people are blocked and offer to help them
- Code review (naming, comments, edge cases, understandability, bugs, too many changes, duplications, …)
- code review der Ton ist entscheidend, nitpicks können geschrieben werden
- tech debt ist eine Abwägung zwischen kurzzeitigem Speed und code qualität (-> Vernünftig für StartUps)
- Testing benefits (e.g. mehr Sicherheit bei Änderungen)
- Test Nachteile (Zeit zu schreiben, Zeit sie laufen zu lassen, Zeit zu maintanen)
15 Software Architecture
- 2 Phasen -> Konzeption und Umsetzung
- Design Documents (rfc request for comments), vor Coding -> Feedback früh bekommen
- Architecture Documents (adr architecture design records, arch42)
- Prototype (machen um Dinge herauszufinden, man kann besser über konkrekte als abstrakte Dinge sprechen, keine tests ci cd weil throwaway)
- DDD (Weniger Missverständnis durch einheitliche Sprache und gemeinsames Verständnis)
- Refuse to ship prototypes
|V Teach Lead
- bei big tech ist es kein offizieller Titel aber min Senior. bei andere Firmen gibt es den Titel öfters.
16 Projektmanagement
- Abhängigkeit: Personen - Umfang - Deadline
- Neue Entwickler machen es erstmal langsamer
- Eine Sache, die in einem Projet funktioniert, muss in einem anderen Projekt nicht funktionieren
- Mögliche Risiken
1 Technologierisiken
2 Engineering Risks
3 Non Engineering Risks (Design)
4 Timeline Risks
5 Unvorgesehene Überraschungen
…
- Beim Projektende sollen Leistungen gewürdigt werden
17 Shipping to production
- Yolo Methode -> Einfach auf Production bringen
- Gegenteil -> Alles bis ins kleinste Detail vorher testen
- Hängt von den Auswirkungen ab (StartUps wollen schneller sein und haben weniger User, Banken haben große Risiken bei Problemen)
- Automatische rollbacks bei schlechteren kpis können hilfreich sein
18 Stakeholder Management
…
19 Team Structures
- Remove unnecessary meetings
- Neue Prioritäten/ Anfragen hinterfragen
Was ist der Impact? —> Erst anfangen wenn der klar ist
Spezifikation anfordern
Nach der Spezifikation eine technische Planung klar machen
20 Team Dynamics
1. Healthy teams
- Clarity (goals)
- Excution
- Good moral (engaged teammates, support, people stay in the teams, healthy communication)
- Psycholgical safety
2. Unhealthy teams
opposite
- Lack of skills
- Brilliant jerk
- New Joiners make the team slower
- Junior heavy teams
- people leaving make the team slower
Growing pains
- Silent conflicts
- Good work unnoticed
- Increasing tech debt
-
A tech lead has to lead by example
21 Understanding the business
1. North Stars, KPIs, OKRs
Nach seiner Meinung soll man mit der ganzen Welt sprechen. Generell gut aber er übertreibt bisschen.
Insgesamt geht es ein bisschen zu sehr in die „mach einfach in allen Bereichen mehr und besser“
In einigen Firmen soll Tech nur über den Manager Kontakt zum Business haben
22 Collaboration
You want to be recogniced as influential not political
23 Software Engineering
- Entferne unnötige Feature Flags (Experiment Hygiene)
- Definition of done (tests hinzufügen)
- Product Health dashboard
- ci cycle <30 min (full cycle cd(?))
- trunk based development
- Buy, build or adapt (open source)
24 Reliable Software Systems
- Notify when logging indicates problems
- oncall work wird oft in sehr gut bezahlten Firmen nicht extra kompensiert
- „people quit managers, not the company“
- Incident management
- Circuit breaker: System switch back to normal wenn es Probleme gibt
25 Software Architecture
- Man kann Standard Architekturtools wie UML Diagramme, etc. nehmen, um ein System zu designen, aber man kann es auch einfach auf einem Whiteboard machen (Uber 70 Mrd. Umsatz) -> Tipp von ihm: Es nicht unnötig klompliziert machen, damit möglichst viele Leute es verstehen.
- Architecture debt
e.g standalone service instead of extending an existing service from another team to avoid pushback
- 1 Door (framework) vs 2 Door (a/b testing tool) decisions
2 way doors can become 1 way doors
26 Lifelong Learning
…
Insgesamt finde ich das ein sehr gutes Buch für jeden Programmierer. Je nach Level wird man schon einiges kennen, man wird aber immer eine gewisse Inspiration von diesem Buch bekommen können.
Notizen:
- Spezifisches Feedback einfordern regelmäßig
- Play the long games, career takes decades
- Platform (interne Kunden, sehr technisch, compute and storage provider, payment sdk provider, ci/cd,
- wartime vs peace time
- Kannst du dir das angucken? Ja, ich würde mir das gerne angucken, aber ich muss gerade x machen und das würde das nach hinten schieben.
- Review Kommentare: sollen warum sein nicht wie
- Advanced language features: e.g. multithreading, memory usage of the language, generics ( )
- Learn a second language, you also are going to better understand the strenghts and shortcomings of your first language
- learn the boring stuff of a language
- software development vs software engineering ->engineering is more, getting requirements, long term impact, make code sustainable
- If you get asked -> create documentation for the next person
- senior responsability: notice when other people are blocked and offer to help them
- Code review (naming, comments, edge cases, understandability, bugs, too many changes, duplications, …)
- code review der Ton ist entscheidend, nitpicks können geschrieben werden
- tech debt ist eine Abwägung zwischen kurzzeitigem Speed und code qualität (-> Vernünftig für StartUps)
- Testing benefits (e.g. mehr Sicherheit bei Änderungen)
- Test Nachteile (Zeit zu schreiben, Zeit sie laufen zu lassen, Zeit zu maintanen)
15 Software Architecture
- 2 Phasen -> Konzeption und Umsetzung
- Design Documents (rfc request for comments), vor Coding -> Feedback früh bekommen
- Architecture Documents (adr architecture design records, arch42)
- Prototype (machen um Dinge herauszufinden, man kann besser über konkrekte als abstrakte Dinge sprechen, keine tests ci cd weil throwaway)
- DDD (Weniger Missverständnis durch einheitliche Sprache und gemeinsames Verständnis)
- Refuse to ship prototypes
|V Teach Lead
- bei big tech ist es kein offizieller Titel aber min Senior. bei andere Firmen gibt es den Titel öfters.
16 Projektmanagement
- Abhängigkeit: Personen - Umfang - Deadline
- Neue Entwickler machen es erstmal langsamer
- Eine Sache, die in einem Projet funktioniert, muss in einem anderen Projekt nicht funktionieren
- Mögliche Risiken
1 Technologierisiken
2 Engineering Risks
3 Non Engineering Risks (Design)
4 Timeline Risks
5 Unvorgesehene Überraschungen
…
- Beim Projektende sollen Leistungen gewürdigt werden
17 Shipping to production
- Yolo Methode -> Einfach auf Production bringen
- Gegenteil -> Alles bis ins kleinste Detail vorher testen
- Hängt von den Auswirkungen ab (StartUps wollen schneller sein und haben weniger User, Banken haben große Risiken bei Problemen)
- Automatische rollbacks bei schlechteren kpis können hilfreich sein
18 Stakeholder Management
…
19 Team Structures
- Remove unnecessary meetings
- Neue Prioritäten/ Anfragen hinterfragen
Was ist der Impact? —> Erst anfangen wenn der klar ist
Spezifikation anfordern
Nach der Spezifikation eine technische Planung klar machen
20 Team Dynamics
1. Healthy teams
- Clarity (goals)
- Excution
- Good moral (engaged teammates, support, people stay in the teams, healthy communication)
- Psycholgical safety
2. Unhealthy teams
opposite
- Lack of skills
- Brilliant jerk
- New Joiners make the team slower
- Junior heavy teams
- people leaving make the team slower
Growing pains
- Silent conflicts
- Good work unnoticed
- Increasing tech debt
-
A tech lead has to lead by example
21 Understanding the business
1. North Stars, KPIs, OKRs
Nach seiner Meinung soll man mit der ganzen Welt sprechen. Generell gut aber er übertreibt bisschen.
Insgesamt geht es ein bisschen zu sehr in die „mach einfach in allen Bereichen mehr und besser“
In einigen Firmen soll Tech nur über den Manager Kontakt zum Business haben
22 Collaboration
You want to be recogniced as influential not political
23 Software Engineering
- Entferne unnötige Feature Flags (Experiment Hygiene)
- Definition of done (tests hinzufügen)
- Product Health dashboard
- ci cycle <30 min (full cycle cd(?))
- trunk based development
- Buy, build or adapt (open source)
24 Reliable Software Systems
- Notify when logging indicates problems
- oncall work wird oft in sehr gut bezahlten Firmen nicht extra kompensiert
- „people quit managers, not the company“
- Incident management
- Circuit breaker: System switch back to normal wenn es Probleme gibt
25 Software Architecture
- Man kann Standard Architekturtools wie UML Diagramme, etc. nehmen, um ein System zu designen, aber man kann es auch einfach auf einem Whiteboard machen (Uber 70 Mrd. Umsatz) -> Tipp von ihm: Es nicht unnötig klompliziert machen, damit möglichst viele Leute es verstehen.
- Architecture debt
e.g standalone service instead of extending an existing service from another team to avoid pushback
- 1 Door (framework) vs 2 Door (a/b testing tool) decisions
2 way doors can become 1 way doors
26 Lifelong Learning
…
April 17, 2024
This book is a great high-level overview of what's expected from various engineering tiers, serving both newer software engineers by going over the "unknown unknowns" in great detail, and more experienced engineers as a refresher for the various levels of development you would be expected to engage in.
August 25, 2024
Nothing new but well structured and nicely written. If you haven’t read any other book on the topic then it’s a great read. If you have then you don’t really need to read it unless you fancy the author, which why I read it in the first place.
December 22, 2025
Maybe useful for College Students. I feel this book could be way shorter, a lot of repetitive things. On positive side, cite some concepts that a younger engineer may not know and then it is aware it needs to study. A bit biased in Uber experience.
July 10, 2025
I'd say, if you are just starting in the industry, or just a few years in, this is a 5-stars book to read. It will give you a very good overview of what is expected of you and provide good guidance for your career.
If you are in the 10-20+ YoE bracket, it will be much less useful, except for identifying some blind spots, and in that case you can use it as a reference and skip some chapters.
If you are in the 10-20+ YoE bracket, it will be much less useful, except for identifying some blind spots, and in that case you can use it as a reference and skip some chapters.
June 9, 2024
I won't say it teaches a lot of new things. It's just well-organized. Overall, it's a good retrospective and a nice teaser of what's coming in the next few years.
July 8, 2024
Provides a great overview of a software engineering career but suffers from being too broad with very little depth.
July 24, 2025
TL;DR:
The Software Engineer’s Guidebook is a thorough and practical resource for software engineers at any stage, from first job through senior and leadership roles. It addresses the real-world aspects of building a tech career—industry structure, promotions, collaboration, and ongoing learning—making it a valuable reference you’ll return to as your responsibilities grow.
This is a book that was purchased for me. I had an excellent manager at Intuit, who recommended a book (The Staff Engineer's Path by Tanya Reilly) for those folks trying to move out of senior roles. I asked him if he could recommend a book for folks in earlier career stages that covered comparable ground, and he bought me a copy of The Software Engineer's Guidebook, by Gergely Orosz. I read the first part straight away, but then life intervened, and it took me much, much too long to get around to reading the remainder of the book. But here we are, at least a couple years later, and I've done it.
For this second read-through, I just went right back to the beginning, as I couldn't remember much of what I'd read before, beyond a few recommended habits to cultivate. So I have as fresh a read on the book as could be hoped for.
This is a very valuable book. Add it to the list of books I wish I'd had earlier in my career. What's more, it's a book I expect to return to again and again as I progress in my career, and as I have some level of care and responsibility for the careers of new engineers coming up behind me.
It's a bit hard to come at a structure for a review of this book, as it covers a lot of territory. In short, this book is about everything you need to know about a software engineering career, except the software engineering. It's about how the industry is structured, and how that affects your financial health and your work-life balances... the kinds of trade-offs you might have to make when considering different roles. It's about how to cultivate relationships with subordinates, superiors, and peers. It's about how to handle performance reviews and promotion packages. It's about how to participate in interviews, on both sides of the relationship. It does reach a bit into software engineering as well, but mostly at a strategic level. How are you thinking about testing? How are you staying current with tooling and knowing which tools are useful for a project? How are you at estimation?
You can see, that's a lot of ground to try to make coherent declarative statements about, so I just won't.
I can tell you a little about how this book is organized though, which gives it some of its value. It's organized into six sections (each with multiple chapters), the first and last of which are more-or-less generally applicable. The remaining four sections deal with your career at different stages (progressing from first-time-hire to Staff/Principal engineer or Architect) , and/or different hats you may be expected to wear in those stages (such as a project lead). I've broken down the sections in a bit more detail at the end of this review.
Like any good software engineer, Gergely is aware of trade-offs, so very little of the book is prescriptive. This is not "Here's one fool-proof system for a successful career in software engineering". It's much more about illuminating some of the terrain ahead, and telling you how different people before have addressed some of the bumps, and what their outcomes might have been. You're still very much in the driver's seat with this book, but it does try to be the sort of passenger who tells you when a deer is about to dart out in the road, or maybe when there's a place you can stop and get a burger before that next long stretch of empty desert.
About Software as a Career
How the industry is structured, what it takes to move between companies and "tiers" of companies and what a software engineer's career path might broadly look like, long-term
• How different positions within a company might affect your career
• Taking responsibility for your career direction
• Record-keeping and reputation management
• Navigating periodic reviews and promotion packages
• What to consider when changing jobs, or considering a change
• How a changing business environment can affect your work
Navigating your Early Career
• Seeking mentors
• Managing your reputation
• Estimation, prioritization, initiative, and getting unblocked
• Writing code that your peers will appreciate
• What to be learning
Being a Senior Engineer
Note that a Senior Engineer here is distinct from a Project Lead. The first is about operating as an individual contributor, but with expanded scope of awareness and responsibility, and the latter (covered in the next section) focuses more on project and team management.
• Requirements gathering
• Observability strategies
• Participating in production support
• Setting standards and documentation
• Relationship/reputation management (with expanded scope)
• Conducting code reviews
• Giving and receiving feedback
• Distributed decision making (ADRs, RFCs, etc.)
Tech Lead
Covers project-management aspects of senior-and-above roles
• Project Management
• Communicating with/managing stakeholders
• Cooperating with other teams
• Cross-functional collaboration (with Product, Design, etc).
• Release strategies and deployment environments, etc.
• Calculated risks, dealing with surprises, and learning from failure
• Team management: explicit roles, implicit roles, and human beings
Staff & Principal Engineers
This section covers broadly the same areas as before, but at a higher level of abstraction, scope, and responsibility and accountability. New subjects include:
• Managing geographically distributed groups of teams
• Incident Management and organizing an On-Call rotation
• Partnering with Engineering and Product Managers
• Being informed about the business
• Architectural decisions and trade-offs
Suggestions & Strategies for continuous learning and long-haul sustainability.
This last section is just a short summing up
All in all, very valuable, and I expect to return to this book again and again over the remainder of my career.
The Software Engineer’s Guidebook is a thorough and practical resource for software engineers at any stage, from first job through senior and leadership roles. It addresses the real-world aspects of building a tech career—industry structure, promotions, collaboration, and ongoing learning—making it a valuable reference you’ll return to as your responsibilities grow.
This is a book that was purchased for me. I had an excellent manager at Intuit, who recommended a book (The Staff Engineer's Path by Tanya Reilly) for those folks trying to move out of senior roles. I asked him if he could recommend a book for folks in earlier career stages that covered comparable ground, and he bought me a copy of The Software Engineer's Guidebook, by Gergely Orosz. I read the first part straight away, but then life intervened, and it took me much, much too long to get around to reading the remainder of the book. But here we are, at least a couple years later, and I've done it.
For this second read-through, I just went right back to the beginning, as I couldn't remember much of what I'd read before, beyond a few recommended habits to cultivate. So I have as fresh a read on the book as could be hoped for.
This is a very valuable book. Add it to the list of books I wish I'd had earlier in my career. What's more, it's a book I expect to return to again and again as I progress in my career, and as I have some level of care and responsibility for the careers of new engineers coming up behind me.
It's a bit hard to come at a structure for a review of this book, as it covers a lot of territory. In short, this book is about everything you need to know about a software engineering career, except the software engineering. It's about how the industry is structured, and how that affects your financial health and your work-life balances... the kinds of trade-offs you might have to make when considering different roles. It's about how to cultivate relationships with subordinates, superiors, and peers. It's about how to handle performance reviews and promotion packages. It's about how to participate in interviews, on both sides of the relationship. It does reach a bit into software engineering as well, but mostly at a strategic level. How are you thinking about testing? How are you staying current with tooling and knowing which tools are useful for a project? How are you at estimation?
You can see, that's a lot of ground to try to make coherent declarative statements about, so I just won't.
I can tell you a little about how this book is organized though, which gives it some of its value. It's organized into six sections (each with multiple chapters), the first and last of which are more-or-less generally applicable. The remaining four sections deal with your career at different stages (progressing from first-time-hire to Staff/Principal engineer or Architect) , and/or different hats you may be expected to wear in those stages (such as a project lead). I've broken down the sections in a bit more detail at the end of this review.
Like any good software engineer, Gergely is aware of trade-offs, so very little of the book is prescriptive. This is not "Here's one fool-proof system for a successful career in software engineering". It's much more about illuminating some of the terrain ahead, and telling you how different people before have addressed some of the bumps, and what their outcomes might have been. You're still very much in the driver's seat with this book, but it does try to be the sort of passenger who tells you when a deer is about to dart out in the road, or maybe when there's a place you can stop and get a burger before that next long stretch of empty desert.
About Software as a Career
How the industry is structured, what it takes to move between companies and "tiers" of companies and what a software engineer's career path might broadly look like, long-term
• How different positions within a company might affect your career
• Taking responsibility for your career direction
• Record-keeping and reputation management
• Navigating periodic reviews and promotion packages
• What to consider when changing jobs, or considering a change
• How a changing business environment can affect your work
Navigating your Early Career
• Seeking mentors
• Managing your reputation
• Estimation, prioritization, initiative, and getting unblocked
• Writing code that your peers will appreciate
• What to be learning
Being a Senior Engineer
Note that a Senior Engineer here is distinct from a Project Lead. The first is about operating as an individual contributor, but with expanded scope of awareness and responsibility, and the latter (covered in the next section) focuses more on project and team management.
• Requirements gathering
• Observability strategies
• Participating in production support
• Setting standards and documentation
• Relationship/reputation management (with expanded scope)
• Conducting code reviews
• Giving and receiving feedback
• Distributed decision making (ADRs, RFCs, etc.)
Tech Lead
Covers project-management aspects of senior-and-above roles
• Project Management
• Communicating with/managing stakeholders
• Cooperating with other teams
• Cross-functional collaboration (with Product, Design, etc).
• Release strategies and deployment environments, etc.
• Calculated risks, dealing with surprises, and learning from failure
• Team management: explicit roles, implicit roles, and human beings
Staff & Principal Engineers
This section covers broadly the same areas as before, but at a higher level of abstraction, scope, and responsibility and accountability. New subjects include:
• Managing geographically distributed groups of teams
• Incident Management and organizing an On-Call rotation
• Partnering with Engineering and Product Managers
• Being informed about the business
• Architectural decisions and trade-offs
Suggestions & Strategies for continuous learning and long-haul sustainability.
This last section is just a short summing up
All in all, very valuable, and I expect to return to this book again and again over the remainder of my career.
December 28, 2023
This book is the best "basic" guide to the Big Tech software engineering. It is really dense in information and could be a great onboarding material!
For someone with enough (say 5-10 years) of Big Tech experience there won't be too much new to read as they aren't the target audience, I feel.
For someone with enough (say 5-10 years) of Big Tech experience there won't be too much new to read as they aren't the target audience, I feel.
Want to read
March 21, 2026The Software Engineer's Guidebook
Author: Gergely Orosz (The Pragmatic Engineer)
Why it matters: A comprehensive career guide from junior engineer to staff+. Strong on ownership, navigating organizations, and positioning yourself during hiring processes.
Key Takeaways
Owning Your Career
Deliver consistently on what was agreed — OKRs, daily tasks, quality bar. Avoid pseudoproductivity: prioritize work with real product impact. Document weekly wins in a worklog so you have evidence at performance reviews.
Choose your company type intentionally. Startups offer speed and breadth; big tech offers structure and compensation. Understand Dual-Track Careers early: IC path vs. management path — both are valid, but the skills differ.
Becoming an Effective Tech Lead
Define “Definition of Done” clearly for every project to avoid rework. Identify stakeholders early — upstream (who you depend on) and downstream (who depends on you). Balance technical long-term decisions against short-term business urgency without becoming an “ivory tower” architect.
Healthy teams have clarity, good communication, and mutual trust. Dysfunctional teams lack psychological safety, have undefined goals, and let conflicts fester.
Growing to Staff+
Impact must expand beyond your immediate team. Your work needs to move business metrics, not just ship code. Mentor junior engineers, broker technical conflicts between teams, and think in terms of long-term architecture.
Build credibility through consistent delivery. Sell ideas through honest persuasion — not politics. Stay humble: there is always something new to learn.
Interview Prep (Before / During / After)
Before: Map stakeholders, prepare a career narrative with impact examples beyond code (mentoring, process improvements, cross-team work). Research the company’s north star and key business metrics.
During: Contextualize answers fast — brief setup before the key point keeps the interviewer engaged. Show both technical depth and business awareness. Demonstrate leadership through examples of conflict resolution, mentorship, and unblocking delivery.
After: Ask for feedback on strengths and areas to improve. Maintain the connection even if not hired. Update your career plan based on what you learned in the process.
Section Overview
1 — Owning Your Career
Delivery, value-add, long-term planning
2 — Pragmatic Tech Lead
Scope, stakeholders, team dynamics
3 — Staff+ Growth
Business impact, influence without authority
4 — Longevity Strategies
Continuous learning, adapting to change
5 — Interview Timeline
Before, during, and after the interview
Actionable Items
- Keep a weekly worklog: what you shipped, what you unblocked, what you learned
- Align your personal career goals to company business metrics
- Build a career narrative that explains each move as intentional progression
- Before every interview: research their north star and how your role impacts it
March 29, 2024
In summary: a book with great content that was hindered by a suboptimal structure.
The Software Engineer's Guidebook is, as the title implies, a guidebook. It covers to a shallow degree a wide breadth of things that the modern software engineer should know: career development, the shape of the industry, collaboration & processes, technical leadership, code & architectural quality, and the modern software stack. 10 years in industry or reading a dozen books dedicated to the specific topics will give you more breadth, of course. However, what this book does is provide just enough of an overview to help a software engineer learn more quickly as they encounter different aspects. Effectively, it turns unknown unknowns into known unknowns. I would strongly recommend this book to someone early-career, and moderately recommend it to those further on. (For those further along in their career, I'd more strongly recommend The Staff Engineer's Path by Tanya Reilly or Staff Engineer by Will Larsen. I prefer the first, but it's largely a stylistic preference.)
That's where this book succeeds. Where this book fails, at least for me, is in the structure. Part I, on Developer Career Fundamentals, is well structured. The rest of the book tries to cram a variety of topics into a structure based around career levels. I do like the way Orosz divides up levels: the competent software developer, the well-rounded senior engineer, the pragmatic tech lead, role-model staff & principal engineers. Both the descriptive titles and the tables at the beginning of each part provide a memorable way of distinguishing different phases of a software engineering career.
What doesn't work as well is the way that all of the other content is put into this structure. For example, there are various discussions of the modern software engineering stack and deployment methods, various discussions of how to write good code and think about architecture, several chapters on collaboration and leadership. Although the way these chapters are divided up by the parts roughly progresses based on level, the mapping was blurry, and I think the guidance in them often applies regardless of the level it's associated with.
I would have much rather have had the book be laid out where each part was more like a mini-book on a particular focus area. E.g., group together the chapters on collaboration, leadership, and project management in one section. Group together the chapters on code and architecture quality in another. Group together the chapters on the modern software development stack in another. This structure would have felt less artificial (and could also have reduced the significant repetition throughout the book).
Overall though, this book fulfills a niche that I have not seen other books fill: it provides information that will help software engineers grow in multiple dimensions in one book that is (at least for now) up to date relative to how professional software development works.
The Software Engineer's Guidebook is, as the title implies, a guidebook. It covers to a shallow degree a wide breadth of things that the modern software engineer should know: career development, the shape of the industry, collaboration & processes, technical leadership, code & architectural quality, and the modern software stack. 10 years in industry or reading a dozen books dedicated to the specific topics will give you more breadth, of course. However, what this book does is provide just enough of an overview to help a software engineer learn more quickly as they encounter different aspects. Effectively, it turns unknown unknowns into known unknowns. I would strongly recommend this book to someone early-career, and moderately recommend it to those further on. (For those further along in their career, I'd more strongly recommend The Staff Engineer's Path by Tanya Reilly or Staff Engineer by Will Larsen. I prefer the first, but it's largely a stylistic preference.)
That's where this book succeeds. Where this book fails, at least for me, is in the structure. Part I, on Developer Career Fundamentals, is well structured. The rest of the book tries to cram a variety of topics into a structure based around career levels. I do like the way Orosz divides up levels: the competent software developer, the well-rounded senior engineer, the pragmatic tech lead, role-model staff & principal engineers. Both the descriptive titles and the tables at the beginning of each part provide a memorable way of distinguishing different phases of a software engineering career.
What doesn't work as well is the way that all of the other content is put into this structure. For example, there are various discussions of the modern software engineering stack and deployment methods, various discussions of how to write good code and think about architecture, several chapters on collaboration and leadership. Although the way these chapters are divided up by the parts roughly progresses based on level, the mapping was blurry, and I think the guidance in them often applies regardless of the level it's associated with.
I would have much rather have had the book be laid out where each part was more like a mini-book on a particular focus area. E.g., group together the chapters on collaboration, leadership, and project management in one section. Group together the chapters on code and architecture quality in another. Group together the chapters on the modern software development stack in another. This structure would have felt less artificial (and could also have reduced the significant repetition throughout the book).
Overall though, this book fulfills a niche that I have not seen other books fill: it provides information that will help software engineers grow in multiple dimensions in one book that is (at least for now) up to date relative to how professional software development works.
June 14, 2024
The Software Engineer’s Guidebook is a must-read for anyone in the tech industry, regardless of their level of experience. What sets this book apart is its comprehensive approach to career development, emphasizing that excelling in software engineering requires more than just technical prowess. The author skillfully illustrates that the most successful engineers are those who have honed both their technical and soft skills.
One of the book’s standout features is its tailored advice for every career stage, from junior engineers to senior engineers, tech leads, and staff engineers. Each section is filled with practical tips and insights that are relevant and actionable. As someone navigating their own career in software engineering, I found myself frequently nodding in agreement and taking notes on how I could implement the suggestions provided.
The advice is not only practical but also deeply resonant. It encourages continuous learning and highlights the importance of taking breaks, a crucial reminder in an industry that often glorifies overwork. This balanced perspective is refreshing and makes the book applicable to a wide audience.
In summary, The Software Engineer’s Guidebook is an invaluable resource that offers guidance for every step of a software engineer’s career. It underscores the importance of balancing technical skills with soft skills and promotes a sustainable approach to career growth. I highly recommend this book to anyone in tech, whether you are just starting out or are a seasoned professional looking to refine your skills and gain new insights.
One of the book’s standout features is its tailored advice for every career stage, from junior engineers to senior engineers, tech leads, and staff engineers. Each section is filled with practical tips and insights that are relevant and actionable. As someone navigating their own career in software engineering, I found myself frequently nodding in agreement and taking notes on how I could implement the suggestions provided.
The advice is not only practical but also deeply resonant. It encourages continuous learning and highlights the importance of taking breaks, a crucial reminder in an industry that often glorifies overwork. This balanced perspective is refreshing and makes the book applicable to a wide audience.
In summary, The Software Engineer’s Guidebook is an invaluable resource that offers guidance for every step of a software engineer’s career. It underscores the importance of balancing technical skills with soft skills and promotes a sustainable approach to career growth. I highly recommend this book to anyone in tech, whether you are just starting out or are a seasoned professional looking to refine your skills and gain new insights.
December 1, 2024
The book’s title perfectly aligns with the content. It’s a guidebook.
If you already are a staff+ engineer or a tech lead there may not be much new information to drive your own career forward… unless you’re in a bad place and need to get on right track.
But think about your younger colleagues. How you can help them navigate their roles in the team or even their careers in the industry. That was my main thought while reading this book: I wish I had this knowledge when I was starting.
Things like recognizing the right company for you, building valuable relationships with peers and managers, understanding how companies operate, how promotions and compensation schemes work. This knowledge is not a given especially for people with origins in non-western cultures. For them it all comes with experience, through trial and errors, so the price in time and money is usually pretty high.
This book sheds some light on what is ahead in the journey of a software engineer, how to prepare and navigate.
If you’re early in your career, or even when starting as a senior, this book will be a great resource for you. If you are senior/staff+, think about younger you and about younger folks that you could support. And simply gift them this book.
If you already are a staff+ engineer or a tech lead there may not be much new information to drive your own career forward… unless you’re in a bad place and need to get on right track.
But think about your younger colleagues. How you can help them navigate their roles in the team or even their careers in the industry. That was my main thought while reading this book: I wish I had this knowledge when I was starting.
Things like recognizing the right company for you, building valuable relationships with peers and managers, understanding how companies operate, how promotions and compensation schemes work. This knowledge is not a given especially for people with origins in non-western cultures. For them it all comes with experience, through trial and errors, so the price in time and money is usually pretty high.
This book sheds some light on what is ahead in the journey of a software engineer, how to prepare and navigate.
If you’re early in your career, or even when starting as a senior, this book will be a great resource for you. If you are senior/staff+, think about younger you and about younger folks that you could support. And simply gift them this book.
June 15, 2024
Of the books that I've read, this one comes the closest to describing what it's like to work in a big-tech corp setting as a SWE. I don't think we've something as comprehensive as this one either, you can find bits and pieces on online articles, Blind and bunch of other resources; but he's giving a lot of great insights, which is valuable to the early-in-career folks.
I think Gergely could have done better with separating this book into 2 volumes, because it looks like there's a bit of back and forth between chapters, so it's not written with a certain path.
I strongly recommend this to all juniors because there's a lot of useful information that you may not be *given* directly, and it could take you longer to figure this out by yourself (by inferring it from situations) as opposed to just reading them in a book. Also a good read for more senior folks, but very likely that a lot would have been figured out by then. If you're at Staff level / or EM level - little you can learn from the book, a lot of the material would be very intuitive by then.
I think Gergely could have done better with separating this book into 2 volumes, because it looks like there's a bit of back and forth between chapters, so it's not written with a certain path.
I strongly recommend this to all juniors because there's a lot of useful information that you may not be *given* directly, and it could take you longer to figure this out by yourself (by inferring it from situations) as opposed to just reading them in a book. Also a good read for more senior folks, but very likely that a lot would have been figured out by then. If you're at Staff level / or EM level - little you can learn from the book, a lot of the material would be very intuitive by then.
October 17, 2024
Does what it says on the tin. It's a guidebook for going from junior to tech lead position. It discusses what differentiates each role from the next/previous and which should be your target goals while on that role. Obviously this sounds abstract and obviously this is. Don't expect ideas on how to structure your code better or how to involve heated situations etc. This is a bundle of different summaries for each role you would find dispersed in multiple blog-posts. And this is not bad, it's nice to have this information bundled in a book where you could reference in order to come up with a PDP. One thing that's missing from this (hence -1 star) is suggested books for each role part. Obviously this is difficult to achieve but I'd like book suggestions for each area of each role. There are book recommendations scattered around due to references in the actual text, but a list of recommended books for each section would have been great.
December 6, 2025
The book tries to cover an extremely broad range of topics—career progression, technical leadership, systems design, navigating big tech, team dynamics—and as a result, it trades depth for breadth. It’s valuable primarily for engineers moving from startups into Big Tech environments or transitioning from mid-level to senior roles. It offers a solid blueprint of what matters at that level, and it will reveal gaps in your current approach.
However, it rarely dives deep enough to stand on its own. For almost every topic, you’ll need to go elsewhere to understand the details well enough to apply them effectively. That’s an acceptable trade-off for a high-level guide, but anyone expecting rigorous technical or managerial depth will be disappointed. Think of it as a map, not an instruction manual.
However, it rarely dives deep enough to stand on its own. For almost every topic, you’ll need to go elsewhere to understand the details well enough to apply them effectively. That’s an acceptable trade-off for a high-level guide, but anyone expecting rigorous technical or managerial depth will be disappointed. Think of it as a map, not an instruction manual.
January 23, 2026
It’s sort of an all-in-one compendium. I’ll admit that if I were a beginner in the IT world, many of these extremely specific, bullet-pointed tips would have been genuinely useful — especially the language and the key buzzwords that show up in the IT market. But for me it was a bit too point-based, too slogan-like; instead of describing things, it focused on presenting a list of advice. I’d recommend it to someone entering the IT world.
Takie trochę kompendium wszystkiego. Przyznam, że gdybym był początkującym w świecie IT, to wiele z tych niezwykle konkretnie wypunktowanych porad byłoby naprawdę przydatnych. Tak samo: użycie języka i kluczowych buzzwordów pojawiających się na rynku IT. Jednak dla mnie ta pozycja była trochę zbyt hasłowa — zamiast opisu raczej skupiała się na pokazaniu listy porad. Poleciłbym ją komuś wchodzącemu w świat IT.
Takie trochę kompendium wszystkiego. Przyznam, że gdybym był początkującym w świecie IT, to wiele z tych niezwykle konkretnie wypunktowanych porad byłoby naprawdę przydatnych. Tak samo: użycie języka i kluczowych buzzwordów pojawiających się na rynku IT. Jednak dla mnie ta pozycja była trochę zbyt hasłowa — zamiast opisu raczej skupiała się na pokazaniu listy porad. Poleciłbym ją komuś wchodzącemu w świat IT.
Displaying 1 - 30 of 106 reviews