Great developers own their code
Written by Calum Bird on March 3rd, 2026
When you make a PR and request a review, you are stamping your code clearly, irrevocably, and without doubt that "this is mine, I know how it works, I know why it works the way it does, and I made it as elegant and simple as I know how". Sometimes there's a better approach, and that's why we still review. But the bar for requesting a review should be high.
Requesting a review is a signal to your team-member that you have done as much as you can, that you have weighed the value of their time and decided that reviewing this code is a better use of their time than anything else they could be doing.
Respect for that team member means ensuring that you know that fucking code - you understand the trade-offs made, why it was organized the way it was, and where to locate every important piece of logic relevant to your change. If you don't know those things, you can't truly say that it's yours, nor that you know how it works, why it works, nor that it is as elegant as you know it could be.
Many of the best contributions remove more code than they add. They find a clever way to abstract complexity away, reduce surface area, and find elegance in an unlimited sea of tokens.
Code is cheap now. Thoughtfulness about why your particular code is necessary, on the other hand, is not.
Be damn sure you own the code you ship. It's one of the only durable things we as writers of code have left.