My time is your time

[Another post in the ongoing series on being the sole developer in a "normal" (that is, non-software) business.]

Perhaps one of the most unexpected aspects of going to work as a lone programmer somewhere, the thing I didn't see coming and should have, is how you become the tech resource for everything and everyone:

• Helping the IT staff troubleshoot issues.
• Helping the help desk troubleshoot users (because it's too much trouble to shoot users).
• Giving answers on the feasibility on every possible project (there is at least one VP who starts every single conversation with me with, "Would it be possible..." - I've started smiling and saying "No" before he even opens his mouth).
• Listening to pitches from vendors who have corralled your boss's ear.
• Writing requirements for statements of work so you have a chance to farm out some of the work load to those vendors.
• Reviewing the resulting statements of work so you can complain about how much consultants charge now days, and how much time they expect to take on a project you know is only a two or three day effort.
• Coordinating, training, monitoring, hand-holding, testing and correcting those consultants.
• Being invited to every meeting that touches technology in any tangential way.

All of that is in addition to "your real job." Can you say "rampant context switching?"

"Flow mode? What's that?"

In some sense I imagine it is similar to being general counsel at a company large enough to afford one, but only large enough to afford one. Since everything has a legal aspect to it, they are probably dragged intoeverything. And since everything seems to have a technical aspect to it, I am dragged into everything. There is seemingly no limit to the number of people who can request, demand or interrupt my time. Or actually, there is a limit:

i = e + v - 1

...where i is the total number of potential interrupters,  e is the total full-time employee count, v is the number of vendors being used or considered for use by the company within the next five years, and the "1" is me.


There are a few self-defense mechanisms I've picked up:

• Sometimes, you just have to be a jerk - Since non-dev companies don't understand the impact of interruptions on productivity nor what a closed door means, sometimes the only recourse is to be a dick. See my automatic "No" response, above (you thought I was joking). Past coworkers will remember the hard time I would give tech support staff if I didn't feel they had done enough research first ("You didn't do the dance.") It doesn't help, it doesn't stop the interruptions, but it does take out some of my aggression. Man, do I feel dirty.
• JIT knowledge and action - Given the fact I have no control over my day, priorities, interruptions and escalations, often even when I am given advanced notice or information, I simply file it away or ask for it again when it applies. It's not that I'm forgetful, it's more to keep any semblance of forward motion (and inbox zero) on my current work it is easier to request information again when it becomes required, rather than trying to remember it over the days, weeks and months between when it is given and when it is actually useful.
• Make 'em ask for it twice - I've used this as a "manage your manager" technique for years, because most CTOs and CIOs are excellent idea generators, and don't know when to stop. They spew possible projects out at a rate that would keep a large offshore development staff happy for a decade. And 90+% of them will never see the light of day, nor do they expect them to (that realization actually came as a shock when I first figured it out). I used to jump at every random suggestion, question and research idea that came from my bosses. Now, especially if I can tell it's a "blue sky" type of suggestion, I just sit on it. If they come back months later (it's always months later) and ask, "Where are you at on that Flux Capacitor Inventory Module?," I then say, "I should have that done by next week." Which satisfies them and I then know it's a real project and pound it out.

I'm not proud of any of the above. I don't think they're the "right" way to be doing things. But they do help me keep my sanity. Because otherwise I would literally work myself to death trying to keep up with everything.


Now, some may think all of this is a complaint. It's not, really. There are many parts of my job I like. I am lucky to have it. However, it is a reality check, both for me and for others. For me, it is a reminder that the good parts of being a "lone wolf" programmer come with a cost. For others, it is simply notice that if you are thinking of hiring on to be the only developer somewhere, you should know, up front, that the vast majority of your time will not be spent in active development, especially after you've been there a year or longer.


Actually, this should be no surprise to anyone who has been a programmer for more than a few years. Over my entire career, across multiple large and small companies,  many of which were software vendors and hence in the business of turning programs into products, I'd say my overall "load average" of time spent actively developing is somewhere between 30-40%. It certainly isn't more than 50%, and often it's been more like 25%. And at my current job I'd say it's more like 10-20%.


Ultimately, my point is that any shop that is big enough to hire one programmer, but only one programmer, is going to spend most of that programmer's time on non-programming work (cf. "support debt"), because there simply isn't the infrastructure, discipline or organizational understanding to do otherwise, and because the skills that make a good programmer are also skills that come in useful for a variety of other purposes. So now you're warned. If I had known all this when I was offered my current position I probably still would have taken it, but I think my expectations would have been different.