Owners Do it Best


Owners of code care and know the most and will thus do the best job.

Programmers are not fungible

Managers try to load balance programmers across projects like stateless computer systems that can run anywhere just as well.

But that's not the case. Programmers work best in code that they know, with the people they work with, on problems they have deep understanding in. Take a programmer out of that optimal environment -- that took significant time to development the optimization for --- and drop them into another, and the performance will not be equal.

You can't load balance teams without paying a price.

If you let a programmer and a team sit and digest a certain context long enough, they'll do better work within that context. They will deeply appreciate and understand the problem domain. They will know and care about their users. They will keep their codebase clean. They will learn and apply patterns well and efficiently. They will be more adept at their tools. They will protect and prune their codebase. The code and the team is healthiest. Ownership is high.

The programmer's tale

Recently I was asked to be a non-owner contributor to a project. I lived the dream. Here's pretty much how it went down... Act I. Scene I.

Product manager: "We deprecated something, and we need the other team to migrate off it quickly. We need you to go over there and do this, because they don't have time."

Me: "Seems like that team is better equipped to do this. But if we need it be done fast..."

Product manager: "Yeah, go talk to them, and see if you can be helpful."

Me: "Hi other team, seems like you're better equipped, but I can help if I need to. You tell me."

Other team programmer 1: "Yeah, your product manager wants this done fast. Please do it."

Me: "Ok, will do. Will you please join a call and explain what this is all about?"

Other team programmer 1: "No, all I know is already written in this ticket."

I read the ticket. I am not getting enough detail. It mentions a function which I find in the code. It calls out to a service for which I know the owner.

Me: "Server owner, will you help me understand what I need to change for this other team in relation to your service?"

We jump on a call. The service owner is helpful. He has more context about what's going on than anyone has yet volunteered. I learn the edges of the problem I'm actually solving.

I jump back into the other team's code. Ok, I'm learning the usage pattern of this function. I need to get it to move away from what's deprecated, keep some stuff, and add what's new. Ok, I figure out how to merge the two data sources. I work through it. I touch about 30 files and 300 lines of code. I try out the code. Well, I see it working in a least one spot. I send a PR review request with a rquest to please help me test this, because I'm not sure what all's even affected. I feel it's a bit of a cop out, but I am really hoping for help.

My code reviewer is another programmer from that team.

Other team programmer 2: "Thank you for helping us do this! I see you have some questions about your submitted code. That touches code in this codebase that yet another programmer from another team has contributed. Let's get his eyes on this."

Fourth programmer answers the question I had and verifies that some vestigial code could be removed. And he approves the PR.

Two reviews. One approve. I merge. It's 3:30pm. 1.5 hours 'til closing time should be long enough to hear something if it goes awry. I still feel like I'm a bit in the dark. I'm not super plugged-into monitoring on this product. It builds, all is quiet. I'm back to thinking about the problems I had put down to leave and do this. The normal day ends.

In the morning, I prepare for standup by thinking about my report for the task I was sent to help with. I can share that it is complete, and I'm switching back. Simultaneously, I pull up group chat, and I see more mention notifications than usual, including a couple in a long thread. Ruh roh. There had been an outage, and my code was implicated. Yep, I had introduced a bug. It had affected something imporant and potentially expensive. A manager/programmer from yet another team jumped in to try to fix it. Another programmer from yet another team started offering helpful insights. They joined a call, they reported later, and fixed the issue. All was well in prod.

The fix was good. It identified that a piece of code, which was known to them to throw a runtime error in a common, normal-use case, and they caught it. Epic completion.

Good teamwork, ya'll

Ok, a great example of team work, right? Well, yes. I am truly grateful to everyone for helping clean up my mess. And I'm sorry to have had to pull in so many, before, during and after -- especially after hours -- to get this sorted.

Also: This would have been better to avoid.

I'm thinking about another lesson related to something that's been on my mind for a couple years. At the time, I had been reading about theory building, and recently went and read the original Peter Naur Programming as Theory Building 1985 paper. In short, programmers are tied to what they program. Put another way, owners do it best.

Non-owners

Non-owners are not bad people and don't intend to do poor work. They're probably just in the wrong place.

Consultants come tell you about the work you should do in order to do it right, and then they leave you with their bill. You can try to pick their brain while they're present in order to help you prepare as best you can. But in the end, they won't do anything themselves and are under-invested.

Temp workers come and get you out of a jam, in the best case delivering the most essentially-needed requirements, but giving nothing else, least quality. You can spend a lot of time managing them, telling them more exactly what to do and verifying more frequently and asking for rework. But eventually, you'll tire of this and let their contracts expire.

Fly-by contributors give you what they want because they rely on something you have. They hope you'll merge their contribution soon so that they can go back to solving their own problems. You can reason with them in back-and-forths to iterate on their contribution until it more or less does what you think is appropriate to what you own. You weren't expecting this contribution, so you'll probably under-review, but maybe it'll be good, and it gets merged.

Even new teammates are not yet owners. But these are the best kind of non-owners. The good thing is that they aspire to be owners. They'll stick around long enough and are invested enough to become so. And they must be closely trained to be. Just because they are a programmer of significant experience doesn't graduate them immediately to owner status. Their experience hasn't yet been in owning this. If they have applicable experience, the timeline will be more efficient, but ownership remains a process of growing into. They are assumed owners, not cut out from anything on the project, but they still practically need ownership growth over time.

Source of non-owners

Where do non-owners come from?

Managers move programmers around, fire and hire programmers and re-org so much that programmers and the codebases they're assigned to are too fresh or temporary to be owned. This practice may come from a mindset of programmer fungibility. It may be a sign of a lack of focus and flow in product development. It may come from radical reactivity to trends, problems or ideas.

We have distributed our monolith. Or, we have split our code but not our domain. Codebases are separate, so are practices, tools and many specific details of parts of the domain. But then one node's team wants to help another node's team complete some feature in the domain and go over to help. We care about the other node to the point of contributing code to it, but not enough to own it. We want the teams to be autonomous but responsible enough to do what I need, on a timeline, or else we're gonna come over and do it ourselves.

We programmers think we should be good at everything and thus jump into someone's code like we know it all, or at least plenty. We want to be helpful. We want to think no code is above our understanding. Pride.

Non-owners writing code comes from a lack of appreciating ownership.

Worth it?

Will it be worth it to hire, fire, move, reorg, fly-by contribute, getting non-owners into other codebases? Maybe. It might.

Was it in my recent case? Doesn't seem like it. But then, I still don't really understand the "need" for "speed" here. My guess is the ROI isn't good.

"Hurry and do it." "We don't have time." "We'll send you someone to do it for you." Done. Merged. Outage. Cost? Broad view of cost: .5 day of discovery, 5 people to share context, 1 day to implement, .5 day to review, off-hours outage, 4 engineers to detect and fix, .5 day to incident review, 6 engineers to discuss incident, 2.5 days not doing original task, lost revenue and trust in an outage.

If we knew this would have been the outcome, I don't think we would have chosen it. But I think we will chose it again if we don't appreciate the value of ownership and the cost of non-ownership.

What do I need to learn? Learn to be patient. Learn to say no. Learn to explain why waiting would be better. Learn to trust the owners of things. Learn to ask owners for more help. Learn to verify unknown code more. Learn to be a better owner. Learn to figure out how to get those sweet consulting rates in my day job.