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

131–140 of 339 posts

Re: Every layer of review makes you 10x slower

#131

Post by raphlinus »

tripledry wrote: post #78
overfeed wrote: post #57

Earlier quoted context omitted.

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.

Would love to be a fly on the wall for a couple of months to see what corporate CxO's actually do. Surely I could do a mediocre job as a CxO by parroting whatever is hot on Linkedin. Probably wouldn't be a massively successful one, but good enough to survive 2 years and have millions in the bank for that, or get fired and get a golden parachute. (half) joking - most likely I'm massively trivializing the role.

Funny enough, the author of this blog post wrote another one on exactly that topic, entitled "What do executives do, anyway?"[1]. If you read it, you'll find it's written from quite an interesting perspective, not quite "fly on the wall," but perhaps as close as you're going to get in a realistic scenario.

[1]: https://apenwarr.ca/log/20190926

Re: Every layer of review makes you 10x slower

#133

Post by interroboink »

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.

My sense is that there is a narrow slice of software developers who genuinely do flourish in a pair programming environment. These are people who actually work through their thoughts better with another person in the loop. They get super excited about it and make the common mistake of "if it works for me, it will work for everybody" and shout it from the hilltops.

Then there are the people who program best in a fugue state and the idea of having to constantly break that to transform their thoughts into words and human interaction is anathema.

I say this as someone who just woke up in the wee hours of the morning when nobody else is around so I can get some work done (:

Re: Every layer of review makes you 10x slower

#135

Post by nicoburns »

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 like pair programming for certain problems: things that are genuinely hard / pushing the boundaries of both participants knowledge and abilities. In those scenarios sometimes two minds can fill in each other's gaps much more efficiently than either can work alone.

Re: Every layer of review makes you 10x slower

#137

Post by nananana9 »

nfw2 wrote: post #101

from article: 1. Whoa, I produced this prototype so fast! I have super powers! 2. This prototype is getting buggy. I’ll tell the AI to fix the bugs. 3. Hmm, every change now causes as many new bugs as it fixes. 4. Aha! But if I have an AI agent also review the code, it can find its own bugs! 5. Wait, why am I personally passing data back and forth between agents 6. I need an agent framework 7. I can have my agent wri…

I've been begging left and right, and I've yet to see a single example of this agent-written high-quality quickly-shipped code.

Re: Every layer of review makes you 10x slower

#138

Post by orwin »

> 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.

That's me. I'm the mad reviewer. Each time I ranted against AI on this site, it was after reviewing sloppy code.

Yes, Claude Opus is better on average than my juniors/new hires. But it will do the same mistakes twice. I _need_ you to fucking review your own generated code and catch the obvious issues before you submit it to me. Please.

Re: Every layer of review makes you 10x slower

#139

Post by workmandan »

yxhuvud wrote: post #65
Aurornis wrote: post #10

Earlier quoted context omitted.

The article is referring to the total time including delays. It isn’t saying that PR review literally takes 5 hours of work. It’s saying you have to wait about half a day for someone else to review it.

Which is a thing that depend very much on team culture. In my team it is perhaps 15 min for smaller fixes to get signoff. There is a virtuous feedback loop here - smaller PRs give faster reviews, but also more frequent PRs, which give more frequent times to actually check if there is something new to review.

If I'm deep in coding flow the last thing I'm going to do is immediately jump on to someone else's PR. Half a day to a day sounds about right from when the PR is submitted to actually getting the green light

Re: Every layer of review makes you 10x slower

#140

Post by ap99 »

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…

Unless you're covering 100% of edge/corner cases during planning (including roughly how they're handled) then there is still value in code reviews.

You conveniently brushed this under the rug of pair programming but of the handful of companies I've worked at, only one tried it and just as an experiment which in the end failed because no one really wanted to work that way.

I think this "don't review" attitude is dangerous and only acceptable for hobby projects.

Post reply on HN