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

31–40 of 339 posts

Re: Every layer of review makes you 10x slower

#31

Post by Swizec »

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…

> You also need to build a team that you can trust to write the code you agreed you'd write

I tell every hire new and old “Hey do your thing, we trust you. Btw we have your phone number. Thanks”

Works like a charm. People even go out of their way to write tests for things that are hard to verify manually. And they verify manually what’s hard to write tests for.

The other side of this is building safety nets. Takes ~10min to revert a bad deploy.

Re: Every layer of review makes you 10x slower

#32

Post by anal_reactor »

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…

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 state, in which case there's no point delaying the project.

Regarding knowledge share, it's complete fiction. Unless you actually make changes to some code, there's zero chance you'll understand how it works.

Re: Every layer of review makes you 10x slower

#33

Post by totetsu »

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 seems to be a core of the problem with trying to leave things to autonomous agents .. The response to Amazons agents deleting prod was to implement review stages

https://blog.barrack.ai/amazon-ai-agents-deleting-production...

Re: Every layer of review makes you 10x slower

#35

Post by devmor »

anal_reactor wrote: post #32
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…

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…

I used to do this! I can’t anymore, not with the advent of AI coding agents.

My trust in my colleagues is gone, I have no reason to believe they wrote the code they asked me to put my approval on, and so I certainly don’t want to be on a postmortem being asked why I approved the change.

Perhaps if I worked in a different industry I would feel like you do, but payments is a scary place to cause downtime.

Re: Every layer of review makes you 10x slower

#36

Post by devmor »

lelanthran wrote: post #12

I wonder where the reviewer worked where PRs are addressed in 5 hours. IME it's measured in units of days, not hours. I agree with him anyway: if every dev felt comfortable hitting a stop button to fix a bug then reviewing might not be needed. The reality is that any individual dev will get dinged for not meeting a release objective.

I’ve worked on teams like you describe and it’s been terrible. My current team’s SDLC is more along the 5-hour line - if someone hasn’t reviewed your code by the end of today, you bring it up in standup and have someone commit to doing it.

Re: Every layer of review makes you 10x slower

#37

Post by CBLT »

lelanthran wrote: post #6
tptacek wrote: post #2

Not before coding agents nor after coding agents has any PR taken me 5 hours to review. Is the delay here coordination/communication issues, the "Mythical Mammoth" stuff? I could buy that.

Some devs interrupt what they are doing when they see a PR in a Slack notification, most don't. Most devs set aside some time at most twice a day for PRs. That's 5 hours at least. Some PRs come in at the end of the day and will only get looked at the next day. That's more than 5 hours. IME it's rare to see a PR get reviewed in under 5 hours.

I use a PR notifier chrome extension, so I have a badge on the toolbar whenever a PR is waiting on me. I get to them in typically <2 minutes during work hours because I tab over to chrome whenever AI is thinking. Sometimes I even get to browse HN if not enough PRs are coming and not too many parallel work sessions.

Re: Every layer of review makes you 10x slower

#38

Post by riffraff »

lelanthran wrote: post #6
tptacek wrote: post #2

Not before coding agents nor after coding agents has any PR taken me 5 hours to review. Is the delay here coordination/communication issues, the "Mythical Mammoth" stuff? I could buy that.

Some devs interrupt what they are doing when they see a PR in a Slack notification, most don't. Most devs set aside some time at most twice a day for PRs. That's 5 hours at least. Some PRs come in at the end of the day and will only get looked at the next day. That's more than 5 hours. IME it's rare to see a PR get reviewed in under 5 hours.

But there's more than one person that can review a PR.

If you work in a team of 5 people, and each one only reviews things twice a day, that's still less than 5 hours any way you slice it.

Re: Every layer of review makes you 10x slower

#39

Post by recursivecaveat »

anal_reactor wrote: post #32
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…

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 beyond the mild irking of a crooked painting or something. There's a difference between aesthetically bothersome and actually harmful. Not to say that you shouldn't run a formatter, but just for some perspective.

Re: Every layer of review makes you 10x slower

#40

Post by riffraff »

KnuthIsGod wrote: post #16
simonw wrote: post #11

This is one of the reasons I'm so interested in sandboxing. A great way to reduce the need for review is to have ways of running code that limit the blast radius if the code is bad. Running code in a sandbox can mean that the worst that can happen is a bad output as opposed to a memory leak, security hole or worse.

And if the bad output leads to a decision maker making a bad decision, that takes down your company or kills your relative ?

The sandbox in question was to absorb shrapnel from explosions, clearly
Post reply on HN