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

51–60 of 339 posts

Re: Every layer of review makes you 10x slower

#51

Post by balamatom »

zmmmmm wrote: post #29
lelanthran wrote: post #24

Earlier quoted context omitted.

> So in that extra time, you can now stack more PRs that still have a 30 hour review time and have more overall throughput Hang on, you think that a queue that drains at a rate of $X/hour can be filled at a rate of 10x$X/hour? No, it cannot: it doesn't matter how fast you fill a queue if the queue has a constant drain rate, sooner or later you are going to hit the bounds of the queue or the items taken off the queue…

This is the fundamental issue currently in my situation with AI code generation. There are some strategies that help: a lot of the AI directives need to go towards making the code actually easy to review. A lot of it it sits around clarity, granularity (code should be committed primarily in reviewable chunks - units of work that make sense for review) rather than whatever you would have done previously when code prod…

>Finally, changes need to be stratified along lines of risk rather than code modularity or other dimensions.

Why don't those other dimensions, and especially the code modularity, already reflect the lines of business risk?

Lemme guess, you cargo culted some "best practices" to offload risk awareness, so now your code is organized in "too big to fail" style and matches your vendor's risk profile instead of yours.

Re: Every layer of review makes you 10x slower

#52

Post by cindyllm »

habinero wrote: post #45
riffraff wrote: post #34

> Code a simple bug fix 30 minutes > Get it code reviewed by the peer next to you 300 minutes → 5 hours → half a day Is it takes 5 hours for a peer to review a simple bugfix your operation is dysfunctional.

People are busy, and small bugfixes are usually not that critical. If you make everyone drop everything to review everything, that is much more dysfunctional.

[dead]

Re: Every layer of review makes you 10x slower

#53

Post by camillomiller »

>> Now you either get to spend 27 minutes reviewing the code yourself in a back-and-forth loop with the AI (this is actually kinda fun); or you save 27 minutes and submit unverified code to the code reviewer, who will still take 5 hours like before, but who will now be mad that you’re making them read the slop that you were too lazy to read yourself. Little of value was gained.

This seems to check out, and it's the reason why I can't reconcile the claims of the industry about workers replacement with reality. I still wonder when a reckoning will come, though. seems long overdue in the current environment

Re: Every layer of review makes you 10x slower

#54

Post by thi2 »

riffraff wrote: post #34

> Code a simple bug fix 30 minutes > Get it code reviewed by the peer next to you 300 minutes → 5 hours → half a day Is it takes 5 hours for a peer to review a simple bugfix your operation is dysfunctional.

Its rare that devs are on standby, waiting for a pr to review. Usually they are working on their own pr, are in meetings, have focus time.

We talked a lot about the costs of context switches so its reasonable to finish your work before switching to the review.

Re: Every layer of review makes you 10x slower

#56

Post by camillomiller »

onion2k wrote: post #28
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.

Putting too much trust in an agent is definitely a problem, but I have to admit I've written about a dozen little apps in the past year without bothering to look at the code and they've all worked really well. They're all just toys and utilities I've needed and I've not put them into a production system, but I would if I had to. Agents are getting really good, and if you're used to planning and designing up front you…

>> Putting too much trust in an agent is definitely a problem, but I have to admit I've written about a dozen little apps in the past year without bothering to look at the code and they've all worked really well. They're all just toys and utilities I've needed and I've not put them into a production system, but I would if I had to.

I have been doing this to, and I've forgotten half of them. For me the point is that this usage scenario is really good, but it also has no added value to it, really. The moment Claude Code raises it prices 2x this won't be viable anymore, and at the same time to scale this to enterprise software production levels you need to spend on an agent probably as much as hiring two SWEs, given that you need at least one to coordinate the agents.

Re: Every layer of review makes you 10x slower

#57

Post by overfeed »

loire280 wrote: post #25
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'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.

Perhaps due to FOMO outbreak[1], upper management everywhere has demanded AI-powered productivity gains, based on LoC/PR metrics, it looks like they are getting it.

1. The longer I work in this industry, the more it becomes clear that CxO's aren't great at projecting/planning, and default to copy-cat, herd behaviors when uncertain.

Re: Every layer of review makes you 10x slower

#58

Post by zmmmmm »

balamatom wrote: post #51
zmmmmm wrote: post #29

Earlier quoted context omitted.

This is the fundamental issue currently in my situation with AI code generation. There are some strategies that help: a lot of the AI directives need to go towards making the code actually easy to review. A lot of it it sits around clarity, granularity (code should be committed primarily in reviewable chunks - units of work that make sense for review) rather than whatever you would have done previously when code prod…

>Finally, changes need to be stratified along lines of risk rather than code modularity or other dimensions. Why don't those other dimensions, and especially the code modularity, already reflect the lines of business risk? Lemme guess, you cargo culted some "best practices" to offload risk awareness , so now your code is organized in "too big to fail" style and matches your vendor's risk profile instead of yours.

> Why don't those other dimensions, and especially the code modularity, already reflect the lines of business risk?

I guess the answer (if you're really asking seriously) is that previously when code production cost so far outweighed everything else, it made sense to structure everything to optimise efficiency in that dimension.

So if a change was implemented, the developer would deliver it as a functional unit that might cut across several lines of risk (low risk changes like updating some CSS sitting along side higher risk like a database migration, all bundled together). Because this was what made it fastest for the developer to implement the code.

Now if AI is doing it, screw how easy or fast it is to make the change. Deliver it in review chunks.

Was the original method cargo culted? I think most of what we do is cargo culted regardless. Virtually the entire software industry is built that way. So probably.

Re: Every layer of review makes you 10x slower

#59

Post by anal_reactor »

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…

Yes. 80% of comments to my PRs are "change _ to -" or something like that.

Re: Every layer of review makes you 10x slower

#60

Post by ramon156 »

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'm in a company that does no reviews and I'm medior. The tools we make is not interesting at all, so it's probably the best position I could ask for. I occasionally have time to explore some improvements, tools and side projects (don't tell my boss about that last one)
Post reply on HN