[dead]
Every layer of review makes you 10x slower
331–339 of 339 posts
Re: Every layer of review makes you 10x slower
#332The 10x claim reminds me of various scaling laws in anthropology/sociology, especially the much-debated Haire cube-root scaling law (eg https://gwern.net/doc/sociology/1959-haire.pdf https://gwern.net/doc/economics/1983-stephan.pdf ). I wonder if one could give a derivation from queuing theory where you have an argument along the lines of 'in indefinitely many layers of queues of queues, the total delay is minimized…
After some chatting with GPT-5.4 Pro, I think the 10x claim might simply be because in the >90% load region, you get the famous unbounded delays. And with realistic loss functions like absolute or squared error (consider that in a queue of queues, delays would add) and distributions like Poisson, you'd encounter massively increased losses if you pushed too far towards 100% load. Without extremely detailed accurate statistics of the sort almost no one has, it'd be hard to distinguish 'by eye' 90% from 95%, say, and you'd just see '10x' everywhere you looked.
(And in a pyramid of queues like many layers of reviews, each layer will wind up being about equally loaded, because otherwise you would get a big benefit from adding/removing capacity, so each layer will slowly be optimized towards its breaking point, yielding the 10x everywhere.)
Re: Every layer of review makes you 10x slower
#333[dead]
Re: Every layer of review makes you 10x slower
#334Earlier quoted context omitted.
I’m so disappointed to see the slip in quality by colleagues I think are better than that. People who used to post great PRs are now posting stuff with random unrelated changes, little structs and helpers all over the place that we already have in common modules etc :’(
> little structs and helpers all over the place that we already have in common modules I've often wondered about building some kind of automated "this codebase already has this logic" linter Not sure how it would actually work, otherwise I'd build it. But it would definitely be useful Maybe an AI tool could do something like that nowadays. "Search this codebase for instances of duplicated functions and list them out"…
You only need to detect structuraly similar code.
You absolutely do not need AI for that. You need ASTs.
In Ruby we have the Flay gem, for example.
Re: Every layer of review makes you 10x slower
#335Re: Every layer of review makes you 10x slower
#336Yes, reviewing things make things slower. Not reviewing them produces horrible results. There's a balance to be found and it depends on the team/org.
I hope we shift engineers closer to users than ever before. Get them to understand user's needs and the actual product more - they'll write better plans and prompts. Review the plans.
Code review becomes less of a thing when the team's on the same page, so regularly align on what the goals are.
Accept post-merge code reviews. Things slip, normalise coming back and saying "actually, we should have done this differently". It's not a bad thing, you're learning!
Re: Every layer of review makes you 10x slower
#337But you can’t just not review things! Actually you can. If you shift the reviews far to the left, and call them code design sessions instead, and you raise problems on dailys, and you pair programme through the gnarly bits, then 90% of what people think a review should find goes away. The expectation that you'll discover bugs and architecture and design problems doesn't exist if you've already agreed with the team wh…
Pairing through the gnarly bits is doing the review, just synchronously and earlier. You haven't eliminated reviews — you've moved them to a higher-bandwidth channel. Genuinely better for catching design-level stuff. But it needs overlapping hours and enough shared context to actually work, which falls apart fast across timezones. Async review exists partly because async work does.
Re: Every layer of review makes you 10x slower
#338Earlier quoted context omitted.
The ‘design everything as a publicly accessible API’ directive seems to play to this as well. If all your data / services are available and must be documented then a lot of communication overhead can be eliminated.
For anyone who doesn't know what you mean, here's an archived copy of Steve Yegge's post about this directive + other musings comparing Amazon vs Google (which is how a lot of us came to find out about this, via Yegge's write-up): https://news.ycombinator.com/item?id=3102800 Copied the most relevant snippet below --- So one day Jeff Bezos issued a mandate. He's doing that all the time, of course, and people scramble…
I haven’t read this in years and it was delightful to see it posted here.
Re: Every layer of review makes you 10x slower
#339That’s because most teams are doing engineering wrong. The handover to a peer for review is a falsehood. PRs were designed for open source projects to gate keep public contributors. Teams should be doing trunk-based development, group/mob programming and one piece flow. Speed is only one measure and AI is pushing this further to an extreme with the volume of change and more code. The quality aspect is missing here. S…
I've seen speed without quality in a single founder shop where they piled up tech debt so high, velocity for anything was glacial and they still wouldn't stop to refactor or clean up.
The best balance of individual initiative-velocity vs. peer review culture I've seen was at Facebook.