This post is a follow up on a previous post regarding “Don’t call yourself a programmer” as well as a response to “The hustler’s manifesto“. These articles attempt to impart wisdom on the craft of software development for the sake of happiness and job security. Both articles basically tell you to focus on delivering business value and not on “solving complex technical problems” or “dorking out hardcore”. Taken at face value this business-oriented, pragmatic approach has a lot of merit. This may be fine for a programmer, but for an engineer this advice is utter crap.

A Linnaean taxonomy of software development

Once upon a time there were computer scientists and hackers. The world was simple. Then a lot happened, and software was everywhere. Now there are programmers, developers, devops, engineers, architects, and dictators roaming distant lands. Where did these roles and titles come from? My faux taxonomy starts with three classes:

• Hackers — Focus on the pragmatic and the immediate
• Engineers — Focus on balancing theory with the real world
• Scientists — Focus on the theoretical

This taxonomy is a useful lens to interpret these other articles. For many people in the startup world, there is an obsession with getting to market quickly and cutting out anything that doesn’t have immediate business or customer value. If you live in this world, it is natural to gravitate to the hacker mentality such that your thinking resonates with the “just build things, motherfucka” crowd. This is great advice if you’re building a prototype or a toy, but for anything else you need to up your game. It’s fine being content as a programmer or hacker (you may well become very successful), but for the love of God, don’t call yourself an engineer.

On being an engineer

The above proclamation is not a self-aggrandizing manifesto. It’s a reality check. Software development is an engineering discipline not unlike civil engineering or electrical engineering: there are objectives, constraints, models, designs, and an underlying theory that explains how it all works. Engineers are meant to solve complex technical problems and not business problems. These complex technical problems are driven by the business, but that doesn’t mean they are business problems. If you start believing that you’re simply solving business problems, then you have nobody in your corner fighting The Good Fight. There is no simple way to build a bridge, a microprocessor, or a software system. It takes time, and it’s hard. Business people don’t understand that. They don’t have the patience to think through the details, the use cases, the edge conditions, the failure scenarios that as an engineer you have to consider. Faced with this unique set of constraints, you have to design a system that optimally solves this problem.

If you can do this, then you’re an engineer. And guess what? You’re not redundant because you’re solving unique, non-recurring problems. If you’re not doing this, then you’re probably a hacker and there’s probably some dude(tte) at Google or Apple focusing on the unique problem of how to auto-generate the code you write.

The magic of language

The moral is that you can’t become an engineer just by calling yourself one. You also won’t become redundant by calling yourself a programmer. Each class of software developer has their place in the ecosystem, and it’s useful to know where you stand. What matters is that you’re solving new and important problems. If you’re not solving new and important problems, then you’re just re-inventing the wheel.