Your Job is Not to Write Code

I know. You think you were hired to write code. In fact, your entire interview process centered around how well you could write code. And I’m sure you do it really well.

But it’s not your job.

Your job is to improve our product for our users. If you want to get technical about it, your job is to improve our product for our users in a way that improves the key metrics of the company. But honestly, you don’t always have a lot of control over that second bit. You do, however, have an enormous amount of control over the first bit!

First off, let me note that I wholeheartedly disagree with 95% of this article. An engineer’s/programmer’s job is absolutely to write code. That is what they excel at, and that is why they were hired in the first place. There is a reason why a programmer’s technical skills are assessed when he or she applies for a job. That reason should be self-evident. It’s, you know, their job.

Note that I’m not saying you should disregard your users. Knowing who you are developing software for is absolutely a good thing. Every programmer should think of the customer and/or user. But then again, so should every single person in an software-intensive company. Instead of saying an engineer’s job is to improve a product for users, one should say that an engineer’s job is to write code for the purpose of improving the user experience. There’s a clear distinction to be made here. No code is ever written without a reason.

For one thing, you need to make sure that the code you write (writing code is still one of the main things you will do when doing your job, by the way) runs the way it should, even on users’ machines.

Did you know that our users probably don’t have brand new MacBook Airs with giant Thunderbolt monitors set at the highest resolution possible and running the latest version of Chrome? I checked.

This comes off and incredibly condescending and I suspect, for most engineers, it would be perceived as insulting their intelligence. Trust me, we are painfully aware of legacy systems and device fragmentation. We also know that software should run as we expect it to. That goes without saying.

In fact, you’re going to need to make sure that the code you wrote runs in production, in general. I don’t really care if your code runs locally. If your code just runs locally, then my only option is to sell your computer so that our users can use our software, and that really doesn’t scale.

This, again, is insulting peoples’ intelligence. Are we expected to make sure that software we write runs properly in a production environment? Well I never.

Of course, in order to check your changes in production, you’re going to need to make sure that your code actually gets merged and pushed into production.

Damn, I knew I was doing something wrong. Code intended for production has to be pushed to production? By us? No wonder no one is using the software I develop.

I mean, you can’t really check your changes in production if you just let them sit unpushed for hours or days. Push your code. Get it into production. Then run it and check it.

I suspect the majority of programmers would welcome full scale adoption of continuous deployment. Unfortunately, it’s seldom our choice to make. It often comes down to the ignorance of higher-ups, or customer wishes. Many customers don’t want constant updates. For a post that’s all about thinking of the users, this remark is, well, remarkable.

Another thing to remember is that sometimes users do surprising things, which means that it’s not enough just to test that your code works under perfect conditions.

Again, we do know this. Don’t insult us. Here’s a fact: no matter how much you test, things break. Software is made by, and consumed by, human beings. Human beings are prone to making mistakes.

There’s one more important part to your job. You need to make sure that we can measure whether we’re all doing our jobs well. That means adding metrics and analytics so that we can test the effects of our changes.

Strictly speaking, implementing analytics solutions is our job if we are tasked to implement them. Not otherwise. As for analysing the data, that is not our job, nor management’s. It should be done by a data analyst, a person who is expert in statistical methods and mathematical models. In addition, data should be thoroughly validated by someone who actually knows what they are doing.

I know what you’re thinking. This will all take so long! I’ll be so much less effective!

I don’t know who the author has been talking to, but I assure you, no engineer or programmer I know thinks like this.

We need to spend less time demanding that you write features and more time asking you to improve our product for our users.

As far as I know, users like new features. Just saying.

I don’t know. I don’t mean to be rude, but this entire pieces reads like it was written by someone completely oblivious to what software engineering actually entails. It reeks of the type of ignorance one can find in people that are actually far removed from the realities of software development yet seem to think they are expert at it.