Baldur BjarnasonMar 16
The two worlds of programming: why developers who make the same observations about LLMs come to opposite conclusions: https://www.baldurbjarnason.com/2026/the-two-worlds-of-programming/
The two worlds of programming: why developers who make the same observations about LLMs come to opposite conclusions

Writing at the end of the world, from Hveragerði, Iceland

Show threadragmanMar 16

@baldur Great essay! I largely agree with it.

It's a throw-away line, but you say that "code review is the norm even though it’s largely useless as practised".

Why do you think it's useless/how could it be practiced better?

For my two cents:

I feel like code review is a bad way to catch bugs (yet another reason that "humans check all the AI output" is doomed to failure).

But I do think of it as a good way to keep a codebase consistent and to share knowledge between team members.

Show threadBigSaur GMar 16
@ragman @baldur The domination of code review in the industry largely comes from the powerful mythology of the open source model (central maintainers/gatekeepers, distributed async contributors). Async individual work that fits in a Gantt chart is also the way most managers think, and modern era individualism means we are more inclined to play the blame game behind the comfort of our respective screens than really cooperate. In a lot of contexts though, synchronous collaboration through pair/mob programming ensures higher-fidelity shared knowledge, better focus and involvement during coding, creates a more immediate feedback loop on the quality of produced code and reduces the integration time of features.
Show threadragman

@GuillaumeL @baldur Interesting! The blame game bit rings true, at least in the more toxic environments I've been in. Though I'd say I've more often seen indifference than blame -- code review as a tedious chore, not as a part of a collaboration between you and the other developer.

Re pair programming, my first dev job was at a place that did mandatory pair programming, and I don't think it was good for me.

It worked when it was two people with similar skills/context, but...

(1/2)

Mar 17 at 1:41amWeb
Show threadragmanMar 17

@GuillaumeL @baldur it fell apart when it was two people with a big power/knowledge differential.

If the more experienced person was really deliberate it could become a learning experience for me as the junior, but that was rare.

When it works, it works, but I do think there's something for banging your head against the code individually too.

(2/2)

Show threadBaldur BjarnasonMar 17
@ragman I think @GuillaumeL covers it pretty well in their answer. It's not a good approach for catching bugs or defects, which seems to be its primary purpose as practised by the industry today. Code review that was primarily for sharing knowledge between team members would require a different approach and style, I think.
Show threadBigSaur GMar 17

@baldur @ragman Real conversation OH recently:

(Dev) - I might have made some mistakes but seniors X and Y approved my PRs

(Lead) - OK but they are supposed to check that your code is clean, not that it works well

Show threadBigSaur GMar 17
@ragman @baldur Yeah I know the feeling. Pair programming can be a hit or miss kind of thing. How does the async code review version of that look, though? Do you think PR review comments can encapsulate the same learning experience? What would the PR comments of these senior devs who were “not deliberate” about teaching look like? How to make sure it’s a two-way street between reviewer and reviewee and not just top down?