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

321–330 of 339 posts

Re: Every layer of review makes you 10x slower

#321

Post by AndrewDucker »

titzer wrote: post #271
AndrewDucker wrote: post #258

Earlier quoted context omitted.

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.

Oh yes, you want a vague idea of where you're going, and concrete plans for the next step. If you can't even get one-page requirements then something has gone very badly wrong.

Re: Every layer of review makes you 10x slower

#322

Post by zingar »

steveBK123 wrote: post #178
zingar wrote: post #166

Earlier quoted context omitted.

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…

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…

I have so many thoughts:

Depending on the reality, either that company doesn't understand agile very well, or you didn't understand the importance of the small steps.

A plan is not made agile by being split into many small sequential steps; what would make this agile is learning from each step and being prepared to scrap steps 2-8 if step 1 turns out to be enough. Usually this attitude results in splits that make more sense and do add user value.

OTOH I've seen many experienced folks get tripped up because it's easy to get consumed and not evaluate work vs the customer value when you're in the middle of a big task.

For example on an internationalisation project a dev thought: "Every translation key is handled the same way in Rails, let me just do them all at once"; spent weeks with the appearance of no progress because they were working through many cases often slightly more complicated than imagined. They said out loud ~ "I'm not working just for the sake of a task board, the work needs to be done, let's be better than box ticking, it's all one logically consistent piece of work".

I had to interrupt to point out that most of the pages were either about to be deleted or were only needed later. Meanwhile we had tons of work that needed this person's attention on things that were of immediate importance.

It's also important to work in a way that a high number of PRs is not a penalty. It's a smell if we're motivated to reduce the number of PRs because shipping PRs feels difficult.

Re: Every layer of review makes you 10x slower

#323

Post by zingar »

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.

Maybe. It might also have nothing to do with ill-conceived attempts at evaluation. I sometimes suggest teams work in steps that small (usually because they don't have the experience to handle something bigger) and it has nothing to do with evaluating the team. It has everything to do with them learning to move precisely and avoid mistakes.

Re: Every layer of review makes you 10x slower

#324

Post by pydry »

nomel wrote: post #315
pydry wrote: post #248

Earlier quoted context omitted.

Nonsense. I pair all the time with stakeholders. If you strip out all of the cucumber nonsense this is essentially what BDD is - fleshing out and refining specs by guiding people through concrete, written example scenarios. I also often pair with infrastructure people on solving a problem - e.g. "im trying to do x as per the docs, but if you look at my screen i get an 1003 error code any idea what went wrong?". Or, p…

you're missing the context of this thread. for the purpose of code quality/review, it can only work if the other person is a programmer.

I interpreted what they meant as "pairing doesnt work with non coders doing non coding design/architecture/requirements".

Not "pair programming doesnt work with non programmers doing pure programming" coz it doesnt make much sense why you'd even attempt to do that. They dont care and they will get in the way.

Re: Every layer of review makes you 10x slower

#325

Post by oktcho »

alkonaut wrote: post #104

I think this makes an assumption early on which is that things are serialized, when usually they are not. If I complete a bugfix every 30 minutes, and submit them all for review, then I really don't care whether the review completes 5 hours later. By that time I have fixed 10 more bugs! Sure, getting review feedback 5 hours later will force me to context switch back to 10 bugs ago and try to remember what that was ab…

Not sure, but there might be a misunderstanding here:

The value of your bug fix is cashed out only when it reaches the customer, not when you have finished implementing it.

There is a cost of delay for value to reach the customer, and we want that delay to be as short as possible.

So it doesn't matter if you fix 10 bugs because your 10th bug is going to reach production 5x10 hours (that's an exageration, but you get the point) after you had fixed it (which is why the article mentions latency and not touch time)

You can tell me "yes but I also participate in the code review effort in parallel). Yes, but then you are not fixing 10 bugs, you are fixing less and reviewing more, and reviews take longer than implementation (especially with LLMs now in the loop).

It's because of the pretty counter-intuitive Little's Law : the more in-progress you have in parallel, the slower it will get for each item to be completed.

Re: Every layer of review makes you 10x slower

#326

Post by DrewADesign »

redman25 wrote: post #234
DrewADesign wrote: post #220

Earlier quoted context omitted.

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

It's why you always have a rollback plan. Every `up` needs to a `down`.

Aircraft engineer: “That’s why you have parachutes.”

They might be an appropriate safeguard for a prototyping shop, but not for Delta.

Re: Every layer of review makes you 10x slower

#327

Post by FromTheFirstIn »

pydry wrote: post #155
serial_dev wrote: post #128

Earlier quoted context omitted.

Software engineers are pushed to their limits (and beyond). Unrealistic expectations are established by Twitter "I shipped an Uber clone in 2 hours with Claude" forcing every developer to crank out PRs, managers are on the look out for any kind of perceived inefficiency in tools like GetDX and Span. If devs are expected to ship 10x faster (or else!), then they will find a way to ship 10x faster.

I always found it weird how most management would do almost anything other than ask their dev team "hey, is there any way to make you guys more productive?" Ive had metrics rammed down my throat, Ive had AI rammed down my throat, Scrum rammed down my throad and Ive had various other diktats rammed down my throat. 95% of which slowed us down. The only time ive been asked is when there is a deadline and it's pretty cle…

In my experience what you’ve described as the ideal setting for Eng work does lead to a very high quality product. The problem then is understanding if the market you’re in values high quality over speed or familiarity. All markets claim to value quality, many markets don’t.

Re: Every layer of review makes you 10x slower

#328

Post by apenwarr »

kkl wrote: post #282

> The job of a code reviewer isn't to review code. It's to figure out how to obsolete their code review comment, that whole class of comment, in all future cases, until you don't need their reviews at all anymore. Making entire classes of issues effectively impossible is definitely the ideal outcome. But, this feels much more complicated when you consider that trust doesn't always extend beyond the company's wall and…

Japanese manufacturing addressed this too! There’s a whole branch of Deming’s work around supply chains and how it’s often worth working with “more expensive” suppliers when their quality is consistently high, because compensating for low quality inputs to your own work is far more expensive.

Re: Every layer of review makes you 10x slower

#329

Post by apenwarr »

SmashngKbds wrote: post #314

This was well written and it hit hard. It brought clarity to an uneasy collection of gut feels, anecdotal evidence, and fundamental beliefs like nothing else. What I'm feeling might even be categorized as an epiphany. I've always liked Tailscale as a product and now I might be a fan of their CEO too. Who knew? I'll be sharing this post widely. Avery - if you're on here, thanks for writing this!

I’m glad you liked it!

Re: Every layer of review makes you 10x slower

#330

Post by kaffekaka »

dotancohen wrote: post #288
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…

> Most of what's planned falls down within the first few hours of implementation. Planning is priceless. But plans are worthless.

I am stealing that quote.
Post reply on HN