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

81–90 of 339 posts

Re: Every layer of review makes you 10x slower

#81

Post by threatofrain »

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 that to be the proper intellectual peer of someone studying the problem, it's quite reasonable to basically double your efforts.

Re: Every layer of review makes you 10x slower

#82

Post by eptcyka »

tripledry wrote: post #78
overfeed wrote: post #57

Earlier quoted context omitted.

Perhaps due to FOMO outbreak[1], upper management everywhere has demanded AI-powered productivity gains, based on LoC/PR metrics, it looks like they are getting it. 1. The longer I work in this industry, the more it becomes clear that CxO's aren't great at projecting/planning, and default to copy-cat, herd behaviors when uncertain.

Would love to be a fly on the wall for a couple of months to see what corporate CxO's actually do. Surely I could do a mediocre job as a CxO by parroting whatever is hot on Linkedin. Probably wouldn't be a massively successful one, but good enough to survive 2 years and have millions in the bank for that, or get fired and get a golden parachute. (half) joking - most likely I'm massively trivializing the role.

A charitable explanation for what CxOs do is that they figure out their strategic goals and then focus really hard on ways to herd cats en masse to achieve the goals in an efficient manner. Some people end up doing a great job, some do so accidentally, other just end up doing a job. Sometimes parroting some linkadink drivel is enough to keep the ship on course - usually because the winds are blowing in the right direction or the people at the oars are working well enough on their own.

Re: Every layer of review makes you 10x slower

#84

Post by servo_sausage »

_kidlike wrote: post #72
anal_reactor wrote: post #32

Earlier quoted context omitted.

I never review PRs, I always rubber-stamp them, unless they come from a certified idiot: 1. I don't care because the company at large fails to value quality engineering. 2. 90% of PR comments are arguments about variable names. 3. The other 10% are mistakes that have very limited blast radius. It's just that, unless my coworker is a complete moron, then most likely whatever they came up with is at least in acceptable…

I'm very surprised by these comments... I regularly review code that is way more complicated that it should. The last few days I was going back and forth on reviews on a function that had originally cyclomatic complexity of 23. Eventually I got it down to 8, but I had to call him into a pair programming session and show him how the complexity could be reduced.

Someone giving work like that should be either junior enough that there is potential for training them, so your time investment is worth it, or managed out.

Or it didn't really matter that the function was complex if the structure of what's surrounding it was robust and testable; just let it be a refactor or bug ticket later.

Re: Every layer of review makes you 10x slower

#85

Post by servo_sausage »

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…

This is an unusually low overlap per topic; probably needs a different structure to traditional prs to get the best chance to benefit from more eyes... Higher scope planning or something like longer but intermittent partner programming.

Generally if the reviewer is not familiar with the content asynchronous line by line reviews are of limited value.

Re: Every layer of review makes you 10x slower

#86

Post by ivanjermakov »

lelanthran wrote: post #12

I wonder where the reviewer worked where PRs are addressed in 5 hours. IME it's measured in units of days, not hours. I agree with him anyway: if every dev felt comfortable hitting a stop button to fix a bug then reviewing might not be needed. The reality is that any individual dev will get dinged for not meeting a release objective.

I'm yet to see a project where reviews are handled seriously. Both business and developers couldn't care less.

Re: Every layer of review makes you 10x slower

#87

Post by eterm »

ivanjermakov wrote: post #86
lelanthran wrote: post #12

I wonder where the reviewer worked where PRs are addressed in 5 hours. IME it's measured in units of days, not hours. I agree with him anyway: if every dev felt comfortable hitting a stop button to fix a bug then reviewing might not be needed. The reality is that any individual dev will get dinged for not meeting a release objective.

I'm yet to see a project where reviews are handled seriously. Both business and developers couldn't care less.

I worked somewhere that actually had a great way to deal with this. It only works in small teams though.

We had a "support rota", i.e. one day a week you'd be essentially excused from doing product delivery.

Instead, you were the dev to deal with big triage, any code reviews, questions about the product, etc.

Any spare time was spent looking for bugs in the backlog to further investigate / squash.

Then when you were done with your support day you were back to sprint work.

This meant there was no ambiguity of who to ask for code review, and limited / eliminated siloing of skills since everyone had to be able to review anyone else's work.

That obviously doesn't scale to large teams, but it worked wonders for a small team.

Re: Every layer of review makes you 10x slower

#88

Post by mcdeltat »

ivanjermakov wrote: post #86
lelanthran wrote: post #12

I wonder where the reviewer worked where PRs are addressed in 5 hours. IME it's measured in units of days, not hours. I agree with him anyway: if every dev felt comfortable hitting a stop button to fix a bug then reviewing might not be needed. The reality is that any individual dev will get dinged for not meeting a release objective.

I'm yet to see a project where reviews are handled seriously. Both business and developers couldn't care less.

Bonus points: reviews are not taken seriously in the legitimate sense, but a facade of seriousness consisting of picky complaints is put forth to reinforce hierarchy and gatekeeping

Re: Every layer of review makes you 10x slower

#89

Post by thrwaway55 »

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…

Okay but Claude is a fucking moron.
Post reply on HN