Live data from Hacker News

Every layer of review makes you 10x slower

apenwarr.ca

161–170 of 339 posts

Re: Every layer of review makes you 10x slower

#161
post #47

Earlier quoted context omitted.

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

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

I really like Churchill’s second famous quote: “What the fuck is software, lol”.

Re: Every layer of review makes you 10x slower

#162

Managers are expected to say that we should be productive yet they're responsible for the framework which slows down everyone and it's quite clear that they're perfectly fine with this framework. I'm not saying it's good or bad because it's complicated.

A few years ago there was a thread about "How complex systems fail" here on HN[1], and one aspect of it (rule 9) is about how individuals have to balance between security and productivity, and being judged differently depending on the context (especially being judged after-the-fact for the security aspect, while being judged before the accident for the productivity aspect).

The linked page in the thread is short and quite enlightening, but here is the relevant passage:

  > Rule 9: Human operators have dual roles: as producers & as defenders against failure.

  > The system practitioners operate the system in order to produce its desired product and also work to forestall accidents. This dynamic quality of system operation, the balancing of demands for production against the possibility of incipient failure is unavoidable. Outsiders rarely acknowledge the duality of this role. In non-accident filled times, the production role is emphasized. After accidents, the defense against failure role is emphasized. At either time, the outsider’s view misapprehends the operator’s constant, simultaneous engagement with both roles.
[1] https://news.ycombinator.com/item?id=32895812

Re: Every layer of review makes you 10x slower

#163

Earlier quoted context omitted.

My last FAANG team had a soft 4-hour review SLA, but if it was a complicated change then that might just mean someone acknowledging it and committing to reviewing it by a certain date/time. IIRC, if someone requested a review and you hadn't gotten to it by around the 3-hour mark you'd get an automated chat message "so-and-so has been waiting a while for your review". Everyone was very highly paid, managers measured e…

That sounds horrible. I don't know how people stand to work in those conditions.

Well, there's a reason I'm no longer working there :)

But some people will put up with a lot for half a million dollars a year.

Re: Every layer of review makes you 10x slower

#164

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

> I still wonder when a reckoning will come, though. seems long overdue in the current environment

Never. Until 1-10 person teams starts disrupt enterprises (legacy banks, payments systems, consultancies).

“Why” would you ask? Because it’s a house of cards. If engineers get redundant, then we don’t need teams. If we don’t need teams, then we don’t need team leads/PMs/POs and others, if we don’t need middle management, then we don’t need VPs and others. All of those layers will eventually catch up to what’s going on and kill any productivity gains via bureaucracy.

Re: Every layer of review makes you 10x slower

#165

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

I don't agree with this take in the article. One person with Claude Code can replace a team of devs. It resolves many issues, such as the tension between devs wanting to focus and devs wanting their peers to put aside their task to review their pull requests. Claude generates the code and the human reviews it. There's no delay in the back-and-forth unlike in a team of humans. There's no ego and there's no context swi…

You’re talking from idealistic requirements - input - programming - output point. That’s not how the world operates. Egos are “important”, politics, bureaucracy, all of those are essential parts of the organizations. LLMs don’t change that, and without changing that there’s no chance at all. Previously coding was maybe 0.1 bottleneck, now it’s 0.07 bottleneck.

Re: Every layer of review makes you 10x slower

#166

Earlier quoted context omitted.

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've worked waterfall and while I hated it at the time I'd rather go back to it. Today we move much faster but build the wrong thing or rewrite and refactor things multiple times. My experience as well. Waterfall is like - let's think about where we want this product to go, and the steps to get there. Agile is like ADHD addled zig zag journey to a destination cutting corners because we are rewriting a component for…

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 that one line to take 5 minutes, after which you should write lots more code that adds no value.

Agile isn’t a good match for a business that can only think in terms of effort and not learning+value. That doesn’t make agile the problem.

Re: Every layer of review makes you 10x slower

#167

> I know what you're thinking. Come on, 10x? That’s a lot. It’s unfathomable. Surely we’re exaggerating. See this rarely known trick! You can be up to 9x more efficient if you code something else when you wait for review > AI projectile vomits Fuck engineering, let's work on methods to make artificial retard be more efficient!

> See this rarely known trick! You can be up to 9x more efficient if you code something else when you wait for review

Context switch alone would kill any productivity gains from this. And I’m not even touching on conflicting MRs and interdependencies yet.

Re: Every layer of review makes you 10x slower

#168

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…

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

Re: Every layer of review makes you 10x slower

#169

Earlier quoted context omitted.

That sounds horrible. I don't know how people stand to work in those conditions.

Well, there's a reason I'm no longer working there :) But some people will put up with a lot for half a million dollars a year.

Ahh, that would do it. I don't think I have it in me, but I get it.

Re: Every layer of review makes you 10x slower

#170

Earlier quoted context omitted.

My last FAANG team had a soft 4-hour review SLA, but if it was a complicated change then that might just mean someone acknowledging it and committing to reviewing it by a certain date/time. IIRC, if someone requested a review and you hadn't gotten to it by around the 3-hour mark you'd get an automated chat message "so-and-so has been waiting a while for your review". Everyone was very highly paid, managers measured e…

That sounds horrible. I don't know how people stand to work in those conditions.

Sounds kind of amazing to me. 4 hours is a bit ridiculous, but I wish we had some kind of automated system to poke people about reviews so I don't have to. It's doubly bad because a) I have to do it, and b) it makes me look annoying.

My ideal system (for work) would be something like: after 2 days, ask for a review if the reviewer hasn't given it. After a week, warn them the PR will be auto-approved. After 2 weeks, auto-approve it.

Post reply on HN