The Libertarian Coder
I'm an independent worker. Solitary by nature. Always have been. In school, I abhorred team projects; there was nothing worse than when the teacher would say, "Now, let's form into small groups for discussion." In pre-calculus, I tuned out my teacher completely and just did my homework in class—the textbook was all I needed when I had questions. When one of my classmates remarked, “But that’s not the way Adam does it,” the teacher replied, “Adam is in his own class.” I took it as a compliment, though none was likely intended (my way got the right answer just as efficiently as theirs).
Later, in college, while everyone else formed study groups, I was content with my computer, a desk and good reading light.
So, starting in the late 90s as a junior in high school, working as a coder was a good gig for me. Programmers at the time were managed by delegation; they were given longer running projects and bigger responsibilities. People were surprised at how little direction I needed. They could point me in a direction, and I’d figure out the details. I might poke my head out of my office occasionally to ask a question or two, but I was mostly heads-down. I worked hard, and I did good work. I usually finished sooner than expected with a solution that was well thought out.1
This kind of independent working style was my sweet spot. Time only deepened my commitment—so much that I could easily see why Donald Knuth wouldn’t even want to fuss with email. In his words:
Email is a wonderful thing for people whose role in life is to be on top of things. But not for me; my role is to be on the bottom of things. What I do takes long hours of studying and uninterruptible concentration.2
I wanted to be at the bottom of things too. I yearned for this type of deep mastery. But it required an equally deep level of autonomy. I needed to do things my way, so I could understand them thoroughly. That’s how my brain worked. Just like in pre-calculus.
Before long, I found the true archetype for my working philosophy in Howard Roark, the fictional architect from Ayn Rand’s The Fountainhead.
I would’ve told you that an honest program, “like an honest man, had to be of one piece and one faith; what constituted the life source, the idea in any existing thing or creature, and why — if one smallest part committed treason to that idea — the thing or the creature was dead; and why the good, the high and the noble on earth was only that which kept its integrity.”3
And that “I can find the joy only if I do my work in the best way possible to me. But the best is a matter of standards — and I set my own standards. I inherit nothing. I stand at the end of no tradition. I may, perhaps, stand at the beginning of one.”4
“The only good which men can do to one another and the only statement of their proper relationship is — Hands off!”5
Call me the coding libertarian.
For me, code ownership was analogous to property rights. Sure, I knew companies had legal rights to their IP, but inside a corporation, people still needed a form of ownership. If everyone owns everything, then no one owns anything, and nothing gets the care it deserves. Just look at how people treat public restrooms compared to their own. The same principle applies to code.
The open source ethos, with its benevolent dictators, was the cherry on top; it was settled. Building software was a matter of assigning broad responsibilities and letting programmers enforce their personal domains.
But midway through the first decade of the 2000s, a whole new collaboration style came into vogue. To my libertarian sensibilities, it felt completely wrong. Everyone owned all the code. The work was split into tasks with everyone just grabbing work from the same bucket—no individual projects. Everyone was talking all the time. Consequently, it was around this time that all the cubicle walls came down and we started working together in “the bullpen”. Donald Knuth and Howard Roark would not approve! I wasn’t buying it either.
Over the next twenty years, this mentality only became more entrenched. It made writing software a less ideal profession for me. I watched myself slowly slip from star to average performer and sometimes poor team player.
It's been deeply depressing, mostly because I love to program and I know I have an aptitude for it. I was disoriented for a long time. I didn’t really understand what was going wrong. I read management books and software blogs. I wrote out my thoughts—all to make sense of things, wondering why I suddenly felt like an alien on a strange planet.
Several times, I even resolved to change professions, but I couldn’t make anything stick. I always fell back to the easy road, taking one of the many available programming jobs (the easy road ended, however, as soon as the job started and I had to start “collaborating” again).
But reading was always my coping mechanism. When it sucked at work, I grabbed another management book. What are other people doing out there? Are other professions just as crazy? I found a lot of solace in the words of Deming and Drucker. Stephen Covey was my hero. I found a whole movement of people investigating ways to self-manage. Someone in Brazil named Ricardo Semler, someone else from Belgium named Frederic Laloux. And so many more.
I even read more about the movement I despised. I learned to separate the Agile Manifesto from the many “Agile” implementations. The Agile Manifesto made sense. I hated the up-front planning people did in the 90s and saw wisdom in abandoning it. I always wanted closer customer collaboration. I even believed project owners should find ways to demonstrate intermediate results to get constructive feedback earlier in the process. In my view, you could still be Agile with strong code ownership. I couldn’t see why a whole new collaboration style came bundled with such a reasonable manifesto.
For a long time, I begged for the old way. “Just let me have my own project.” “I’ll show you what I can do.” “I promise, I’ll do a great job.” But I never got more than disapproving rebukes and platitudes about more heads being better than one. This new movement was taking a moral position rather than a practical one. I was ‘immoral’ if I didn’t agree. It’s really hard to persuade someone that’s taking a moral stand. I guess they don’t want to become ‘immoral’ too.
So, I read more about shared code ownership. I dug deeper into the philosophy of the new cult of collaboration. I read what Kent Beck and Martin Fowler were saying. Finally, I saw what I hadn’t before. I stumbled into something that has made it possible to survive as a programmer/individualist in a world of code collectivists. I realized that, just as there are people like Donald Knuth and myself—independent workers that want big projects and to be left alone—there are people that prefer to collaborate—and not just occasionally, but all the time. Where I see distraction, they see synergy. Where I see a lack of ownership, they see power in numbers. I could see that there were two valid, yet seemingly paradoxical, ways of looking at the problem—two styles of collaboration.
Whether you liked one way or the other all depended on your personality. I started seeing this new style as different rather than wrong. Even if it wasn’t a good style for me, maybe it was right for someone else. This made me less resentful. My Grinch heart started beating just a little bit harder.
Unfortunately, there where more of the shared code ownership types than my own, at least among corporate decision makers, so I was eventually forced to consign myself to the new way. My golden years weren’t coming back. But that didn’t mean I was giving up. That was not in my nature.
Digging deeper into the tenets of the cult of collaboration, I realized that when I first started doing XP back in 2007, my company had omitted a lot of its most important practices. In essence, they left out all the collaboration. We didn’t do any pair programming and we barely talked to each other. We each worked separately on separate tickets. I later realized we were missing the whole point. Kent Beck and Martin Fowler would not approve!
What most companies didn’t seem to understand (most still don’t) is that shared code ownership only works if you’re “all in”. Because the codebase you share is so much larger, you have to be in constant communication, asking if anyone knows about various parts of the code. Domain knowledge is spread across the whole team. You have to pair program, integrate code quickly, and get constant feedback. My most important epiphany was this: doing shared code ownership halfway is far worse than doing either shared ownership or individual ownership correctly. As Mr. Miyagi says, “walk middle, sooner or later, get the squish, just like grape.”6
So, even though everyone seems to think they switched to a shared stewardship collaboration model a long time ago, they really only got part of the way there, and a lot of my trouble was actually coming from these partial implementations, which omitted all the important supporting activities that optimize the work for shared ownership. These very activities where the ones that made shared work manageable, even for libertarian coders like myself. Of course, Kent Beck, Martin Fowler, and others figured this out ages ago, but no one seemed to take them seriously. Companies picked and chose the parts of XP they liked, or abandoned it all together for Scrum, leaving us with a bunch of Frankenstein process monsters.
These insights changed my strategy. Instead of advocating for individual ownership and minimal coordination, now I push for more collaboration—the missing ingredient for staying sane in the collective code ownership commune. You can find me in my homemade bell-bottoms, singing by the fire. I am even letting people use my toothbrush now if they want.
Before, I was a lone wolf drowning in a sea of legacy code, never mastering anything. It was just too much for my brain. No matter what I tried, I was always lost and slow. But now I see that shared code ownership was never meant to function that way. When everyone owns the code, everyone must help everyone else, all the time. Constant Collaboration.
Once I started pushing for pair and mob programming, my experience improved instantly. Even though it still wasn’t the autonomy and mastery that I craved (I’ve learned to get those from open source software, writing, and occasional skunk works—ssshhh, don’t tell), it was finally tolerable. With people there to answer my questions, I can keep moving forward—which does wonders for my anxiety. Pair programming is actually pretty fun sometimes and comes with its own unique benefits.
The only problem I run into now is when my coworkers are reluctant to pair program. While I can’t judge them—after all, that was me for twenty years—I’ve developed a useful skill to mitigate the problem: unapologetic, unrelenting questions.
It is the hardest thing in the world for me sometimes. My heart of hearts still just wants to crank on things by myself, and I want to let others do the same. But that is a road to disaster. I’ve learned that if the team wants to share all the code and make consensus decisions, they also have to be available to share knowledge. That’s part of the deal—the only way it works.
If I am feeling particularly sheepish, I remind myself: this is the utopia they wanted, and I’m just helping them live it out.
If you remember anything from these ramblings, remember this: if you’re stuck, it is not your fault. It is your team’s fault (or your manager’s fault if they are the one forcing you to work this way). Being stuck means people are not collaborating enough. It doesn’t mean you’re deficient. No one expects you to have mastered all the code. That’s not even practical in a shared ownership model. Don’t spend any more days stuck in the mud, wondering how you’re going to explain why you still haven’t finished your Jira ticket. Do pair programming—and if that’s not an option, ask lots of questions.
And if you keep asking questions, sooner or later, maybe your manager, or your team, will realize that something’s wrong. Then you can tell them all about Kent Beck and Martin Fowler and all the stuff they shouldn’t have ignored in XP programming.
While I’m still, at heart, an individual code ownership person, this is how I manage until that type of collaboration makes a comeback. Maybe one day there will be room for all of us: the libertarian coders as well as the shared ownership coders. But, until then, I’ll be over here, asking lots of questions.
I also made a habit of pulling in my manager as I made small amounts of progress, to get their opinion. So, I wasn’t just working in total isolation. When I say my solution was “well thought out”, it included the thoughts of others as well.
Rand, Ayn, The Fountainhead
Rand, Ayn, The Fountainhead
Rand, Ayn, The Fountainhead