DEEP READING · READ 920

The Software Engineer's Guidebook

Gergely Orosz · 2023

中文 →

In One Sentence

This is the book that draws the whole road at once: from the developer whose code merely works, to the senior who can be handed a vague problem and trusted with it, to the tech lead who gets a team's work across the line, to the staff or principal engineer who moves an organization without managing anyone. What Orosz is really explaining at each rung is how the definition of your output changes — plus one thing most engineers are never told outright: a large share of what you're paid and how fast you grow depends not on how good you are, but on which tier of the market you're standing in, and on whether your work is visible at all.

Where It Sits

Orosz is Hungarian; he worked at Skype/Microsoft and Skyscanner, then spent years at Uber as an engineer and engineering manager on payments. After leaving he began writing The Pragmatic Engineer, and became one of the most widely read practitioner voices in the industry. The book was self-published in 2023 — no publisher vetting it, and therefore no publisher trimming it. It is an insider's field record, not a theory. Set against the two staff+ classics already covered on this shelf, its position is clear: Will Larson's Staff Engineer is about reaching and defining the role, Tanya Reilly's The Staff Engineer's Path is about what you actually do once you're there, while Orosz's book starts much earlier and looks much wider — it begins when you are still junior, and adds a layer neither of the others has: how this industry actually works, and how it prices people.

The Central Claims

• Each level is not "the same job, done better" — the definition of output changes. Juniors are judged on code, seniors on whether the problem got solved, tech leads on the team's output, staff+ on the organization's. Playing the next level's game by the previous level's rules is why most people stall.
• Getting things done is the most systematically underrated skill there is. It isn't the cleverest people who move fastest; it's the ones you can hand something to and know it will land — because in an environment full of dependencies, ambiguity and half-finished work, reliably crossing the last 20% is scarce.
• Promotion is a lagging indicator, not a reward. Nobody promotes you because you deserve it. You get the label after you are already doing the work of the next level, someone can see it, and someone will vouch for it.
• The same ability is priced several times differently depending on the tier of company you're in. That's not a moral fact, it's a structural one — and not knowing it means pitting your individual effort against an entire pricing mechanism.

The Core Ideas, One by One

Three tiers of the market: why the same you carries several different prices

This is Orosz's most distinctive framework, and the easiest to misuse. His observation is that engineering compensation isn't one smooth curve but several separate peaks, because companies aren't fishing in the same talent pool and don't price by the same logic.

Schematic. The tiers differ in pricing mechanism, not in the worth of the humans; the gap between tiers is usually multiples, not percentages.

The value of this framework isn't "go get another job." It's that it re-describes as structural something people experience as personal. Someone six years into a Tier 1 company, with a perfect record of "exceeds expectations," will usually read their pay ceiling as I'm not good enough yet, and respond by writing more code — when the problem lives somewhere else entirely: the number they want does not exist anywhere in their employer's pricing frame. It's like renovating a house in a small town in the hope of reaching big-city listing prices. The craftsmanship isn't the variable. The market is.

But Orosz does not turn this into "sprint for Tier 3." He keeps flagging the other half: the higher the tier, the more you're expected to find your own direction inside ambiguity, the thinner the margin for error, the faster the treadmill. Plenty of people are miserable in Tier 3, and plenty do very well in Tier 2 with a genuinely controllable life. What it changes in how you see things: from now on, "should I work harder?" splits into three different questions — work harder, change which game I'm in, or accept this price and buy something else with the rest of my life.

Company type decides what a title even means

The companion idea: "senior engineer" at an early-stage startup, at a fast-scaling company, and at a mature big tech firm are three different jobs. The startup wants someone who can turn their hand to anything and force a product into existence where no process exists. The scaleup wants someone who can rebuild the foundations while the building stays open. Big tech wants someone who can push one change through many desks, across enormous existing systems and long chains of collaboration.

The practical corollary is sharp: the real risk when you switch companies isn't "am I technically strong enough" but "does the thing I got good at still count as a strength here?" Someone whose superpower was aligning ten teams arrives at an eight-person startup and finds there are no ten teams to align. Someone who took pride in shipping in three days arrives at a large company, hits review boards, compliance and migration plans, and misdiagnoses the whole thing as "nobody here does any work." Hence Orosz's advice is not "pick the best company" but "work out which kind of person this company needs right now, then decide whether that's who you want to become."

Getting things done: the plainest idea in the book, and the dividing line

The phrase gets polished again and again, and it sounds like a truism until he breaks it down. "Done" means travelling all the way from "my part is written" to "users are on it, it's stable in production, and the people who need to know it shipped know it shipped" — and treating every unclaimed gap along that path as yours.

Concretely, the gaps look like this: a dependency team hasn't scheduled your work, so you go talk to their lead about priorities; the spec contradicts itself in one line, so instead of posting a question and waiting three days you grab ten minutes and settle it; the test environment has no data, so you generate some; nothing is watching the metric after launch, so you build the dashboard. None of it is in your job description, and all of it together decides whether the thing actually happened.

Why is this the dividing line? Because in any organization above a certain size, the hard part was never writing the logic; it was getting something that spans three teams, two quarters and a dozen fuzzy decisions to actually arrive. To a manager, a person who reliably does that isn't linearly more valuable — they're a different category: they can be trusted with things. How it changes your view: you stop grading yourself on "I finished what was assigned to me" and start asking a much harder question — if I disappeared today, would this rot halfway?

Output gets redefined at every rung — that's what a promotion really is

This is the spine of the book, and the one table worth memorizing.

Each rung up, "what I did" carries less weight and "what happened because of me" carries more.

On tech lead, Orosz insists on a point that is constantly missed: it's a role, not a level. It can rotate; you may hold it on this project and hand it over on the next; it does not necessarily lead to management and does not outrank senior. People who read it as a promotion start behaving like junior managers — hoarding decisions and keeping the interesting work. People who read it as "for now, I'm responsible for this team moving" do a different set of things: cutting the boulder into parallel pieces, catching two people building the same thing, pulling out whoever has been stuck for three days.

Three radii of influence: what staff+ actually do

Orosz's account of staff+ is restrained, which is what makes it usable: the value isn't doing harder engineering, it's selection and amplification. Selection — among a dozen genuinely important things, judging which one makes the next year easier for everybody and which one merely makes this quarter look good. Amplification — the same hours spent writing code yourself versus spent making twenty people write the right thing.

He sorts the ways of having effect into escalating levels: doing (personally solving something nobody else could crack) → teaching (giving the people around you that capability) → establishing (locking in a direction, a standard, a decision framework, so that from now on the default path is the right one). The third is the highest-leverage and the most invisible: one well-written design document, one meeting that finally settles "do we build this ourselves or not," pays out for two years and shows up in nobody's commit history. Which is exactly why staff+ engineers need to make work visible — not out of vanity, but because the most valuable output of the job is inherently the hardest kind for an organization to notice on its own.

How promotion actually works: do it, evidence it, then ask

Orosz is unsentimental here, and this is the most immediately usable stretch of the book. A promotion is not a medal for past effort; it is the confirmation of a fact that has already happened. What the committee wants to see is whether this person is already operating at the next level, with checkable evidence. So the order is the reverse of the folk model — not "I've been here three years, I'm due," but:

• Align on the bar with your manager first: what does the next level look like at this company? Give me two concrete examples. (Ladders differ wildly between companies, and titles barely transfer across them — one of his recurring warnings against measuring yourself by a title.)
• Pick work that generates evidence: a technically delightful refactor nobody asked for and a less glamorous project that removes a whole team's pain carry completely different weight in a promotion packet.
• Keep a running record — many people call it a brag document — noting what you did, what changed because of it, and who benefited. Reconstructing six months from memory when the packet is due loses most of it, and produces no numbers.
• Find people who will speak for you. You are not in the room where the decision happens; somebody else is. This isn't politics, it's the physics of how organizations work.

How it changes your view: promotion stops being something the company does to you and becomes something you produce and present evidence for. Along with an uncomfortable acceptance: doing good work and being known to do good work are two separate jobs, and both are yours.

Opinions vs. facts: a small habit that separates junior from senior

One deceptively minor piece of advice carries a lot of weight: separate facts from opinions when you speak, and label which is which. "This query's p99 in production is 800 ms" is a fact. "I think we should move to Redis" is an opinion. Junior engineers routinely fuse the two, and the discussion turns into a contest of positions; pull them apart and the conversation drops to where it belongs — first, is the fact right, and then, given the fact, what should we do?

It matters because it fixes three things at once. It makes your judgement checkable (people can correct your fact instead of concluding you're wrong as a person). It makes changing your mind cheap (admitting "my opinion has changed" is far easier than admitting "I was wrong"). And it makes you credible across teams — credible not because you're always right, but because people know you won't dress a guess as a conclusion.

Looking outside the company: two things that compound

Orosz is himself the living case for this advice — his influence today comes from years of writing in public, not from any company's ladder. The claim has two layers.

The first is calibration. Stay inside one company long enough and you start taking its standards for the industry's: what's considered hard here is hard, what counts as senior here is senior. Internal evaluation is a closed coordinate system, and it can be collectively skewed with nobody in a position to tell you. The remedy is unglamorous: read job postings, interview occasionally for real, talk shop with peers elsewhere. Not to leave — to know where you're standing.

The second is network and public trace. People who have worked with you and rate you are the longest-paying investment in your career: most good opportunities arrive through someone who remembers you shipped something, not through an application form. Writing in public — blog posts, open source, talks — compounds differently: it converts "the version of you only your ex-colleagues know" into a version strangers can verify. Neither can be crammed. Both accumulate only while you don't need them.

The Argument in Skeleton

The whole book answers one question: what actually drives a software engineer's career? Orosz's answer has three parts, and dropping any one of them sends you off course.

Part one is the ladder of capability, where every rung redefines the terms. From "finished the task" to "solved the problem" to "the team delivered" to "the organization is pointed the right way." The higher the same person climbs, the smaller the share of hours spent writing code and the larger the share of "things got better because of me." People who miss the redefinition respond with more overtime to a problem that was never about volume.

Part two is the machinery of being seen. An organization is not an omniscient observer; it judges you through a handful of signals — the documents you wrote, the projects you led, your manager's retelling of you, how often your name comes up in rooms you're not in. So "doing good work" and "getting good work into the organization's field of view" are independent tasks, and countless engineers refuse the second as undignified while paying its cost themselves.

Part three is the market you're standing in. Tier, company type and company stage together determine what your effort converts into. This is the least intuitive part, because it implies that doing the right thing in the wrong place can pay far less than doing an ordinary thing in the right one.

Put together: career growth = a real jump in capability × making it visible × standing in a market that pays for it. Three factors multiplied — drive any one toward zero and the product goes with it. Almost everyone works only on the first.

Misreadings and Serious Objections

Misreading one: treating it as a promotion playbook. The book is full of operational detail about levels, reviews and switching jobs, but its actual claim is the opposite: first be genuinely able to do the next level's work; the rest is only meaningful afterwards. Learn the second half alone and you become someone excellent at writing packets who cannot hold the role.

Misreading two: reading "three tiers" as "you must reach Tier 3." The tiers describe pricing mechanisms, not a ranking of lives. Tier 3 also means steeper expectations, more ambiguity, higher layoff exposure and a larger share of pay in equity that can go to zero. The correct use of the framework is knowing which game you're in and what its rules are, not climbing unconditionally.

Objection one, and the fairest: this is a book of experience, not of evidence. Its conclusions come from the author's own years inside a handful of European and American tech companies plus a great many practitioner interviews — no controls, no dataset. That knowledge is genuinely valuable and also carries survivorship bias by construction: the people who followed the same advice and didn't make it are not in the sample. For engineering effectiveness with empirical backing, you want something like Accelerate instead.

Objection two: much of the advice quietly assumes a loose labour market. The book comes at the end of a decade-long expansion, when "if you're unhappy, move — move up a tier" was actually available. In a cycle of layoffs, hiring freezes and slashed promotion budgets, the same advice degrades badly; "do the next level's job and wait for the company to confirm it" in an organization that has just paused promotions may simply mean a year donated. The book handles that cyclical risk lightly.

Objection three: structural barriers are understated. "Get into a company that hires globally" is a completely different proposition depending on your passport, time zone and first language. Visas, employment compliance, overlap hours and local hiring policy constrain tier mobility more than individual ability does, and that layer gets comparatively little space.

Objection four: it's a big book, and it repeats. Self-published and running to roughly seven hundred pages, its breadth is the point and the price is that several stretches are covered more sharply elsewhere — the tech lead and management material overlaps Camille Fournier's The Manager's Path, and the staff+ material is thinner than Reilly's. Its distinctive value is concentrated in two places: the complete map of the ladder, and the layer of industry-and-pricing common sense nobody else writes down.

Ten Sentences