The Lone Programmer’s Tale

Another Go-Live Day. The phone rings. It’s the client. Production is down. My stomach feels sick.

Kenneth Carey
The Startup
4 min readMay 26, 2020

--

We exchange a few niceties before he gets straight to the point of the call — the production line is down. I’m hanging on his every word as my mind races. He mentions the ERP system integration. Did I think of everything? I tested this!! What’s gone wrong? The call finishes and all I have to offer is a meek “Ok, I’ll look at the code”.

“AHA”

The 'I' in TEAM

Thankfully, that’s not a typical day in the life of a lone programmer. So what’s it like? Great (mostly).

The most satisfying aspect is having complete control over the full life-cycle of a project. From inception to completion, wielding ultimate power over every decision.

All projects start by gathering requirements from the client. That might be a simple phone call or a user requirements specification for more complex projects.

From then on, you’ve control over the architecture, design, and every line of code you’ll write to meet those requirements. Sounds great. What could possibly go wrong?

A lot.

Mistakes You’ll Make

I took a keen interest in Design Patterns early in my career. An interest that consumed me. I was starting a new project and decided to take the plunge with Design Patterns and Dependency Injection.

Pretty soon I was programming to interfaces, adding factory classes, state machines, command objects and wiring dependencies up using XML. I quickly lost sight of the client’s requirements and spent days finessing patterns and knee-deep in XML config.

I didn’t realise at the time but I needed a colleague to reign me in before it was too late! But there was no one. I was the software architect, the programmer, the database admin, the project manager. The ‘I’ in “TEAM”.

You Don’t Know What You Don’t Know

This is true for every programmer. But for the lone programmer, where are the new ideas going to come from? Working on a team you’ll be exposed to new ideas and terms you’re not familiar with far more regularly.

New versions of platforms, languages and toolkits are released almost on a monthly basis. You’re not going to stumble upon these during a conversation in the canteen. There is no canteen. You’re flying blind. You’ve got to spend more time researching because you just don’t know what you don’t know.

Always Researching

Self Doubt

Doubt begins to creep in. Is there a better way of doing this? There’s no team or colleague to talk over your concerns with. No peer reviews.

On the plus side, doubt is a form of self-regulation, on the other, a constant nagging feeling. Would I be a better programmer if I was part of a team?

Taking Hits

Early in my career, I wrote a simple desktop application where one app generated XML files in a directory and my app parsed them and performed some analysis, the detail of which I’ve long since forgotten.

The app was written in VB6. I arrived at the customer site. Full of confidence. I ran the installer and rebooted the machine. You can probably guess what happened next.

The PC wouldn’t boot.

Over Confident Developer

I’d taken my first hit. Panic sets in, but it, thankfully, doesn’t last. Your mind starts racing, as you search in hope for the cause and eventual solution. Solve the problem and you get to punch the air in triumph.

But how will the experience affect you going forward? Will you count your ability to debug the issue as a win and move on? What about next time? The time after that?

Key Traits of a Lone Programmer?

Self-motivation, above all, is the single most important trait of the lone programmer. In the absence of team accountability, the onus is solely on you to stay motivated and continue to deliver your best software day after day.

Another important trait is resilience. Some days are tougher than others. Some clients are more difficult, demanding and obstinant.

The Trade-Off

Lone Programming offers total ownership of decisions and immense pride and satisfaction in delivering complete solutions, from start to finish.

It’s not for everyone. There’s a trade-off — not being part of a successful software team which shares ideas, in which every member has their own unique strengths, weaknesses and knowledge set. Where two heads are better than one.

And then there’s the loneliness.

--

--