Every layer of review makes you 10x slower • Hacker News Board

Re: Every layer of review makes you 10x slower

#241

Post by ndriscoll » Tue, Mar 17, 2026, 2:27 PM UTC

teeray wrote: post #214

Code reviews are a volunteer’s dilemma. Nobody is showered with accolades by putting “reviewed a bunch of PRs” on their performance review by comparison with “shipped a bunch of features.” The two go hand-in-hand, but rewards follow marks of authorship despite how much reviewers influence what actually landed in production. Consequently, people tend to become invested in reviewing work only once it’s blocking their w…

I've always encouraged everyone more junior to review everything regardless of who signs off, and even if you don't understand what's going on/why something was done in a particular way, to not be shy to leave comments asking for clarification. Reviewing others' work is a fantastic way to learn. At a lower level, do it selfishly.

If you're aiming for a higher level, you also need to review work. If you're leading a team or above (or want to be), I assume you'll be doing a lot of reviewing of code, design docs, etc. If you're judged on the effectiveness of the team, reviews are maybe not an explicit part of some ladder doc, but they're going to be part of boosting that effectiveness.

Re: Every layer of review makes you 10x slower

#242

Post by sodapopcan » Tue, Mar 17, 2026, 2:35 PM UTC

palmotea wrote: post #239

sodapopcan wrote: post #230

Earlier quoted context omitted.

Well as the person you are replying to said, it's hard to have an opinion when you haven't actually tried it. I don't find it like that at all. Also, it doesn't mean you get NO solo time. Pairs can decide to break up for a bit and of course sometimes people aren't in leaving your team with an odd number of people, so some _has_ to solo (though sometimes we'd triple!) But it's something you have to work at which is de…

> Well as the person you are replying to said, it's hard to have an opinion when you haven't actually tried it. I don't find it like that at all. I don't need to try pair programming because I know how that level of constant social interaction makes me feel. > Otherwise, saying it sucks without giving it a real try is akin to saying, "I went for a run and didn't lose any weight so I feel that running is exhausting wi…

I wouldn't call "work" social interaction but I get ya. It's my biggest pet peeve of this industry: it has a whole lot of people who just don't want to talk to anyone. It is what it is, though.

Re: Every layer of review makes you 10x slower

#243

Post by drob518 » Tue, Mar 17, 2026, 2:43 PM UTC

Overall, this is pretty accurate. Of course, it’s a range at every level, say 5x-15x. Large companies trend toward 15x and startups toward 5x, which is why startups out-execute large companies. Also, they just skip some levels of review because, for instance, the CEO is sitting in a code review meeting. But yea, the average is close.

Re: Every layer of review makes you 10x slower

#244

Post by pavel_lishin » Tue, Mar 17, 2026, 2:43 PM UTC

lesuorac wrote: post #219

duskdozer wrote: post #160

Earlier quoted context omitted.

Why would I care if my code is reviewed quickly? If the answer is some variant of "I get punished if I don't have enough changes merged in fast enough," that's not helping. From the other side, it's having someone constantly breathe down your neck. Hope you don't get in a flow at the wrong time and need to break it so Mr. Lumbergh doesn't hit you up on Teams. It just reeks of a culture of "unlimited pto," rigid sched…

Because it's basically async pair-programming. You do a lot of small changes ( Argueable you have 8 hours of work a day. How many of them do you need to write 100 loc? After that 100 loc or maybe 200 take a break and review other people's code. Plus you also have random meetings and stuff so your day already fragments itself so adding a code review in the time before a meeting or after is "free" from a fragmentation…

> Argueable you have 8 hours of work a day. How many of them do you need to write 100 loc?

I have an issue at work that will likely be solved by a single line change. But figuring out which line it is is going to take awhile.

Re: Every layer of review makes you 10x slower

#245

Post by jayd16 » Tue, Mar 17, 2026, 2:44 PM UTC

onion2k wrote: post #22

But 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…

Linting isn't going to catch most malicious implementation patterns. You still need to sniff test what was written.

Re: Every layer of review makes you 10x slower

#246

Post by eyelidlessness » Tue, Mar 17, 2026, 3:03 PM UTC

alkonaut wrote: post #107

onion2k wrote: post #22

But 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…

This falls for the famous "hours of planning can save minutes of coding". Architecture can't (all) be planned out on a whiteboard, it's the response to the difficulty you only realize as you try to implement. If you can agree what to build and how to build it and then it turns out that actually is a working plan - then you are better than me. That hasn't happened in 20 years of software development. Most of what's pl…

It’s a muscle you can exercise, and doing so helps you learn what to focus on so it’ll be successful. IME a very successful approach is to focus on interfaces, especially at critical boundaries (critical for your use case first, then critical for your existing design/architecture).

Doing this often settles the design direction in a stable way early on. More than that, it often reveals a lot of the harder questions you’ll need to answer: domain constraints and usage expectations.

Putting this kind of work upfront can save an enormous amount of time and energy by precluding implementation work on the wrong things, and ruling out problematic approaches for both the problem at hand as well as a project’s longer term goals.

Re: Every layer of review makes you 10x slower

#247

Post by bluefirebrand » Tue, Mar 17, 2026, 3:06 PM UTC

denkmoon wrote: post #119

loire280 wrote: post #25

Earlier quoted context omitted.

I've seen engineers I respect abandon this way of working as a team for the productivity promise of conjuring PRs with a coding agent. It blows away years of trust so quickly when you realize they stopped reviewing their own output.

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" sort of thing

Re: Every layer of review makes you 10x slower

#248

Post by pydry » Tue, Mar 17, 2026, 3:08 PM UTC

alkonaut wrote: post #229

sodapopcan wrote: post #201

Earlier quoted context omitted.

Pair programming 100% of also works. It's unfortunately widely unpopular, but it works.

The problem is that you can only meaningfully pair program with programmers. The people involved in architexture/design meetings might not be programmers. The questions that arise when 2 programmers work might not be resolvable without involving the others.

Nonsense. I pair all the time with stakeholders. If you strip out all of the cucumber nonsense this is essentially what BDD is - fleshing out and refining specs by guiding people through concrete, written example scenarios.

I also often pair with infrastructure people on solving a problem - e.g. "im trying to do x as per the docs, but if you look at my screen i get an 1003 error code any idea what went wrong?".

Or, people on a different team whose microservice talks to mine when debugging an issue or fleshing out an API spec.

It's true that this isnt possible in plenty of organizations due to the culture, but lots of organizations are broken in all sorts of ways that set piles of cash on fire. This one isnt unique.

Re: Every layer of review makes you 10x slower

#249

Post by alemanek » Tue, Mar 17, 2026, 3:18 PM UTC

recursivecaveat wrote: post #39

anal_reactor wrote: post #32

Earlier quoted context omitted.

I never review PRs, I always rubber-stamp them, unless they come from a certified idiot: 1. I don't care because the company at large fails to value quality engineering. 2. 90% of PR comments are arguments about variable names. 3. The other 10% are mistakes that have very limited blast radius. It's just that, unless my coworker is a complete moron, then most likely whatever they came up with is at least in acceptable…

Do people really argue about variable names? Most reviews comments I see are fairly trivial, but almost always not very subjective. (Leftover debug log, please add comment here, etc) Maybe it helps that many of our seniors are from a team where we had no auto-formatter or style guide at all for quite a while. I think everyone should experience that a random mix of `){` and `) {` does not really impact you in any way…

I have seen this mostly on teams which refuse to formalize preferences into a style guide.

I have fixed this by forcing the issue and we get together as a team, set a standard and document it. If we can use tools to enforce it automatically we do that. If not you get a comment with a link to the style guide and told to fix it.

Style is subjective but consistency is not. Having a formal style guide which is automatically enforced helps with onboarding and code review as well.

Re: Every layer of review makes you 10x slower

#250

Post by palmotea » Tue, Mar 17, 2026, 3:22 PM UTC

sodapopcan wrote: post #242

palmotea wrote: post #239

Earlier quoted context omitted.

> Well as the person you are replying to said, it's hard to have an opinion when you haven't actually tried it. I don't find it like that at all. I don't need to try pair programming because I know how that level of constant social interaction makes me feel. > Otherwise, saying it sucks without giving it a real try is akin to saying, "I went for a run and didn't lose any weight so I feel that running is exhausting wi…

I wouldn't call "work" social interaction but I get ya. It's my biggest pet peeve of this industry: it has a whole lot of people who just don't want to talk to anyone. It is what it is, though.

> I wouldn't call "work" social interaction but I get ya.

IMHO, social interaction is anything where you interact with other people.

> It's my biggest pet peeve of this industry: it has a whole lot of people who just don't want to talk to anyone.

That's very black and white thinking. I like talking to other people, but too much of it is draining. Every day spending all-day or even a half-day working directly with someone else? No thanks.