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

271–280 of 339 posts

Re: Every layer of review makes you 10x slower

#271

Post by titzer »

AndrewDucker wrote: post #258
steveBK123 wrote: post #157

Earlier quoted context omitted.

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

Agile largely came about because we thought about where we wanted the product to go, and the steps to get there, and started building, and then it turned out that the way we thought we wanted to go was wrong, and all of that planning we did was completely wasted. If you work in an environment where you definitely do know where you want the product to go, and the customer doesn't change their mind once they've seen th…

It helps to at least write down requirements. And not requirements in that "it must use Reddis", but customer, user, performance, cost, etc requirements.

A one page requirements document is like pulling teeth apparently.

Re: Every layer of review makes you 10x slower

#272

Post by yonaguska »

jakevoytko wrote: post #210
sodapopcan wrote: post #201

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…

For anything complicated or wide in scope, we've found it much more productive to just hop on a call and pair.

Re: Every layer of review makes you 10x slower

#273

Post by [deleted] »

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…

[deleted]

Re: Every layer of review makes you 10x slower

#274

Post by maxothex »

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…

[dead]

Re: Every layer of review makes you 10x slower

#275

Post by onion2k »

DeathArrow wrote: post #93
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…

The issue is that every review adds a lot of delay. A lot of alignment and pair programming won't be time expensive?

A lot of alignment and pair programming won't be time expensive?

The question is really "Will up-front design and pair programming cost more than not doing up-front design and pair programming?".

In my experience, somewhat counter-intuitively, alignment and pairing is cheaper because you get to the right answer a bit 'slower' but without needing the time spent reworking things. If rework is doubling the time it takes to deliver something (which is not an extreme example, and in some orgs would be incredibly conservative) then spending 1.5 times the estimate putting in good design and pair programming time is still waaaay cheaper.

Re: Every layer of review makes you 10x slower

#276

Post by genthree »

palmotea wrote: post #222
hallway_monitor wrote: post #216

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…

Yeah, I’d have a mental breakdown within weeks if I had to pair more than an hour a day, max (even that much, consistently, would probably harm my quality of life quite a bit—a little every now and then is no big deal, though). No exaggeration, it’d break me in ways that’d take a while to fix.

[edit] I’m not even anti-social, but the feeling of being watched while working is extremely draining. An hour of that is like four hours without it.

Re: Every layer of review makes you 10x slower

#277

Post by lostdog »

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.

Maybe it's time to do pair agentic engineering? Have two engineers at the screen, writing the prompts together, and deciding how to verify the results.

Re: Every layer of review makes you 10x slower

#278

Post by kkl »

presentation wrote: post #112

I broadly agree with this, it really is all about trust. Just, as a company scales it’s hard to make sure that everybody in the team remains trustworthy – it isn’t just about personality and culture, it’s also about people actually having the skill, motivation, and track record of doing good work efficiently. Maybe AI‘s greatest value will be to allow teams to stay small, which reduces the difficulty of maintaining t…

It’s also the case that someone you trust makes an honest mistake and, for example, gets their laptop stolen and their credentials compromised. I do trust my team, and want that to be the foundation to our relationship, but I also recognize that humans are infallible and having guardrails (eg code review) is beneficial.

Re: Every layer of review makes you 10x slower

#279

Post by simonw »

swiftcoder wrote: post #144
MeetingsBrowser wrote: post #23

Earlier quoted context omitted.

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.

> Isn’t “bad output” already worst case? Worst case in a modern agentic scenario is more like "drained your bank account to buy bitcoin and then deleted your harddrive along with the private key" > Pre-LLMs correct output was table stakes We're only just getting to the point where we have languages and tooling that can reliably prevent segfaults. Correctness isn't even on the table, outside of a few (mostly academic)…

> Worst case in a modern agentic scenario is more like "drained your bank account to buy bitcoin and then deleted your harddrive along with the private key"

Hence my interest in sandboxes!

Re: Every layer of review makes you 10x slower

#280

Post by ventana »

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…

That's actually one thing that always prevented me from following the standard pathway of "write a design document first, get it approved, then execute" during my years in Google.

I cannot write a realistic non-hand-wavy design document without having a proof of concept working, because even if I try, I will need to convince myself that this part and this part and that part will work, and the only way to do it is to write an actual code, and then you pretty much have code ready, so why bother writing a design doc.

Some of my best (in terms of perf consequences) design documents were either completely trivial from the code complexity point of view, so that I did not actually need to write the code to see the system working, or were written after I already had a quick and dirty implementation working.

Post reply on HN