The virtues of flying solo
January 27, 2011 - 0 Comments - programming
In the last month, I’ve had ample time for the first time in a long time to really dive into a solo programming project. It was something I had actually been working on for longer than that, but not until this last month have I had the rare chance to work completely uninterrupted on my own. The result is a product launch—that’s right, this thing is shipping, next week! When that happens, I will write a more detailed post about some of the approaches, fairly unique to the Rails world, which I took to a few different problems.
But first, I wanted to write a post reflecting on the merits of working alone as a programmer. There are many articles which talk about the different challenges and advantages of working in teams, but rarely on programming solo. This makes sense, to an extent, as most of us have Actual Paying Jobs™ and work with teams more than we work alone, and there is also all the ongoing buzz about the benefits of pair programming over the last several years. At the same time, though, it’s surprising, since most of the best programmers I’ve met on various teams got their start doing it on their own, as a hobby, as an amateur, a lover of the craft, and only joined companies when they realized they had bills stacking up.
If you’re one of those programmers, think back. Remember that? Remember the first time you got your compiler working? Remember fixing your first bug? Remember the first time you programmed something, not because you were trying to learn a skill or complete a job requirement, but because you were curious to see if it could be done? Let’s take a step back to that time for a moment.
It’s not (that) dangerous!
When you’ve spent years working on teams where practices such as regular code reviews and pair programming are enforced as part of the development process, it can be easy to get the general impression that working on something by yourself, in a vacuum, as they say, is a Bad Idea®. I want to dispel that right now. It’s actually a Really, Really Good Idea®!
Don’t get me wrong. Code reviews and pair programming are great ideas for teams, if they’re done in the right way. The wrong way is to have the attitude that it’s done to prevent incompetent code or designs from getting into the ever-growing repository. Well, okay, that is true to a small extent. But the real reason code reviews and pair programming are a good idea is not because we don’t trust our peers; rather, it’s because working on a team introduces a new challenge which solo programmers don’t face: knowledge sharing. It prevents someone from becoming the only one who knows about parts of the system, which makes them a liability if they get hit by a bus, decide to move on, or otherwise leave the project.
Solo programmers don’t have this problem! This makes irrelevant the bulk of what code reviews and pairing are meant to address. Sure, if something plays out and the solo programmer goes writing code that ends up becoming popular as open source, or ends up building a business and having to hire more programmers, then someone else will need to learn the code. However, at this point, assuming there are good tests in place, it should be fairly simple. Indeed, I’ve found that working on the guts of open source tools which originated from a single programmer is consistently easier than with code written by an organization. Perhaps the code lacks some optimizations that the individual did not know about, but at least there’s a greater likelihood of consistency in things like naming and stylistic conventions, as well as a more cohesive design altogether. (Naturally, this assumes that the individual is a programmer of reasonable talent.)
The point is, individuals can and do build great, reliable software. In fact, free of the risks and pitfalls inherent in working on a team, magical things can happen.
No interruptions, no compromises
Another one of the challenges brought in by working with a team is the constant need to stay in sync. This brings in things like status stand-up meetings, sprint meetings, design/planning meetings, and the like. Throw in code reviews, pair programming, the usual interruptions from support, QA, company meetings, and lunch (because we gotta eat), and one might rarely get the chance to just sit and do some quality, solo programming. While many of these things have their place, I know I’m not alone as a programmer when I say that one of my favorite things about programming is being able to put some tunes on in the earbuds, shut out the world, get into the flow, and slam out some fine, fine functionality. Such is a luxury, and often one nobody can afford, when working on a team, especially larger teams.
But for a team to work, everyone needs to be on the same page. The solo programmer is already on the same page, assuming the lack of conditions such as schizophrenia. The solo programmer doesn’t need planning meetings or design meetings. The solo programmer devises a solution and then makes it happen. The solo programmer doesn’t need complicated development processes checking and double-checking his every move, nor similarly-complicated bug tracking software. The solo programmer has his vision on scraps of paper or a simple to-do list app, and when the solo programmer wants to check his progress, he simply looks at what he’s accomplished.
Maybe the solo programmer doesn’t come up with the most optimal possible solution. But given what I’ve seen and the kinds of egos harbored by the most talented programmers, neither does a planning meeting or analysis by paralysis (reversal intended). Even at its best, a planning meeting certainly doesn’t get any actual work done. At least the solo programmer, proceeding audaciously with no more advice than could be gleaned from a Google search, a reference manual, and past experience, gets things done.
The glorious return of the individual hacker
We as programmers can sometimes forget the power that we wield in today’s age. People of all stripes in the industrialized world are reliant upon the technology which we know how to shape and form and apply at a whim. Most people interact with software every single day, often without even being aware of it. The internet itself is ever expanding its reach into the homes of more and more people, all over the world. For those of us with the knowhow, computing technology is in a unique position to spread innovation and to disrupt industries. And of those among us with the knowhow, a single visionary, working independently and with determination, can accomplish a lot, including much that a team cannot.
There is no reason that any programmer of reasonable talent, anywhere, should feel as though they require the stability of someone else’s vision and guiding hand. If we so choose, we individuals can be the sole visionaries and guiding hands of our own labors. I can cite many cases of this happening, but I should not need to; if you’re working in the tech industry, you are likely mere degrees away from someone who made exactly that choice, and, indeed, probably working for them.
I can’t speak for everyone, but I can say conclusively for myself that the number of times I have felt the fleeting moment of utter joy at what I’d done while working for someone else absolutely pales in comparison the the number of times I’ve experienced that feeling working on my own projects, even those projects which never panned out into anything greater than “for my eyes only”. I can say this with confidence, even while I have had the opportunity to build some pretty wicked shit, if I do say so myself, while working for the man. Programming solo on a project I wanted to do just to do it always feels infinitely better than working on someone else’s project for a paycheck, even if they have a pretty cool project. Why? Because your own project is your own project. You can only fake that level of enthusiasm for so long.
Make it happen
I will end this post with a call to action, one which echos what I heard Hampton Caitlin preach at a Ruby conference, reminiscing about when he built Haml.
That side-project you’ve been mulling over in your head? The one you know you could build? The one you could build so well, so elegantly, you can almost see it unfold in your mind’s eye? The one that you would love to at least start on, but you feel so tired after a long day at work, and those days at work just don’t seem to be getting any shorter, even as the rate of pay remains the same?
Build it. Work late. Spend the energy, even if it takes a toll on you. Just do it. Buy yourself a sixer of your favorite beer, if that’s what gets you motivated, and just code until you can’t anymore. Shut the world out for a while and do what it is you want to do. Be selfish for a little bit. Allow yourself that pleasure, that old, worn, first joy of programming, the one that has been left dusty in your sepia-toned nostalgia in exchange for that regular paycheck.
You’ll be glad that you did. And maybe what you work on blossoms into a thing of its own. Maybe you can quit your job and instead make a living as both visionary and implementor, rather than merely some visionary’s implementor.
Or maybe not. Maybe there wasn’t a market for your idea, or the timing was bad, or it just didn’t gain traction. But you’ll feel better having taken the risk and stuck it out there instead of taking the “easier” mundane route. Who needs security? Fuck security. Security is an illusion, and all the accolades and perks from your bosses can’t give you true freedom. Go get dirty, get bruised, and then get back up and do it again. Throw your creativity to the wind and watch it fly or watch it die, because who cares? Life is short. Make these bets while you can, or die regretting that you didn’t.
