The weekly letter from Systems Thinking Lab: systems thinking insights for junior engineers, framed through the seven building blocks.
The hard part of engineering moved this year. It is no longer writing the code. It is deciding whether to trust it.
Addy Osmani put a rule on that in June, and the rule is good: tier your review by risk, not by who wrote it. A config change gets a linter. A payments path gets a human reading every line. Spend attention where being wrong is expensive. For a team shipping fast, that is exactly right.
Here is the change it tells you to skip.
Monday morning. Your agent opens a pull request: "Add retry to the receipt email worker." Sixty lines. Tests green. It is a background job, not a payment path, so the rule says the linter can have it. You have eleven other things open. Approve.
Now read it instead. The job pulls a message off the Queue, renders the receipt, calls the email provider, and marks the order as notified. The retry the agent added wraps the whole job. A timeout anywhere inside it runs the whole job again from the top.
Trace one bad afternoon. The email provider accepts the send, then the connection drops before it answers. The Worker sees a timeout. The retry fires. The customer gets two receipts for one order, and the second one arrives ninety seconds after the first, which is exactly the shape of a charged-twice email. Support gets the ticket. Nobody can find a bug, because there is no bug in any single line. There is a bug in where the retry boundary sits.
The fix is small. Retry the render and the send separately, and make the send safe to repeat by handing the provider an idempotency key built from the order id. Four lines. But you only get to write them if you read the sixty.
That is what the risk rule cannot see. It scores the change by what it touches. It cannot score what reading it would have taught you. The linter would have passed this pull request every time, forever, and you would have learned nothing from it every time, forever.
This is the same shape in every system you will ever work on. Instagram's feed is a cache that has to be told when a post changes, and the interesting question is who tells it. Uber's dispatch is a Queue with a clock on it, and the interesting question is what happens to a ride request when the Worker holding it dies. None of those questions live in the code. They live at the seams between building blocks, and you only find seams by reading across them.
So here is the thing to add to the rule if you are early in your career. Review is not only a gate. It is a rep. Reading code you did not write, deciding whether it holds, finding the edge the test did not cover: that is the whole exercise that builds judgment, and there is no other one. The throughput math says move on. The growth math says read it anyway.
The wrong move is the obvious one. Approving faster looks like seniority. It is the opposite. A senior engineer is not someone who trusts more code. It is someone who has read enough code to know exactly which lines to distrust. Trust is not a setting you turn up. It is a residue that reading leaves behind.
You do not have to read everything. Read the ones that would teach you something if they were wrong, which is most of them when you are starting. Five a day, for a year, is more system reading than most engineers do in five.
In the seven building blocks I teach juniors to read systems before they write them: to trace one request across a Service, a Queue, a Worker, and a store, and to name where it can break. The reading is where the seeing gets built.
You do not build trust by clicking approve. You build it by reading until you could have written it yourself.
P.S. If you want reps that are not your own pull requests, I wrote up three real systems block by block, Netflix, Instagram, and Uber, and the seams are marked: systemthinkinglab.ai/learn/case-studies/