Dear [Software] Engineers,

Your job is not to write code.

Rather, your job isn't only to write code. Your job is to design and build software, and one of the steps in that process happens to be explaining to a computer how to do its new job.

An article appeared on Medium recently that writing code isn't really a big deal and it's not really what your job is about. It is. You can smell "Product Manager" miles before the signature line of the article.

The article goes on to talk about how your job is to improve your products for your users. This is not the job of an engineer — this is the job of every person at your company. Some of the people at your company can affect this more directly than others, but it's still everyone's job. Even yours. Usually, you have other, more specific, jobs in addition to this one, but it's still your job. So are things like designing software.

Let's consider some of the other jobs the article asserts are yours.

Should you "make sure the code runs the way it should"? Absolutely. To achieve this, you might need to consider operating systems, web browsers, network stacks, chip architectures, runtime environments, available system resources, or countless other things. These things take experience, and you'll make mistakes along the way. This is okay; that's how you learn.

Much of this kind of testing, though, is the job of someone trained to test your product. Testing is really hard, too. It takes time to test, and it takes a careful eye to spot something misbehaving in any product of significant size. The person doing the testing needs to understand all of the details of the product to even realize that your style change made a button slightly too small for its container and violated some particular style guide for the product that you didn't even know about because you're not a graphic designer. Maybe your product is small enough that you can wear this hat, too, but that's exactly what it is — wearing another hat. Sometimes, this is also your job. Sometimes, it's not.

What about making sure that your code "actually gets merged and pushed into production"? It depends! Are you a Release Engineer, too? You might be, depending on the size of your company or the structure of your deployment process. Do you understand release schedules and per-client deployment rules? Will merging and pushing your code make a client angry because the account manager on that job promised them that those kinds of changes wouldn't go out until after the holiday season blackout? Are you expected to keep track of that at your company? You might be. You might not be! In large enough companies, there are literally teams of people to coordinate that kind of thing. In a small enough company, this might also be your job; it might also be another hat you have to wear.

Does your code need to work under every possible condition? Well, it needs to work under some set of conditions, but not all of them. When a Product Manager says something needs to work under "all" conditions, they mean "under every condition that is obvious to me", which has a different meaning than "all" to an engineer. Does the product really need to work on a toaster running NetBSD while it is also making toast? Does it need to work in Lynx and in Links? When on dial-up internet? On IE5? 5.5? 6? On machines from 1998? On machines with international keyboards that can't type $?

Every additional condition under which the software has to work means that engineers need to spend more time making it work there and that testers need to spend exponentially more time testing every release there. This is a cost-benefit analysis that involves considering target audience, time to market, maintainability, and roughly four-point-two-billion other concerns that you didn't even know were a thing. So, is it worth it to make sure the application functions when the user does something unexpected? It depends. Is it worth that much extra effort to the business? Will the business get more users or make more money or improve whatever-their-key-metrics-are to such an extent that it outweighs that effort? If it will, then sure, go for it. If spending another two weeks to get the website working in IE6 will help almost nobody, then maybe it would be better to work on something else. Is it your job to determine that? Maybe — if your head can fit that many hats. I'm tempted to suggest you get a hat rack at this point.

Should you add analytics and metrics to your code? Probably. You should also make sure your code is maintainable in the future, which requires predicting the changes that will need to be made in the next weeks, months, or years — which, I should note, is substantially harder than figuring out whether it will rain tomorrow, and that alone is an industry. You should make sure your code is clean and easy to read, that is, that the intent of the code is obvious to a human reader. You should make sure your code is secure. You should separate code in ways that make it modular and reusable (based on those forecasts you just did) — but not too reusable, because now you're just wasting time, and why weren't you working on the next feature in the queue if the code "already works" as-is?

Because your job is to write code. Your job is to write the best code you can, as quickly as you can, within budget, meeting all of the expected features, in a maintainable way, and a million other things, and still make the users happy. And yes, all of your goals conflict with each other, and you will make mistakes, and you will fail, and you will learn, and you will get better, and you will succeed. Your job is to tell someone when you make a mistake. Your job is to work together with your testers and with operations and with product and finance and, yes, even the other engineers. Your job is to figure out what product will ask for before they ask for it, and build the code so that if and when they do, adding the feature is easy because the code wasn't written in a way that requires a year-long refactoring project to do it in a way that wouldn't make Cthulhu literally gleeful at the thought of it.

You're an engineer, and your job is to design and build software — your job is to engineer things, and to love every second of it.