Live data from Hacker News

Every layer of review makes you 10x slower

apenwarr.ca

291–300 of 339 posts

Re: Every layer of review makes you 10x slower

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

>The expectation that you'll discover bugs and architecture and design problems doesn't exist if you've already agreed with the team what you're going to build.

This is like, there's not going to be surprise on the road you'll take if you already set the destination point. Though most of the time, you are just given a vague description of the kind of place you want to reach, not a precise point targeted. And you are not necessarily starting with a map, not even an outdated one. Also geological forces reshape the landscape at least as fast as you are able to move.

Re: Every layer of review makes you 10x slower

#292

Earlier quoted context omitted.

There's an abstraction level above which waterfall makes more sense, and below which [some replacement for agile but without the rituals] makes more sense.

I think Qs to ask are.. if the nature of user facing deliverable tasks are longer than a sprint, the tasks have linear dependencies, there are coordination concerns, etc

Sprints are just ritual though. The others... if you're that low I'd say you're past waterfall since you have well defined tasks while I feel a waterfall like approach is more for initial architecture.

Re: Every layer of review makes you 10x slower

#294
post #182
post #150

Earlier quoted context omitted.

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

I have always been amazed at that rule because it implies developers either do not like pizza or they happen to be on a diet.

Re: Every layer of review makes you 10x slower

#295
post #109
post #66

Earlier quoted context omitted.

These systems make it more efficient to remove the actively toxic members for your team. Beligerence can be passively aggressively “handled” by additional layers but at considerable time and emotional labor cost to people who could be getting more work done without having to coddle untalented assholes.

Sounds like there was a bad hiring process.

There's no such thing as a hiring process that avoids that problem 100% of the time.

After all, most people will be on their best behavior during an interview, and even a lengthy interview process is a very short period of time compared to working with someone for weeks or months.

Re: Every layer of review makes you 10x slower

#296

Earlier quoted context omitted.

Pair programming 100% of also works. It's unfortunately widely unpopular, but it works.

I also think we're going to see a resurgence of either pair programming, or the buddy system where both engineers take responsibility for the prompting and review and each commit has 2 authors. I actually wrote a post on this subject on my blog yesterday, so I'm happy to see other people saying it too. I've worked on 2-engineer projects recently and it's been way smoother than larger projects. It's just so obvious th…

[dead]

Re: Every layer of review makes you 10x slower

#297

Earlier quoted context omitted.

You are exactly correct. As to why it’s unpopular, I believe it’s just that no one has given it a fair try. Once you have done it for at least 20 hours a week for a few weeks you will understand that typing is not and has never been the bottleneck in programming. If you have not tried it then you cannot have an opinion.

> You are exactly correct. As to why it’s unpopular, I believe it’s just that no one has given it a fair try. Once you have done it for at least 20 hours a week for a few weeks you will understand that typing is not and has never been the bottleneck in programming. If you have not tried it then you cannot have an opinion. I haven't tried pair programming except in very ad-hoc situations, but doing it all the time sou…

[dead]

Re: Every layer of review makes you 10x slower

#298

Earlier quoted context omitted.

> I'm not convinced there's any real velocity gains in agile when factoring in all the fiddling, rewrites, and refactoring. That’s not the point. The point is to end up with something actually useful in the end. If the artifact I deliver does not meet requirements, it does not really matter how fast I deliver it. The reason waterfall methodology falls flat so often is not long delivery times, but ending up with compl…

> If the artifact I deliver does not meet requirements, it does not really matter how fast I deliver it. I don’t know. The faster you deliver the wrong thing, the sooner you can discover your mistake and pivot.

You summarized agile. That is the whole point: short feedback cycles. You can view it as a series of short, self-regressive waterfalls.

Re: Every layer of review makes you 10x slower

#299

Earlier quoted context omitted.

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…

I hope you mean "flow state" and not actually "fugue state".

Well, I wrote what I meant, but I meant to be facetious (:

Re: Every layer of review makes you 10x slower

#300
post #109
post #66

Earlier quoted context omitted.

These systems make it more efficient to remove the actively toxic members for your team. Beligerence can be passively aggressively “handled” by additional layers but at considerable time and emotional labor cost to people who could be getting more work done without having to coddle untalented assholes.

Sounds like there was a bad hiring process.

They’re all bad hiring processes. Some worse than others. Hiring known quantities can slip onto nepotism shockingly fast.
Post reply on HN