CIRCLE WITH A DOT

@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?

@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

@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.