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

181–190 of 339 posts

Re: Every layer of review makes you 10x slower

#181

Post by orthoxerox »

2OEH8eoCRo0 wrote: post #154
alkonaut wrote: post #107

Earlier quoted context omitted.

This falls for the famous "hours of planning can save minutes of coding". Architecture can't (all) be planned out on a whiteboard, it's the response to the difficulty you only realize as you try to implement. If you can agree what to build and how to build it and then it turns out that actually is a working plan - then you are better than me. That hasn't happened in 20 years of software development. Most of what's pl…

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…

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

That's an interesting observation. That's one of the biggest criticisms of waterfall: by the time you finish building something the requirements have changed already, so you have to rewrite it.

Re: Every layer of review makes you 10x slower

#182

Post by pkos98 »

trymas wrote: post #150
MrBuddyCasino wrote: post #96

Earlier quoted context omitted.

The first one to realise this was Jeff Bezos, afaik. One would think the others have wisened up in the meantime, but no.

> The first one to realise this was Jeff Bezos, afaik I am not aware about the details - can you elaborate?

Maybe the Two Pizza rule:

No team at Amazon should be larger than what two pizzas can feed (usually about 6 to 10 people).

Re: Every layer of review makes you 10x slower

#183

Post by anonymars »

Jensson wrote: post #149
duskdozer wrote: post #146

Earlier quoted context omitted.

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

Why does it sound horrible to have your code reviewed quickly? There is no reason for reviews to wait a long time. 4 hours is already a long time, it means you can wait to do it right before you go home or after lunch.

It sounds horrible to be interrupted constantly. I can't imagine they'd be particularly thorough reviews

Re: Every layer of review makes you 10x slower

#184

Post by furryrain »

gebalamariusz wrote: post #177

Well, this all makes sense for application code, but not necessarily for infrastructure changes. Imagine a failed Terraform merge that deletes the production database but opens the inbound at 0.0.0.0/0, and you can't undo it for 10 minutes. In my opinion, you need to pay attention to the narrow scope specific to a given project.

Try to imagine a deployment/CI system where that isn't possible. That's what the post is asking.

* Maybe you don't have privileges to delete the database

* Maybe your CI environments are actually high fidelity, and will fail when there is no DB

* Maybe destructive actions require further review

* Maybe your service isn't exposed to the public internet, and exposing to 0.0.0.0/0 isn't a problem.

* Maybe we engineer our systems to have trivial instant undo, and deleting a DB triggers an undo

Our tooling is kind of crappy. There's a lot we can do.

Re: Every layer of review makes you 10x slower

#185

Post by furryrain »

ukuina wrote: post #55
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.

> "Mythical Mammoth" Most excellent.

Man moth?

Re: Every layer of review makes you 10x slower

#186

Post by simonw »

MeetingsBrowser wrote: post #23
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.

Isn’t “bad output” already worst case? Pre-LLMs correct output was table stakes. You expect your calculator to always give correct answers, your bank to always transfer your money correctly, and so on.

I've seen plenty of decision makers act on bad output from human employees in the past. The company usually survives.

Re: Every layer of review makes you 10x slower

#187

Post by datsci_est_2015 »

2OEH8eoCRo0 wrote: post #154
alkonaut wrote: post #107

Earlier quoted context omitted.

This falls for the famous "hours of planning can save minutes of coding". Architecture can't (all) be planned out on a whiteboard, it's the response to the difficulty you only realize as you try to implement. If you can agree what to build and how to build it and then it turns out that actually is a working plan - then you are better than me. That hasn't happened in 20 years of software development. Most of what's pl…

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…

> > Most of what's planned falls down within the first few hours of implementation.

> Not my experience at all. We know what computers are capable of.

You must not work in a field where uncertainty is baked in, like Data Science. We call them “hypotheses”. As an example, my team recently had a week-long workshop where we committed to bodies of work on timelines and 3 out of our 4 workstreams blew up just a few days after the workshop because our initial hypotheses were false (i.e. “best case scenario X is true and we can simply implement Y; whoops, X is false, onto the next idea”)

Re: Every layer of review makes you 10x slower

#188

Post by whynotmaybe »

vaylian wrote: post #127
jffhn wrote: post #69

Earlier quoted context omitted.

>Do people really argue about variable names? Of course they do. A program's code is mostly a graph of names; they can be cornerstones of its clarity, or sources of confusion and bugs. The first thing I do when debugging is ensuring proper names, sometimes that's enough to make the bug obvious.

The greatest barrier to understanding is not lack of knowledge but incorrect knowledge. That's why good names matter. And naming things is hard, which is why it makes sense to comment on variable names in a review.

Unless the naming convention were written in the 90s and all variable must follow a precise algorithm to be made of only abbreviation and a maximum length of 15.

Or for some, if it contains the value of a column in the db, it must have the same name as the column.

So yeah, instead of "UsualQuantityOrder", you get "UslQtyOrd" or "I_U_Q_O"... And you must maintain the comments to explain what the field is supposed to contain.

Re: Every layer of review makes you 10x slower

#189

Post by agumonkey »

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…

Anybody has idea on how to avoid childish resistance? Anytime something like this pops up people discuss it into oblivion and teams stay in their old habits

Re: Every layer of review makes you 10x slower

#190

Post by sbarre »

datsci_est_2015 wrote: post #187
2OEH8eoCRo0 wrote: post #154

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…

> > Most of what's planned falls down within the first few hours of implementation. > Not my experience at all. We know what computers are capable of. You must not work in a field where uncertainty is baked in, like Data Science. We call them “hypotheses”. As an example, my team recently had a week-long workshop where we committed to bodies of work on timelines and 3 out of our 4 workstreams blew up just a few days a…

Wait, are you perhaps saying that... "it depends"? ;-)

Every single reply in this thread is someone sharing their subjective anecdotal experience..

There are so many factors involved in how work pans out beyond planning. Even a single one of us could probably tell 10 different stories about 10 different projects that all went differently.

Post reply on HN