Finding Collective Ownership of the Codebase

Code is not mine, it’s ours. Through that our code is mine.

There's something incredibly harmful about an individual owning a piece of code. When I say owning a piece of code I mean they feel like they have a right, above and beyond the rights of other individuals on their team, to make the call that this code isn’t good enough to be a part of the code base. It’s not up to their standards, rather than the team’s standards. This harm can take many shapes, but the manifestation you should care most about as an engineering leader is the team being unequipped to manage this code. Where due to fear of interaction with the owner, development on the owned part of the codebase is slowed.

When an individual owns the code others on their team feel unwelcome in the codebase. Like they don’t belong. The rest of the team hesitates to touch it, whether that means modifying, updating, or extending it. They’ll only debug it when it’s absolutely critical, and the owner is out. Otherwise, they’ll just wait for them to come back to debug it too. Because it's difficult for the team to understand, or they fear the owner will block them. Block them by rejecting their pull request without real reason. Or worse, they may be forced to endure an endless cycle of reviews where the owner pushes them into rewriting it to the point that they may as well have written it themselves.

Put yourself in the shoes of the folks on the team. Would you really want to write some tests, code, and wait for CI just to toss a coin to see if Jordan’s going to nitpick it over the course of 3-4 cycles, or just request changes and disappear, until you throw up your hands and decide that this code wasn’t worth it anyway?

Avoiding multiple cycles of less than productive reviews highlights why linters, formatters, and other automated rules and static analysis tools are important. They push you to make it so code doesn't look so individualized. It's harder to tell "whose code this is" outside of git blame. They also automate the enforcement of these otherwise trivial seeming rules that would cause friction during the review process.

A consistent style makes it easier to jump in and contribute because everything looks more like the team's style. Ideally, these boundaries are pushed out further to community standards. It's easier to onboard individuals from the general language community and onboard them faster because your code looks like their code. Because of this "your code" is "their code".

This also highlights the value of establishing common organizational patterns and idioms. If your team knows that the way that you handle rate limiting APIs via a retry and circuit breaker pattern, and that you have that encapsulated in your `CloudRetry` class, then the team knows that any classes for API interactions need to leverage this class.

Teams with shared understanding and patterns have the foundation for higher velocity. What norms has your team established around shipping? What’s the process for creating new norms and updating old ones? What about pushing their adoption in the rest of the organization?

Team ownership doesn’t mean that no one owns the code. In fact just the opposite. A single team needs to be responsible for a given piece of a domain, especially if it’s broken out into its own service. Teams need to be responsible for the code they write, from ideation to end of life. This ensures the need for quality is baked in. You can’t throw the code over the wall to the ops/maintenance team, because spoiler alert, that’s you. If only specific individuals own it you have increased risk of only being able to modify it with great difficulty, if at all. Team ownership spreads around knowledge, context, and ability to change the code.

All of this means you need to be writing code for the team. This also ensures you're in the right frame of mind when reviewing code. If the code only makes sense to you, it’s not good enough. How can you make sure other engineers will be able to understand it on their first read through? If it’s not there yet, give it another pass.

When the code doesn't look like anyone as an individual wrote it, it looks like the team wrote it. Individuals are less likely to become the sole gatekeeper, or nitpick things that don't matter.

That said, all of the above won’t necessarily stop someone from just being an ass about the codebase. That’s where it’s the job of the team and the engineering manager to push back on the individual about their concerns voiced in the review, or worse, in the commit that immediately follows in the owner’s style, if their changes are unreasonable. Not just because there is a potential deadline looming, or “we want to ship this fast”. Especially not if that deadline is just the end of the sprint. (There’s a special place in hell for folks who try to force changes through at the end of a sprint “to keep velocity up”.) Ignoring valid concerns about the long term maintainability of the codebase is a recipe for disaster though. Listen to the folks on the team, and figure out which is which.

Software engineering is a social activity, not an individual activity. Enabling that social element is key.

Find flow in your team by losing yourself.