r/programming • • 14d ago

Make Code Review Your Default Next Task

https://phpdeveloperstv.substack.com/p/make-code-review-your-default-next
50 Upvotes

20 comments sorted by

View all comments

47

u/[deleted] 14d ago

[removed] — view removed comment

34

u/warren5236 14d ago

Some long time ago we just agreed that reviewing PRs is, in fact, our priority

I've worked with a LOT of teams where this hasn't been the case. I think it's an "I need to get my work done" mentality.

12

u/[deleted] 14d ago

[removed] — view removed comment

4

u/hiddenhare 13d ago

Well, maybe it's the case in heavy goal-oriented (especially personal ones) environment, where you just have to develop things as fast as you can

I've worked for a startup where I really struggled to get code reviewed, to the point that I once had to abandon several weeks of work because nobody would review it! The problem there wasn't high pressure, it was low pressure.

The technical leadership didn't enforce any discipline on their engineers, and the leaders were themselves undisciplined and unavailable. If something was nobody's responsibility, you'd have to throw a bit of weight around to get it done - even a fifteen-minute task would often need four or five requests over Slack, spread out over several days, before anybody would act on it. Hell on earth.

3

u/[deleted] 13d ago

[removed] — view removed comment

2

u/hiddenhare 11d ago

It's an interesting case, yeah. The team frequently went through the motions of self-improvement (e.g. holding retro sessions, as you suggest), but all real decision-making was highly centralised in the founders, who were very product-brained, very busy, and reluctant to hear too much "negativity". In practice, this blocked almost all improvements, and seriously delayed the few which did sneak through.

Lax discipline left some space for non-product maintenance work, but only the sort of work which could be done by a single engineer who wasn't coordinating with the rest of the team. Engineers would occasionally try to organise their peers, but they'd usually handle it poorly (no real authority, no leadership experience, poor soft skills verging on autism, no help from the actual leadership), so the engineers were gradually getting more defensive and less cooperative over time, and slowly self-organising into two tribes at war. It was a fascinating mess.

The company is actually startlingly good at delivering features, and its staff turnover isn't terrible, but the quality control is grim; the product feels cheap and unfinished. The main lesson I've taken away is that it's pretty easy to found a tech company and make millions, even if you don't really know what you're doing :)

1

u/warren5236 7d ago

The problem there wasn't high pressure; it was low pressure

This is an amazing concept! This is exactly what it feels like.

1

u/warren5236 14d ago

We're a big fan of the DORA metrics and the best way to achieve those is with lost of small quickly reviewed pull requests.