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

91–100 of 339 posts

Re: Every layer of review makes you 10x slower

#91

Post by blitzar »

anal_reactor wrote: post #59
recursivecaveat wrote: post #39

Earlier quoted context omitted.

Do people really argue about variable names? Most reviews comments I see are fairly trivial, but almost always not very subjective. (Leftover debug log, please add comment here, etc) Maybe it helps that many of our seniors are from a team where we had no auto-formatter or style guide at all for quite a while. I think everyone should experience that a random mix of `){` and `) {` does not really impact you in any way…

Yes. 80% of comments to my PRs are "change _ to -" or something like that.

PR #467 - Reformat code from tabs to spaces

PR #515 - Reformat code from spaces to tabs

Re: Every layer of review makes you 10x slower

#92

Post by pm215 »

threatofrain wrote: post #81
superlopuh wrote: post #75

In my experience a culture where teammates prioritise review times (both by checking on updates in GH a few times a day, and by splitting changes agressively into smaller patches) is reflected in much faster overall progress time. It's definitely a culture thing, there's nothing technically or organisationally difficult about implementing it, it just requires people working together considering team velocity more imp…

Let's say a teammate is writing code to do geometric projection of streets and roads onto live video. Another teammate is writing code to do automated drone pursuit of cars. Let's say I'm over here writing auth code, making sure I'm modeling all the branches which might occur in some order. To what degree do we expect intellectual peerage from someone just glancing into this problem because of a PR? I would expect th…

If the team is that small and working on things that are that disparate, then it is also very vulnerable to one of those people leaving, at which point there's a whole part of the project that nobody on the team has a good understanding of.

Having somebody else devote enough time to being up to speed enough to do code review on an area is also an investment in resilience so the team isn't suddenly in huge difficulty if the lone expert in that area leaves. It's still a problem, but at least you have one other person who's been looking at the code and talking about it with the now-departed expert, instead of nobody.

Re: Every layer of review makes you 10x slower

#93

Post by DeathArrow »

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?

Re: Every layer of review makes you 10x slower

#94

Post by sevenseacat »

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.

I've had PRs that take me five hours to review. If your one PR is an entire feature that touches the database, the UI, and an API, and I have to do the QA on every part of it because as soon as I give the thumbs up it goes out the door to clients? Then its gonna take a while and I'm probably going to find a few critical issues and then the loop starts again

Re: Every layer of review makes you 10x slower

#95

Post by pdhborges »

Swizec wrote: post #31
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…

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

Re: Every layer of review makes you 10x slower

#96

Post by MrBuddyCasino »

thot_experiment wrote: post #17

Valve is one of the only companies that appears to understand this, as well as that individual productivity is almost always limited by communication bandwidth, and communication burden is exponential as nodes in the tree/mesh grow linearly. [or some derated exponent since it doesn't need to be fully connected]

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

Re: Every layer of review makes you 10x slower

#97

Post by PunchyHamster »

> I know what you're thinking. Come on, 10x? That’s a lot. It’s unfathomable. Surely we’re exaggerating.

See this rarely known trick! You can be up to 9x more efficient if you code something else when you wait for review

> AI

projectile vomits

Fuck engineering, let's work on methods to make artificial retard be more efficient!

Re: Every layer of review makes you 10x slower

#98

Post by namanyayg »

Swizec wrote: post #31
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…

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

How does the phone number help?

Re: Every layer of review makes you 10x slower

#99

Post by kmijyiyxfbklao »

seer wrote: post #47
JoshTriplett wrote: post #26

Earlier quoted context omitted.

> In software it's the opposite, in my experience. That's been my experience as well: ten hours of doing will definitely save you an hour of planning. If you aren't getting requirements from elsewhere, at least document the set of requirements you think you're working towards, and post them for review. You sometimes get new useful requirements very fast if you post "wrong" ones.

I think what they meant is you “can save 10 hours of planning with one hour of doing” And I think this has become even more so with the age of ai, because there is even more unknown unknowns, which is harder to discover while planning, but easy wile “doing” and that “doing” itself is so much more streamlined. In my experience no amount of planning will de-risk software engineering effort, what works is making sure co…

Planning includes the prototype you build with AI.
Post reply on HN