I agree with the general point of the article, though the main compare/contrast of different code review scenarios seems to speak more about deadlines for code reviews than code ownership. Where I work we just expect multi-day turnaround times on most PRs so that the reviewer can schedule it however they see fit, and that does more to relieve code review stress than anything else.
Assigning PRs to code "owners" just seems like common sense to me, and is built in to github now.
Great article! I really like the notion of code ownership over checklists.
However I wonder how this would be implemented in reality. Write permissions in git are managed by having different repositories. Splitting up your code base into several repositories has serious drawbacks in terms of maintainability and deployment.
There is definitely something to code ownership and I‘m looking forward to follow up articles.
It's fine for the write permissions to only be enforced by convention or automated CI checks (eg, status checks on github PRs). No need to split up the monorepo or anything.
The problem with code ownership is siloing. Because you are the only one who understands the problem domain or “the code” this create dependencies which doesn’t scale. I’d say code ownership is a smell and an indication that your code isn’t clear enough. Code needs to change all the time and sometimes completely.
Assigning PRs to code "owners" just seems like common sense to me, and is built in to github now.