Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Every layer of review makes you 10x slower

apenwarr.ca

Post reply on HN
Print view View original

201–210 of 339 posts

Re: Every layer of review makes you 10x slower

#201

Post by sodapopcan »

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…

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

Re: Every layer of review makes you 10x slower

#202

Post by muskstinks »

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…

[dead]

Re: Every layer of review makes you 10x slower

#203

Post by swiftcoder »

anal_reactor wrote: post #168
swiftcoder wrote: post #148

Earlier quoted context omitted.

> 2. 90% of PR comments are arguments about variable names. This sort of comment is meaningless noise that people add to PRs to pad their management-facing code review stats. If this is going on in your shop, your senior engineers have failed to set a suitable engineering culture. If you are one of the seniors, schedule a one-on-one with your manager, and tell them in no uncertain terms that code review stats are off…

The most senior guy has the worst reviews because it takes multiple rounds, each round finds new problems. Manager thinks this contributes to code quality. I was denied promotion because I failed to convince half of the company to drop everything and do my manager's pet project that had literally zero business value.

Yeah, I'm afraid that's an engineering culture that is thoroughly cooked. Not much choice except keep your head down until you are ready to cut your losses

Re: Every layer of review makes you 10x slower

#204

Post by sltr »

about a year ago I shared this on /r/AskProgramming:

"...a Pull Request is a delivery. It's like UPS standing at your door with a package. You think, "Nice, the feature, bugfix, etc has arrived! And because it's a delivery, it's also an inspection. A Code Review. Like a freight delivery with a manifest and signoff. So you have to be able to conduct the inspection: to understand what you're receiving and evaluate if it's acceptable as-is. Like signing for a package, once you approve, the code is yours and your team's to keep."

The metaphor has limits. IRL I sign immediately and resolve issues post-hoc with customer service. The UPS guy is not going to stand on my porch while I check if there's actually a bootable MacBook in the box. The vast majority of the time, there's no issue. If that were the same with code, teams could adopt a similar "trust now and defer verification" approach.

The article has a section on Modularity but never defines it. I wrote a post a few weeks ago on modularity and LLMs which does provide a definition. [1].

[1] https://www.slater.dev/2026/02/relieve-your-context-anxiety-...

Re: Every layer of review makes you 10x slower

#205

Post by chrisweekly »

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…

"If you can get the team to that level you can stop doing code reviews."

IMHO / IME (over 20y in dev) reviewing PRs still has value as a sanity check and a guard against (slippery slope) hasty changes that might not have received all of the prior checks you mentioned. A bit of well-justified friction w/ ROI, along the lines of "slow is smooth, smooth is fast".

Re: Every layer of review makes you 10x slower

#206

Post by pixl97 »

steveBK123 wrote: post #178
zingar wrote: post #166

Earlier quoted context omitted.

It’s possible to manage the quarterly expectations by saying “we can improve metric X by 10% in a quarter”. It’s often possible to find an improvement that you’re very confident of making very quickly. Depending on how backwards the company is you may need to hide the fact that the 10% improvement required a one line change after a month of experimentation, or they’ll fight you on the experimentation time and expect…

My experience in an agile firm was that they hired a lot of experienced people and then treated them like juniors. Actively allergic to thinking ahead. To get around the problem that deliverables took more than a few days, actual tasks would be salami sliced down into 3 point tickets that simply delivered the starting state the next ticket needed. None of these tickets being completed was an actual user observable de…

Heh, sounds like Goodhart's law gone wild at that place.

Re: Every layer of review makes you 10x slower

#207

Post by g947o »

sn0wleppard wrote: post #130
christophilus wrote: post #117

Earlier quoted context omitted.

Does your team just context switch all the time? That sounds like a terrible place to work.

Similar in my team and I don't feel like there's much context switching. With around 8 engineers there's usually at least one person not in the middle of something who can spare a few minutes.

How can everyone be familiar with everybody else's work?

Usually at most 2-3 engineer have enough context to fully understand what your code is doing.

Re: Every layer of review makes you 10x slower

#208

Post by rimunroe »

roncesvalles wrote: post #115
riffraff wrote: post #41

Earlier quoted context omitted.

This is also the premise of pair programming/extreme programming: if code review is useful, we should do it all the time .

Anyone who talks about pair programming has either never done them or just started doing them last week.

I worked for five years at a shop where a few years in we started pair programming aggressively. One of our most experienced engineers was really into XP and agile work (in the “purer” meaning of the term). He often suggested pairing when thorny problems came up, and eventually it spread. It often took half or more of the available time for programming each day. That was by far the best working environment I’ve been in. The team was excellent and it seems like we all improved in our skills when we started doing it more. We cut down on how long it took to get in while managing to produce better code. It made planning features and adjusting to unforeseen snags in plans so much quicker. I can’t emphasize enough how much of an impact it made on me as a developer or how much I miss it.

The biggest downside to me was that it forces a level of engagement exceeding the most heads down solo work I’ve done. I’d come home and feel mentally exhausted in a way I didn’t usually.

Re: Every layer of review makes you 10x slower

#209

Post by Hendrikto »

2OEH8eoCRo0 wrote: post #154
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…

I've worked waterfall (defense) and while I hated it at the time I'd rather go back to it. Today we move much faster but often build the wrong thing or rewrite and refactor things multiple times. In waterfall we move glacially but what we would build sticks. Also, with so much up front planning the code practically writes itself. I'm not convinced there's any real velocity gains in agile when factoring in all the fid…

> I'm not convinced there's any real velocity gains in agile when factoring in all the fiddling, rewrites, and refactoring.

That’s not the point. The point is to end up with something actually useful in the end. If the artifact I deliver does not meet requirements, it does not really matter how fast I deliver it.

The reason waterfall methodology falls flat so often is not long delivery times, but ending up with completely the wrong thing.

Re: Every layer of review makes you 10x slower

#210

Post by jakevoytko »

sodapopcan wrote: post #201
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…

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

I also think we're going to see a resurgence of either pair programming, or the buddy system where both engineers take responsibility for the prompting and review and each commit has 2 authors. I actually wrote a post on this subject on my blog yesterday, so I'm happy to see other people saying it too. I've worked on 2-engineer projects recently and it's been way smoother than larger projects. It's just so obvious that asynchronous review cycles are way too slow nowadays, and we're DDoSing our project leaders who have to take responsibility for engineering outcomes.
Post reply on HN