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

211–220 of 339 posts

Re: Every layer of review makes you 10x slower

#211

Post by steveBK123 »

pixl97 wrote: post #206
steveBK123 wrote: post #178

Earlier quoted context omitted.

My experience in an agile firm was that they hired a lot of experienced people and then treated them like juniors. Actively allergic to thinking ahead. To get around the problem that deliverables took more than a few days, actual tasks would be salami sliced down into 3 point tickets that simply delivered the starting state the next ticket needed. None of these tickets being completed was an actual user observable de…

Heh, sounds like Goodhart's law gone wild at that place.

Yes - how to complete story points without actually solving any problems

Re: Every layer of review makes you 10x slower

#212

Post by beepbooptheory »

pu_pe wrote: post #100

Nice piece, and rings true. I also think startups and smaller organizations will be able to capture better value out of AI because they simply don't have all those approval layers.

I do not think you have comprehended the blog.

> you can’t overcome latency with brute force

Curious what rang true to you if not the main point?

Re: Every layer of review makes you 10x slower

#213

Post by lesuorac »

steveBK123 wrote: post #157
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…

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

I think the bigger issue is that Waterfall is often not "Waterfall".

Sure there's a 3000 row excel file of requirements but during development the client still sees the product or slides outlining how the product works and you still had QA that had to test stuff as you made it. Then you make changes based on that feedback.

While Agile often feels like it's lost the plot. We're just going to make something and iterate it into a product people like versus figuring out a product people will like and designing towards it.

Re: Every layer of review makes you 10x slower

#214

Post by teeray »

Code reviews are a volunteer’s dilemma. Nobody is showered with accolades by putting “reviewed a bunch of PRs” on their performance review by comparison with “shipped a bunch of features.” The two go hand-in-hand, but rewards follow marks of authorship despite how much reviewers influence what actually landed in production.

Consequently, people tend to become invested in reviewing work only once it’s blocking their work. Usually, that’s work that they need to do in the future that depends on your changes. However, that can also be work they’re doing concurrently that now has a bunch of merge conflicts because your change landed first. The latter reviewers, unfortunately, won’t have an opinion until it’s too late.

Fortunately, code is fairly malleable. These “reviewers” can submit their own changes. If your process has a bias towards merging sooner, you may merge suboptimal changes. However, it will converge on a better solution more quickly than if your changes live in a vacuum for months on a feature branch passing through the gauntlet of a Byzantine review and CI process.

Re: Every layer of review makes you 10x slower

#215

Post by munksbeer »

nananana9 wrote: post #137
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.

There are examples littered around threads on HN. What happens is when people provide the examples, the goalposts get moved. So people have stopped bothering to reply to these demands.

Re: Every layer of review makes you 10x slower

#216

Post by hallway_monitor »

sodapopcan wrote: post #201
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…

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

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.

Re: Every layer of review makes you 10x slower

#217

Post by apexalpha »

alkonaut wrote: post #107
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 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…

This might be true for tech companies, but the tech department I am in at a large government could absolutely architecture away >95% of 'problems' we are fixing at the end of the SDLC.

Re: Every layer of review makes you 10x slower

#219

Post by lesuorac »

duskdozer wrote: post #160
Jensson wrote: post #149

Earlier quoted context omitted.

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.

Why would I care if my code is reviewed quickly? If the answer is some variant of "I get punished if I don't have enough changes merged in fast enough," that's not helping. From the other side, it's having someone constantly breathe down your neck. Hope you don't get in a flow at the wrong time and need to break it so Mr. Lumbergh doesn't hit you up on Teams. It just reeks of a culture of "unlimited pto," rigid sched…

Because it's basically async pair-programming.

You do a lot of small changes (Argueable you have 8 hours of work a day. How many of them do you need to write 100 loc? After that 100 loc or maybe 200 take a break and review other people's code.

Plus you also have random meetings and stuff so your day already fragments itself so adding a code review in the time before a meeting or after is "free" from a fragmentation standpoint.

Re: Every layer of review makes you 10x slower

#220

Post by DrewADesign »

pdhborges wrote: post #95
Swizec wrote: post #31

Earlier quoted context omitted.

> You also need to build a team that you can trust to write the code you agreed you'd write I tell every hire new and old “Hey do your thing, we trust you. Btw we have your phone number. Thanks” Works like a charm. People even go out of their way to write tests for things that are hard to verify manually. And they verify manually what’s hard to write tests for. The other side of this is building safety nets. Takes ~1…

> The other side of this is building safety nets. Takes ~10min to revert a bad deploy. Does it? Reverting a bad deploy is not only about running the previous version. Did you mess up data? Did you take actions on third party services that that need to be reverted? Did it have legal reprecursions?

Having data model changes be a part of regular deployments would give me persistent heartburn.
Post reply on HN