Post #1966169

2026-03-17 18:40 UTC

@chandlerc that all makes sense. Random speculation: I wonder if it's worthwhile separating out the "How many eyes look at a work product" from "Layers of review". I don't know anything about design/production in the physical assembly space, but I could easily imagine that it naturally involves multiple people. That might suggest substituting pair programming (+ trust + an emphasis on quality code) for the first layer of review, which might substitute a x2 cost for an x10 cost. Again, pure speculation; I also have very little experience with pair programming. But what I do have suggests that just having a second pair of eyes and brain going through the process in parallel catches a lot of possible failure points.

Replies (1)

@chandlerc@hachyderm.io 2026-03-18 01:24

@curiouserrandy Yeah, I am also thinking along similar lines. The more I think about it recently, code review has ended up in an awkward place: - Try to do optional code review, it just never happens - Eventually, make it mandatory and pre-commit to ensure it happens - Ooops, now it's not just a second set of eyes, it's a layer of review process to make progress Pair programming I think neatly side-steps this doom loop, which in nice. But it has its own challenge due to its synchronous nature: timezones. This makes it incredibly difficult to insist on, especially in environments like open source projects. What I want is an async code review process that _feels_ more like pair programming rather than a layer of review, and so doesn't explode to the 10x cost. But not sure how to achieve that (yet).

Open ##1966170