.svg)
.png)
Part I
In my previous post about guest contribution, I highlighted 3 practices to be a good "steward" of a codebase. (In hindsight, I wonder why I named the article "Guest contribution", then wrote about stewardship. Perhaps Imeant to make a point about how those should be synonymous, but a little explanation would have been helpful!)
The 3 practices were:
1. Assimilation, to write your code with the same style and design sensibilities as the code that surrounds it.
2. Communication, to be transparent with your team about the code you intend to write and why.
3. Compassion, to have a frame-of-mind that forgives previous contributors for any errors they may have made with the understanding that you may make errors as well.
4. Bonus: Ownership:
I provided a bonus tip advising that everyone should consider themselves a guest contributor as opposed to an "owner," framing "ownership" as something that people claim in order to unjustly lord their authority over others. My intent was to impart a mindset of "stewardship" rather than "power", which comes from a deeply held belief of mine that those who wish to be first should make themselves come last.
Part II: Ownership
Today, I'd like to add nuance to my feelings about the "ownership" of a codebase.
Ownership is actually a good thing. But it’s not pleasant.
Suffering
It would be naive for someone to seek ownership of something just for the honor and glory that comes with it. It would be tyrannical to desire ownership for control. It would be foolish to think that ownership grants pleasure.
No; with ownership comes suffering. As a matter of fact, it is almost always preceded by suffering.
One is usually seen as the owner of something when they have established a pattern of being there to fix it when it breaks; to take responsibility for what it does, and to insist on being held accountable.
I can think of a number of projects I published and have abandoned after mere months (or shorter). Ownership of a thing requires bondage to it, which I've historically found difficult to willfully submit myself to and imagine others would probably agree. (By the way, I don’t want to sound overly masochistic. I don’t want to imply that having published a project automatically means that you are obliged to maintain it for the rest of your life. The decision to put yourself in bondage should be grounded in a value judgement: “is it worth the effort?”)
When someone sees themselves as an owner of something without having first suffered for it and served it, people (hopefully) see right through them.
Now more than ever
At their current throughput, many engineers already find it difficult to push a feature from development to testing to production and be held accountable for it, not only immediately after deployment but for the years that follow.
In the age of AI, true ownership is more valuable than ever. Engineers can potentially write more code than they could before; but are they able & willing to be held accountable for it? Can engineers find ways to use AI to facilitate accountability in the same way that they've found ways to use it to facilitate authorship? An engineer's mindset has a lot to do with that.
Stewardship and ownership
The best owner of a codebase steps up not because she wants to but because she knows that she must. She takes blame and shuns credit. She prioritizes reviewing others' code and helping them get to production. She seeks permission from others to go to the main branch. She supports testing more than development. She is a servant.
