Are You a Programmer or a Software Engineer?

So you write code for a living — does it matter how you call yourself?
The (tongue-in-cheek) answer is both yes and no.

Let’s start with “yes”.

On naming things (and invalidating cache)

If you work with code, eventually you’ll stumble upon the old adagio by Phil Karlton (as per Uncle Bob’s quote):

There are only two hard things in Computer Science: cache invalidation and naming things.

This little pill of wisdom encapsulates beautifully how something apparently simple is actually a rather complicated job.

In particular, naming is a powerful tool because we can use it to define the scope of anything we put a label on. In other words, “naming is framing”.

Spot the difference

Both “programmer” and “software engineer” labels indicate the job of someone who instructs a machine to do something under a given set of inputs and circumstances (for the argument’s sake, let’s leave AI out of the picture).

Typically, said person would go about building software through the act of writing working code that is also easy to read, extend, and maintain.

Writing code is part science and part art. When coding, there are many ways to achieve the same result: while some aspects can be measured precisely (e.g. how many milliseconds it takes to run this snippet of code?), there are many flavors and styles to what great code looks like. Regardless of what you call yourself, we can probably all agree that writing code is central to getting the job done and writing great code is a pretty darn difficult thing to do.

One of the two labels mentions “engineering”, so let’s dig into it.

ECPD’s definition of engineering reads:

The creative application of scientific principles to design or develop structures, machines, apparatus, or manufacturing processes, or works utilizing them singly or in combination; or to construct or operate the same with full cognizance of their design; or to forecast their behavior under specific operating conditions; all as respects an intended function, economics of operation and safety to life and property.

Ok, that’s a lot to unpack and it’s indeed a broad definition that groups many disciplines under a big umbrella. One bit I would focus on is the last one:

“[..] all as respects an intended function, economics of operation, and safety to life and property”.

In other words, when we engineer a solution we want to make sure:

• it solves an actual problem;
• it does so efficiently, within the context and constraints of the domain it operates into;
• its usage doesn’t cause direct or collateral damage.

Isn’t that what a programmer does?

Partly, yes.

When we approach a problem with the mindset of a programmer, we define the necessary inputs and the desired outputs of a constrained problem, then we build a solution that guarantees the correctness of its execution (i.e. “It works™”).

When we switch to an engineering mindset, we go even further beyond and we ask ourselves:

• To which degree do I understand the problem we are trying to solve?
• Is it a problem worth solving? Is it the right time to solve this problem?
• Who will benefit by the usage of our solution and will their problem be truly solved by it?
• What are the costs (monetary or otherwise) that we will incur in operating our solution at scale?
• How do we identify undesired side effects ahead of time? If we don’t, how do we find them and correct course later on?

And so on and so forth.

I can hear someone arguing, “We have a PM/designer/tester/analyst/CxO for this!” - and that someone would not be entirely wrong. There are great reasons to have a mix of specialties in most teams, the most compelling probably being “a specialist will get the job done better and faster”.

So what’s the problem with that?

The “conveyor belt” mindset

There is a risk in compartmentalizing the various functions in any team or organization — we assume each person in a given role can operate successfully in isolation from the rest.

This approach works on a conveyor belt, repeatedly assembling yet another copy of a predefined product. It works rather well because each function on the chain has one job and one job only; in fact, anything that takes away focus from that one job puts the entire manufacturing production at risk.

The conveyor belt mindset is highly counterproductive when it comes to knowledge work. It is indeed the overlap of different domains, skills, and talent that creates the best products and solutions.

When we switch from a programmer-only mindset to an engineering one, we push our scope and influence beyond our little silo of expertise (i.e. writing code) and we contribute to build a world where the final result is greater than the sum of its individual parts.

For example, your PM might not know that there’s a better way to solve a given problem — maybe even one that doesn’t require engineering work at all. Maybe a chat with the UX researcher or the data analyst will provide you with insights that will help you implement a more refined solution for your customers. Maybe the UI designer would love to help simplify frontend development via a design system but they don’t know where to start.

The more you expose yourself to other functions and areas of competence, the more chances you have to bring positive impact to your team and organization.

How does an engineering mindset serve “me”?

When you think as an engineer, you are not only better contributing to the organization you work at or collaborate with.

You are in fact making sure you develop as a T-shaped professional: a generalist who can look at things from different angles, and then go deep when it comes to practicing their own craft.

As an EM, I value engineers who (are willing to) step outside of their comfort zone and get their hands dirty with cross-functional work. By doing so:

• they can be a great sparring partner to leadership roles;
• they can contribute to the decision-making and the long-term direction for their team;
• they get exposed to more growth opportunities and actively shape their career.

So everyone who writes code should be called a Software Engineer?

No, that’s not my point. If you like to call yourself a programmer or developer, nothing wrong with that!

What I am suggesting is that coding is a beautiful craft that often fits in a greater scheme of things (and, hopefully, supports a positive mission). Understanding the context around the code you write and how it brings the most value to the bigger picture, is a skill every programmer/developer/SWE should pick up.

We can code just for the fun of it, and that is absolutely fantastic! I would argue we should practice our craft intentionally and become every day better programmers who can write working, clean, efficient, and elegant code.

My recommendation is to approach writing code with an engineering mindset, alongside a T-shaped attitude. Doing so will make you grow faster as a professional, expand the radius of your impact, and open the door to more opportunities.