How to Thrive as an Average Programmer
A survival guide for us non-prodigies
It’s something that’s hard to admit and not exactly something you’d find on my official resume: I’m an average programmer. I understand (most) code, but I don’t dream in .Net core. Rubies and gems are things I have no money for because I don’t write enough Ruby. I haven’t built my own framework, and when I switch between programming languages, I reach for the cheat sheet if I need it.
This isn’t to say that I don’t like coding. In fact, I love it as much as it makes me want to switch jobs in the span of minutes. I hate agile methodology with a passion because it’s always spouted by people who think that it’s somehow a completely new concept we all need excessive training for. I could rant for hours about the things gone wrong in my small corner of the tech world — let alone the world at scale.
And yet I go to bed happy to have a job that I love, that keeps me just sane and insane enough to get me through the day without dripping hot wax on my fingers just to feel anything. It’s a comparatively good life, and I hope to show in this article how and why I learned to enjoy it and get pretty good at what I do.
Start by Not Hating What You Do
To like or even love what you do isn’t something you can just do with the flick of a mental switch, but you can stop hating it. I came into coding more by accident. I was good with computers, so I sent out some applications and somehow scored an apprenticeship despite not having the slightest clue about coding. I did my apprenticeship together with a mass of people who had chosen this job and worked hard to get the skills that made them interesting to employers. They were and still are lightyears ahead of my skills when it comes to bare coding.
There are other areas of a programmer’s life. We’ll get to that in a moment, but for now, let me summarize by saying that there’s some tiny area of your job that is cute, quirky, enjoyable.
I had the luxury of pretty extensive database access even during my apprenticeship, and since I was often left alone to roam, I started digging into statistics. How many customers do we have who have this, that, or this again? How many emails does the average customer write? What are the most common reasons for contacting us?
In the end, I became a bit of a database detective, quick to dig into whenever someone needed statistics or run mass updates to save our customer support guys hours of time. This was never part of my official job description, but then no one ever complains when you use available time to help someone.
Unlike my normal work, I did not hate this. In fact, it was quite fun and, on occasion, I would find a chocolate bar on my table as thanks for the help. By the way, that’s an easy way to get your code monkey to like you — even though I don’t like chocolate and only give it away to coworkers in need.
“Git Gud” at What You Do
I have always lived by a general rule that mastery in one area isn’t as desirable as getting decent at several things — and in programming, that is even truer.
There are various ways to do your job well, either through hard work or just through experience and being fast at fixing bugs others would take much longer with. If you manage to keep your head above water for a while, you’ll start seeing light on the horizon, start to understand how the system works, and you’ll find your own little workarounds for problems that may put sweat on other people’s heads while they imagine all the things that could go wrong.
Part of my work contains such atrocities as “production database tests,” where I bypass, trick, reverse, and edit against the live database to fix critical errors that I can’t test since the test database is only cloned once a week and never when you need it. “Pray and commit,” as I like to say. What’s the worst that could happen?
It may lead the purists at work to a minor identity crisis, especially considering there is no way to unit-test this stuff and I committed straight into the master branch since I’m the only one working on this system anyway and have no one to approve my pull requests. It took me some time to bypass those stupid rules to permit check-ins to the master branch, and I’m proud of that. Desperate times call for desperate measures.
All of this is to say that there are many shades of “gud” in the world of programming. Even if that only means being there when things break in spectacular fashion and being the kind of guy who owns up to his mistakes and mops the floor after.
I’m deep into the “chaotic good” corner, but just as I have found my niche there, you can find yours in the opposite where you have your whole system in order, where the tasks are so damn well-formatted that even someone without coding skills can take over your work when needed, and where they all have just the right amount of story points assigned to them. Expertly crafted user stories, elegant displays of law and order in a world where there is none — that’s the stuff that makes your team leader see your face in his dreams.
Do Something Fun With Your Skills (and Learn New Ones)
Programming is a line of work that enables you as much as it challenges you. These days, almost anything can be built with open-source tools and languages. There’s a tutorial for pretty much everything you might encounter on a hobby scale.
So use your skills and go from there. Build something stupid like a random quote generator or something practical like a website that solves problems for people and makes you rich from the subscription fees. Or just work on any kind of project that seems fun. I spent an ungodly amount of time building a sex story generator in PHP once because I like pain and also I wanted to understand PHP after hating it too much for too long. Now that I think about it, that project might warrant an article of its own. It was quirky enough.
The point here is that most of the time, you only have to spend time — not money — and there are plenty of tutorials out there to get you going.
Realize That Programming Is More Than Writing Code
It took me a while to realize and also some time for people to start trusting me with the responsibilities, but little by little, I transformed my whole job into something entirely different from where it started. I write comparatively little code these days — just enough to keep calling myself a programmer, really.
Instead, I ended up being the single maintainer for a decently complex, decently crucial system at my company with all there is to it. I organize my work, communicate with my team and colleagues in general, attend meetings to lend my expertise and input, and run everything front to back as best as I can.
While admittedly stressful, I enjoy this style of work a lot. No day is ever the same, and since I’m on the receiving end of all the annoying stuff — from tiny bugs causing big drama to the meetings I would rather skip — I’m always happily supplied with office drama to keep myself occupied.
I also get to enjoy the late nights at the office with other workaholics, those amazing times of relaxed-yet-focused work when people from various departments assemble in one room and work hand in hand because the deadline is so rapidly approaching. I love being in a room where everyone pulls their weight — and being accepted, welcomed there. Finding a missing space in a concatenated SQL query after two hours feels a lot less horrible when the people next to you have to fight their own demons.
Understand Your Company’s Architecture and Ecosystem
The other week, we had a critical system breakdown — one that I don’t maintain, but the maintainer, his vacation replacement, and the other guy who might have known something were away ill or out of the country.
I had a general idea of how the program worked, got on the case, and was eventually joined by two other people who were as clueless as I was. But in the end, we managed to narrow the error to a server fault, and together with the third-party company that sold us the system, we eventually managed to get everything working again early Saturday morning.
Sure, it was a wasted day for half the company, but that could have been two or three days. That was easily our respective year’s wage in savings there because we had a general understanding of how the systems work together to pinpoint the error and dig through log files.
It was honestly one of the wildest times in recent memory — and one of the most fun ones. I even got a “good job” email from the department boss and he briefly knew who I was when I ran into him on the floor. Luckily, that never lasts and I can return to the anonymity of the void. Thank god.
I went through a time at my company where I came within inches of being fired — it’s easy to understand how and why if you read this far — for exactly the same work I am commended for these days. That’s a whole other story for another day, but let me summarize it by saying that communication made all the difference in how my work was perceived.
Do all the useless baggage stuff like writing thank-you emails whenever someone notifies you of an error, respond when it’s fixed, and no matter if they care or not, write a quick one-minute explanation of why the error happened in the first place and how you fixed it. Not only did I learn that a surprising amount of people like when you tell them this stuff, but it also runs its course and comes back to you eventually. Respond, answer, anticipate, prepare, spend an hour a day just talking to people.
Over the course of this thing, I picked up a motto I live by these days: Explain things to idiots and watch them become people.
I hope you enjoyed this post or even found it useful. It sure saved my ass from getting fired or quitting and buying a cabin in the woods to get away from all tech. Those thoughts are reserved for Wednesday afternoons now.
Thanks for reading!