Putting yourself out of work

So I was surfing Stack Exchange yesterday, and I came across this post (in a thread about "controversial opinions about programming")...

Interestingly, this post had many replies, and everybody agreed with it.

Of course, I'm sure all good programmers agree with this in principle, but how many of us have actually worked in a role where the work was clean and well-documented enough for a new programmer to come in off the street, and "be up and running within a week tops". In my last gig, the one I burned out with, the ramp-up time was more like a year. Or maybe as little as several months on a team that did the most standard and basic of work. But still, nothing like "a week tops".

What it means to "be up and running" is subjective of course, but the elephant in the room here is obvious: programming should be done in such a way that individual developers don't get stuck being the only ones who can do their job. It should be clean, well-documented, and open enough for any decent developer to be dropped into the role at relatively short notice.

I've never worked in a role which has been even remotely like this. About the best ramp-up time I've ever worked with is around six months. And yes, I have considered the possibility that I'm a 'tard and a slow learner :) - but that wasn't the case. I've watched others start at these companies, and saw the same ramp-up timeframes play out. The projects were just never done to be well maintainable, or "developer-accessible" enough. Documentation was unheard of (or woefully out of date).

I guess the reason this bothers me is that I really don't enjoy this kind of messy, open ended, maintenance-oriented work. I like the idea of clean projects - a well defined beginning, progression, and end. Some people can work on massive reams of bad, unmaintainable code, and just sit in the same role forever, constantly re-shaping the big ball of mud, relishing the job security. That's just not me. Or more accurately - that's not me in spirit, but it's a rut I often fell into in roles and environments that encouraged this approach to programming (intentionally or unintentionally).

I think Mike Hofer is quite right. And I believe there is a strong corollary at play here: companies/projects with a very long ramp up time are a bad sign. If a software project is done well, any developer should be able to come in, read the doccos, and be up and running within weeks - and probably plateau out (more or less) in basic everyday productivity within a month or two. Of course, there will always be certain details which more senior people know better than a newbie - but it shouldn't be this hidden "dark art" type of scenario where it takes years to become fully proficient and productive - because the system is full of little tricks and hacks that aren't documented anywhere, and can't be learned easily.

Of course, making yourself easily replaceable might not be very good for job security. On the other hand, this kind of "artificial job security" can easily lead to burnout - at least if one is focused on closure - rather than ongoing work and job security for its own sake.