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

41–50 of 339 posts

Re: Every layer of review makes you 10x slower

#41

Post by riffraff »

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 is also the premise of pair programming/extreme programming: if code review is useful, we should do it all the time.

Re: Every layer of review makes you 10x slower

#42

Post by cindyllm »

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…

[dead]

Re: Every layer of review makes you 10x slower

#45

Post by habinero »

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.

Re: Every layer of review makes you 10x slower

#46

Post by usr1106 »

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 worked in a company where reviews took days. The CTO complained a lot about the speed, but we had decent code quality.

Now I work at a company where reviews take minutes. We have 5 lines of technical debt per 3 lines of code written. We spend months to work on complicated bugs that have made it to production.

Re: Every layer of review makes you 10x slower

#47

Post by seer »

JoshTriplett wrote: post #26
lmm wrote: post #14

Earlier quoted context omitted.

> As they say: an hour of planning saves ten hours of doing. In software it's the opposite, in my experience. > You don't need so much code or maintenance work if you get better requirements upfront. Sure, and if you could wave a magic wand and get rid of all your bugs that would cut down on maintenance work too. But in the real world, with the requirements we get, what do we do?

> In software it's the opposite, in my experience. That's been my experience as well: ten hours of doing will definitely save you an hour of planning. If you aren't getting requirements from elsewhere, at least document the set of requirements you think you're working towards, and post them for review. You sometimes get new useful requirements very fast if you post "wrong" ones.

I think what they meant is you “can save 10 hours of planning with one hour of doing”

And I think this has become even more so with the age of ai, because there is even more unknown unknowns, which is harder to discover while planning, but easy wile “doing” and that “doing” itself is so much more streamlined.

In my experience no amount of planning will de-risk software engineering effort, what works is making sure coming back and refactoring, switching tech is less expensive, which allows you to rapidly change the approach when you inevitably discover some roadblock.

You can read all the docs during planning phases, but you will stumble with some undocumented behaviour / bug / limitation every single time and then you are back to the drawing board. The faster you can turn that around the faster you can adjust and go forward.

I really like the famous quote from Churchill- “Plans are useless, planning is essential”

Re: Every layer of review makes you 10x slower

#48

Post by rendall »

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…

Yes. This is the way. Declarative design contracts are the answer to A.I. coders. A team declares what they want, agents code it together with human supervision. Then code review is just answering the question "is the code conformant with the design contract?"

But. The design contract needs review, which takes time.

Re: Every layer of review makes you 10x slower

#49

Post by bsjshshsb »

abtinf wrote: post #3
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.

The PR won’t take 5 hours of work, but it could easily sit that long waiting for another engineer to willing to context switch from their own heads-down work.

Exaxtly. Can you get a lawyer on the phone now or do you wait ~ 5 hours. How about a doctor appt. Or a vet appt. Or a mechanic visit.

Needing full human attention on a co.plex task from a pro who can only look at your thing has a wait time. It is worse when there are only 2 or 3 such people in the world you can ask!

Re: Every layer of review makes you 10x slower

#50

Post by balamatom »

lelanthran wrote: post #24
markbao wrote: post #7

If you save 3 hours building something with agentic engineering and that PR sits in review for the same 30 hours or whatever it would have spent sitting in review if you handwrote it, you’re still saving 3 hours building that thing. So in that extra time, you can now stack more PRs that still have a 30 hour review time and have more overall throughput (good lord, we better get used to doing more code review) This doe…

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

You are considering a good-faith environment where GP cares about throughput of the queue.

I think GP is thinking in terms of being incentivized by their environment to demonstrate an image of high personal throughput.

In a dysfunctional organization one is forced to overpromise and underdeliver, which the AI facilitates.

Post reply on HN