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

Re: Every layer of review makes you 10x slower

#281

Post by sodapopcan » Tue, Mar 17, 2026, 5:25 PM UTC

palmotea wrote: post #250

sodapopcan wrote: post #242

Earlier quoted context omitted.

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

It's not black and white because that is my whole point: you have to push through the terribleness at the beginning to start feeling the benefits, and most people aren't willing to. I'm a _massive_ introvert myself, btw. But like, I'm not trying to convince you of anything.

Re: Every layer of review makes you 10x slower

#282

Post by kkl » Tue, Mar 17, 2026, 5:40 PM UTC

> The job of a code reviewer isn't to review code. It's to figure out how to obsolete their code review comment, that whole class of comment, in all future cases, until you don't need their reviews at all anymore.

Making entire classes of issues effectively impossible is definitely the ideal outcome. But, this feels much more complicated when you consider that trust doesn't always extend beyond the company's wall and you cannot always ignore that fact because the negative outcomes can be external to the company.

What if I, a trusted engineer, run `npm update` at the wrong time and malware makes its way into production and user data is stolen? A mistake to learn from, for sure, but a post-mortem is too late for those users.

I'm certainly not advocating for relying on human checks everywhere, but reasoning about where you crank the trust knob can get very complicated or costly. Occasionally a trustworthy human reviewer can be part of a very reasonable control.

Re: Every layer of review makes you 10x slower

#283

Post by bee_rider » Tue, Mar 17, 2026, 5:50 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…

It’s weird that the two tasks that most programmers would agree are most important (reviewing code and deleting code) are not heavily rewarded.

Re: Every layer of review makes you 10x slower

#284

Post by SkyBelow » Tue, Mar 17, 2026, 5:57 PM UTC

bluefirebrand wrote: post #247

denkmoon wrote: post #119

Earlier 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"…

>this codebase already has this logic

At first glance this looks like it might be the halting problem in disguise (instead of the general function of the logic, just ask if they both have logic that halts or doesn't halt). I think we would need to allow for false negatives to even be theoretically possible, so while identical text comparison would be easy enough, anything past that can quickly becomes complicated and you can probably infinitely expand the complexity by handling more and more edge cases (but never every edge case due to the underlying halting problem/undecidability of code).

Re: Every layer of review makes you 10x slower

#285

Post by _kidlike » Tue, Mar 17, 2026, 6:00 PM UTC

zzrrt wrote: post #227

_kidlike wrote: post #72

Earlier quoted context omitted.

I'm very surprised by these comments... I regularly review code that is way more complicated that it should. The last few days I was going back and forth on reviews on a function that had originally cyclomatic complexity of 23. Eventually I got it down to 8, but I had to call him into a pair programming session and show him how the complexity could be reduced.

I know the aggravation of getting a hairball of code to review, but I often hold my nose. At least find a better reason to send it back, like a specific bug. If you're sure cyclomatic complexity should be minimized, I think you should put such rules in a pre-commit hook or something that runs before a reviewer ever sees the code. You should only have to help with that if someone can't figure out how to make it pass.…

I just used it here to approximately convey the scale.

the original function was full of mutable state (not required), full of special cases (not required), full of extra return statements (not required). Also had some private helper methods that were mocked in the tests (!!!).

All of this just for a "pure" function. Just immutable object in - immutable object out.

and yes, he was a junior.

Re: Every layer of review makes you 10x slower

#286

Post by _kidlike » Tue, Mar 17, 2026, 6:00 PM UTC

servo_sausage wrote: post #84

_kidlike wrote: post #72

Earlier quoted context omitted.

I'm very surprised by these comments... I regularly review code that is way more complicated that it should. The last few days I was going back and forth on reviews on a function that had originally cyclomatic complexity of 23. Eventually I got it down to 8, but I had to call him into a pair programming session and show him how the complexity could be reduced.

Someone giving work like that should be either junior enough that there is potential for training them, so your time investment is worth it, or managed out. Or it didn't really matter that the function was complex if the structure of what's surrounding it was robust and testable; just let it be a refactor or bug ticket later.

he is a junior yes.

Re: Every layer of review makes you 10x slower

#287

Post by cherry_tree » Tue, Mar 17, 2026, 6:05 PM UTC

bee_rider wrote: post #283

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…

It’s weird that the two tasks that most programmers would agree are most important (reviewing code and deleting code) are not heavily rewarded.

Unfortunately for programmers, programmers aren’t doing the rewarding

Re: Every layer of review makes you 10x slower

#288

Post by dotancohen » Tue, Mar 17, 2026, 6:06 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…

  > Most of what's planned falls down within the first few hours of implementation.

Planning is priceless. But plans are worthless.

Re: Every layer of review makes you 10x slower

#289

Post by nyrikki » Tue, Mar 17, 2026, 6:10 PM UTC

ventana wrote: post #280

alkonaut wrote: post #107

Earlier quoted context omitted.

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…

That's actually one thing that always prevented me from following the standard pathway of "write a design document first, get it approved, then execute" during my years in Google. I cannot write a realistic non-hand-wavy design document without having a proof of concept working, because even if I try, I will need to convince myself that this part and this part and that part will work, and the only way to do it is to…

That’s why I either started with the ports and adapters pattern or quickly refactored into it on spikes.

You don’t have to choose what flavor of DDD/Clean/… you want to drink, just use some method that keeps domains and use cases separate from implementation.

Just with shapes and domain level tests, the first pass on a spec is easier (at least for me) and I also found feedback was better.

I am sure there are other patterns that do the same, but the trick is to let the problem domain drive, not to choose any particular set of rules.

Keeping the core domain as a fixed point does that for me.

Re: Every layer of review makes you 10x slower

#290

Post by wcfrobert » Tue, Mar 17, 2026, 6:29 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…

Master planning has never worked for my side projects unless I am building the exact replica of what I've done in the past. The most important decisions are made while I'm deep in the code base and I have a better understanding of the tradeoffs.

I think that's why startups have such an edge over big companies. They can just build and iterate while the big company gets caught up in month-long review processes.