I don’t usually call out articles on Hacker News for being exceptionally silly – if I did I wouldn’t have the time to write about anything else – but I saw one in particular tonight that bugged me, titled Your Job Is Not To Code. It was filled with the sort of engineering platitudes that one can reliably expect from HN: you must be an engineering ambassador to your company from the strange and incomprehensible Codingverse. It’s up to you to interpret and reinterpret the requirements of your project, hopefully better than its stakeholders, and tell them what they’re doing wrong. Your technical skills must be married to the sort of interpersonal skills that would make ambassadors and diplomats blush.
This is all bunk.
If you’re an engineer, then your job is to code. Your job is to be good at it. No, more than that: your job is to be great at it. Anything less is a disservice to the people who’ve hired you and a disservice to yourself. You should work constantly to succeed at your job. Working towards anything else is a distraction.
I find the point of view that creating code is the least of our concerns particularly troubling, since the skill our profession provides is so unique and valuable. Usually you don’t see agile coaches, salespeople, or business development professionals jumping in and coding. And when they do, they’re not great at it. Why should they be? Their talents are of a different sort. So why do we constantly receive exhortations to do their jobs? Does having the ability to code make us great at marketing? Or leading a team? Or being a chef?
I’ll tell you what coding does make us great at: creating computer programs. I mean this unironically. Our applied skills produce amazing products, save hundred of hours of human labor, and make people laugh or cry. The knowledge that enables this is, for most of us, hard won. Retaining our engineering position is a lifelong process of learning, changing, and growing. It’s the Red Queen’s Race to keep up with our peers and our changing world. The fastest we can run will result in us merely standing still… and if you don’t run as fast as you can, you’ll be left behind.
Of course we must communicate what we’re doing to our bosses, our clients, and our process managers. But this doesn’t make you a boss, a client, or a process manager. If they don’t understand what you’re doing, despite your communication, then that doesn’t make you bad at your job. It makes them bad at theirs. This is a hard spot to be in, and while the solution might be to try to do their job for them, that doesn’t change what your job is. (To reiterate: your job is to code.) If you’ve taken their responsibilities on top of yours, that doesn’t make you great. It means something has gone very wrong indeed.
Coding is a form of communication. As you become better at coding, hopefully your communication skills will follow – and this allows you to better interact with others. And while there’s nothing wrong with using new skills, don’t become distracted by them. You have a talent, a knowledge, a skill that others in your organization lack. Your job is to employ that skill as efficaciously, as completely as possible. And that should be taking up 99% of your time in any given day.
Leave the strategy to the generals and the garbage collecting to the janitors. Do what you do best, do what you love. That way lies success, self-actualization, and happiness. Become distracted and soon you will be a general or a janitor: there’s nothing wrong with that, but their jobs aren’t coding. And if you were hired to code, if you want to code, then your job is to code. It’s as simple as that.
