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/
-
@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.
-
I don’t think this is true. It comes from software engineering studies done in the eighties, particularly at IBM. Admittedly few places do rigorous reviews the way IBM documented.
@lain_7 So, me and @GuillaumeL are specifically talking about the pull request style of code review, the one that was popularised by GitHub and is quite popular these days in tech and software dev, especially web.
Quite a few modern software dev practices have diverged considerably from the original methods while still keeping the names. TDD doesn't look like original TDD. Code review doesn't look like original code review. Agile isn't agile. Etc.
-
@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)
@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?
-
R relay@relay.infosec.exchange shared this topic
