What is an Engineer?

As I write this, it’s the start of 2026 and many people are in a crisis about what their job is. “If AI writes all the code, am I still an engineer?” “Will the world still need software engineers?” “What really is an engineer, anyway?”

Really, all of this comes down to that last question: what really is an engineer, anyway? Well, I have an answer for that that I think will help bring clarity to a lot of people. To get there, however, we’re going to have to go through a few logical steps that will seem stupidly obvious at first. At the end, though, it will be super eye-opening.

Let’s start off with a stupidly obvious definition of “engineer”:

An engineer (noun) is a person that engineers (verb).

Pretty stupid, right? Okay, so next step, what does “engineer (verb)” mean?

Engineer (verb) means “do engineering (the activity).”

Well, not interesting yet. It’s the next step where this starts to get interesting: what is engineering?

What is Engineering?

Usually I love dictionaries, but in this case, the dictionary is unhelpful. It says that the basic definition of engineering is: “the branch of science and technology concerned with the design, building, and use of engines, machines, and structures.” (Oxford New American Dictionary) This definition is why some people say “software engineers are not engineers.” They don’t build things in the physical universe. You could say that software engineers are building machines, they’re just logical machines instead of physical ones, but that really starts to feel like you’re stretching the definition. This is why many people insist on using the word “developer” instead of “engineer” when talking about people who write software.

The real problem with this definition, though, is that it doesn’t clarify anything for us. As AI becomes better and better at the design and building of software, is it the engineer now? That doesn’t sound right. We are still left wondering: what really is engineering?

Well, I have long had a definition for engineering that I really like that I think clarifies this tremendously. We will start off with the most basic version of this definition, and then build on it from there to understand what the job of engineers really is. The simplest statement is:

Engineering is taking the right actions in the right sequence.

You can use it exactly like that, and I often do. However, there are a lot of words doing a lot of heavy lifting in that definition, in particular, the word “right.” What is a “right action” and what is a “right sequence?” And why is “sequence” in there? Well, there’s a lot more to learn here, so let’s get into it.

Right Action

Most simply, a right action is one that successfully accomplishes your intention. If I intend to get dirt of my hands, washing them with soap and water is a right action. Putting my hands back in the dirt would be a wrong action.

Actions can be more or less right. If my hands are very messy, I can partially clean them with water alone. So that’s somewhat right. But using both water and soap is better.

People can have multiple intentions. They can say, “I want to wash my hands but I also want to conserve water and soap.” So then the right action would involve getting the hands clean with minimal use of water and soap. Every real engineering project I’ve ever worked on has multiple intentions. For example, “we need to solve this problem, but do it in a certain time and with a certain limited set of resources.” In fact, those specific constraints are so common that some engineers believe those are the only constraints they ever have to think about: deliver the expected result on time and under budget. But there can actually be an infinite number of different intentions, and real projects have many, many complex intentions. Just as an example, here is a set of intentions that could exist for a project:

• Spend less money on infrastructure than the product makes.
• Provide engineers interesting problems so that they keep working here.
• Split up the work so that the four people on the team can all be contributing.
• Ensure the CEO is happy with the product.
• Make the product appealing to a whole new set of users.
• Don’t lose any of our existing users.
• Get a person on the team promoted who really deserves it, by showing they can tackle challenging problems.

And so on, and so on. Real projects often have lots of intentions.

Taking this all into account, we see that we can expand our definition of enginering:

Engineering is taking the right actions in the right sequence in order to accomplish a set of intentions.

Intentions

Realizing that the definition has to do with intentions has all sorts of fascinating consequences that you can see play out in real engineering projects. Do we know what our intentions actually are? Does everybody agree about what the intentions are? Many teams have built the wrong things due to not knowing the answers to those questions.

You might also wonder, “how do we know if we have the right intentions?” If you think it through, you will realize that there is some higher-level, more senior intention that you’re trying to accomplish:

1. “Why are we building this user interface that lets people add numbers?”
2. “Oh, we’re building it because we are trying to build a calculator.”
3. “Why are we trying to build a calculator?”
4. “Because our users need to do math while they are working in this other part of the system.”
5. “Why do our users need to do math while they are working there?”

And so on and so forth. You can keep playing this “why” game until you get up to something like “because we have to survive” or “because we want to help people” if you really want. Usually you only need to do it until you understand the overall intention of a system you’re trying to build, or the overall intentions of the company/group you’re in. For example, you know, “our company exists to build bikes for kids,” and so at some level you can say “we are doing this because it helps us build bikes for kids.” This process of asking “why do we want to accomplish this intention” is how you determine if your intentions are “right” or not.

Doing this “why” game often tremendously improves the quality of engineering work that gets done. You very frequently discover that you are taking the wrong actions (or were about to take the wrong actions) by discovering that your intentions were not aligned with the more senior intentions.

Thus, you could actually say:

Engineering is taking the right actions in the right sequence in order to accomplish the right intentions.

Right Sequence

So why is “sequence” in the definition? Well, this is one of the key things that makes the definition of “engineering” different from “do good stuff.” Engineering projects always involve more than one step, and in order to accomplish one’s intentions, the order in which those steps are done matters a great deal.

Let’s say the intention is: “every time our hands get dirty, we will get them effectively clean.” Here’s a wildly wrong sequence:

1. Put hands under the faucet.
2. Remove hands from under the faucet.
3. Turn on water.
4. Put soap on hands.
5. Turn off water.
6. Rub hands together.
7. Get hands dirty.

If you look at that sequence and you just feel like you have to fix it, you may be an engineer. This is part of the art and science of what we do: we put many actions in sequence to accomplish intentions. Knowing what that right sequence is is a skill we develop through education and experience.

Sequences of Sequences

Sequences almost always contain other smaller sequences. There are sequences inside of sequences inside of sequences. For example, even “Turn on water” from above has a sequence:

1. Move hand to faucet.
2. Turn faucet in the right direction to turn it on.
3. Observe water as it comes out and adjust faucet until the intended volume is coming out.

And then each of those points has a sequence, and so on and so on.

In real engineering projects, this manifests in very large sequences that get broken down into smaller sequences. For example, if you want to build a website that has your resume on it so that you can get a new job, you might:

1. Investigate resume formats that have been successful at getting people jobs.
2. Build a web site that has my resume in a format that will successfully get me hired.

Then you would have to break down each of those steps into smaller projects. For example, the “investigate” step might look like:

1. Search the Internet for advice on resumes.
2. Read advice until I feel like I have a good idea of what to build.
3. List out friends who recently got jobs in the same field.
4. Ask those friends how they structured their resumes.
5. Write up brief notes on what I learned.

In that list, we start to see a little bit of the art involved in sequencing actions. Should we search the Internet first or should we ask our friends first? Well, the logic here is that searching the Internet can be done quickly, so I will get whatever benefit I can from that. But maybe actually the right sequence is to make the list of friends first, then email them and then do my Internet searches. That way I’m doing something productive while I wait for them to respond. This also exposes another intention that I have: “use my time efficiently.”

Engineers vs. Non-Engineers

Sequencing is where we start to see the core difference between how an engineer approaches a problem and how a non-engineer approaches a problem. A non-engineer will take any winding set of steps that vaguely accomplishes an intention—usually some narrow, more simple intention. Their process for building a resume might be, “I will look at one resume and copy it.”

Non-engineers are sometimes not aware of sequences at all, or only realize that there are additional steps when those additional steps hit them in the face. They might think, “I want to have a website,” and that the whole sequence is: “I will build this website tomorrow and be done.” Then a year later, something goes wrong with the website. Only then do they realize they also have to maintain that website. A professional software engineer would have known that from the start.

To be fair, this isn’t a black and white thing. Everybody has the experience of discovering there was some step they should have done, and only learning about it when it hits them in the face. Think how many engineers have realized, “Oops, I should have written more tests while I was writing my code, and now it’s really hard to go back and add them.” That doesn’t mean they are non-engineers. It just means they have more to learn, like the rest of us.

In fact, all of us are probably non-engineers in some part of our lives. I am not a plumber; I have attached shower heads in non-optimal ways and only realized the problem later. Knowing the right sequence requires expertise, and nobody has expertise in everything.

Sequences Are Not Absolutely Right or Wrong

Just like actions, some sequences are better than others, and some are worse than others.

Sometimes, the difference simply doesn’t matter that much. Like, if you’re washing your hands, you can argue whether you should get them wet first and then put soap on them, or whether you should rub soap on dry hands and then wash it off with water. The truth is, both of those sequences are going to get your hands sufficiently clean for most purposes, in the same amount of time, with the same amount of effort. There is a point beyond which optimizing the sequence just doesn’t matter.

However, that doesn’t mean that all sequences are equivalent. Too many times, I’ve heard people say things like, “It doesn’t matter how we get there as long as we get there.” There’s so much confusion in the world about “does it matter how we get the result?” If you’re doing engineering, the answer is: how we get the result is the fundamental nature of my job. If you think “how we get the result doesn’t matter,” then you simply are not doing engineering and you are not an engineer. There are, unquestionably, better ways and worse ways to accomplish a set of intentions.

(If you’re curious about how to figure out the right sequence of actions in software engineering, that’s essentially the core message of my first book, Code Simplicity: The Fundamentals of Software, which is free.)

All that said, there’s also no perfect sequence. It is possible to spend so much time trying to optimize the sequence in advance that you end up impeding your intentions. For example, if you spend three months trying to figure out the right sequence of actions for something that takes one day to build, you’ve wasted three months. If your intention was, “I’d like to engage in an academic exercise to try to optimize a sequence,” that’s fine. But if you had the intention, “I would like to have the maximum impact for the least investment of my time,” then you would totally fail at that intention.

Most engineering teams I’ve worked with do not spend enough time ensuring they are taking their actions in the right sequence. So usually, the problem here is that there’s not enough optimization of the sequence. But you can overdo it, so I wanted to mention that too.

Prerequisites to Action

Before one acts, one must decide how to act and then decide that one will act. Let’s say I have the intention to pick up a piece of food. Am I going to do it with my fingers or with a fork? Then after I decide between those, I have to actually decide to do it, and then do it.

Some decision always precedes an action. Before you found a company to build a software product, you have to decide to do that. The same goes for designing a new feature in your software, fixing a bug, writing a single function, or any other action you take as an engineer. There is always some decision involved.

Then, before decision, there is always some observation, perception, or data that triggered the decision or that helps us make the decision. You have seen some problem, you’ve learned some data, you have some reasoning, you feel some way, etc. For example, “we observed a user get confused about this button, so we have decided to make it clearer,” or “I have written a lot of software and I know that if you name your variables this way it will confuse the other programmers on this project.”

In life, a person could make a decision with no input (like “I have decided to yell for no reason”) but those aren’t the sort of decisions or actions that occur in engineering. In engineering, all decisions are based on some form of input.

I nearly always simplify this and just say that “observation” is required before a decision. Theoretically that could mean observation of your own thoughts or feelings, but if we want to be effective in the physical universe, it nearly always means “something I have perceived outside of me in the physical universe.” I find that the word “observe” tends to be the best for communicating that.

Thus, there is a universal sequence that is actually involved in all action: Observe, Decide, Act. Before I pick up a piece of food, I have to observe the food, observe that I’m hungry, observe the environment, observe my hand, and observe the fork. Then I have to decide whether to use my hand or fork based on those observations. Then I have to decide to actually pick up the food, and then do it.

Observation is King

You will find that the quality and quantity of observation is what matters the most for taking the right actions. Having the right inputs to a decision is what lets you make optimal decisions. The better your observation is, the better decision you will make, and the better the actions will be as a result.

If you wondered above “how can I know that I’m taking the right action before I take it,” or “how can I know that I took the right action after I took it,” this is the answer to both questions.

Often, people refer to this as “data” or “being data-driven.” In the full definition of the word “data,” that is accurate. However, people often don’t fully realize what data is—sometimes they think it’s just numbers in a table or in a graph. Now, don’t get me wrong—having real numbers in a table or a graph can be super powerful, if it helps you make the right decision. But there are so many types of observations that go into making a good decision that it’s dangerous to believe there’s only one type of observation that’s valid. Since people so often misinterpret the word “data,” I use “observe” and “observation” instead.

On the other side, there’s many people who believe that their own thoughts and feelings are sufficient to engineer a solution that will be used by many other people. That’s almost always an insufficient level of observation in order to make a good decision.

In fact, we are starting to even see what observations we need, and what the purpose of observation is, in engineering:

In engineering, the purpose of observation is for making decisions that lead to action.

Observations that don’t help us make decisions are useless. If I want to build software for tax accountants to do taxes, observations about a fish in the sea don’t help me. They might have other value for me personally (maybe I want to learn about cool fish) but they aren’t useful for engineering on my software.

Some observations are more helpful at helping us make decisions than others, too. For example, let’s imagine I’m building that tax accounting software and I’m trying to understand the problems those accountants have. A story from one of my friends who once talked to a tax accountant has some value, though it’s pretty minor. On the other hand, if a professional survey analysis company did a very thorough survey and analysis on my exact target audience with the exact problems pinpointed that tax accountants want solved, that would be tremendously valuable for me.

So we can say:

In engineering, observations are valuable to the degree that they help us make the right decisions that lead to us taking the right actions in the right sequence.

The Full Definition

This gets us to the final form of our definition:

Engineering is making the right observations, making the right decisions, and taking the right actions, in the right sequence, in order to accomplish the right intentions.

This gives us a huge range of things that engineers do that make them engineers. It shows us where we can grow, how we can improve our craft, and how we can know if we are doing our job well or less well. Maybe we know how to code, but not how to gather the data required to make those decisions, so we can grow there. Maybe we haven’t really studied up on how to sequence actions in our projects, so we can improve there. Maybe we are great at planning, but not so great at execution (taking action) and so that should be our focus.

As a side note, one of the reasons that I am so skeptical of standardized processes for software development (people showing up from consulting companies and saying “this is the exact, rigid process everybody must follow for all software engineering forevermore”) is that determining these sequences is one of the core jobs of an engineer. I have seen too many times where some overly-rigid process causes a team to do something stupid. Then I go and ask that team if they knew they were doing something stupid, and an engineer on the team tells me, “I totally knew we were doing something stupid and I knew what the right thing to do was instead, but I have been told I must do these things this way.”

That said, large-scale software development really is a team sport. It involves the coordination of lots of people. There isn’t a single person that’s going to do all of the observation, decision, action, and sequencing. There do have to be some agreed-upon methods of collaboration within a team. You can’t have everybody operating on a different sequence, a different set of intentions, conflicting observations, etc. So I’m supportive of setting up agreements about how a team or company will work, as long as they exist so that they enable engineers to take the right actions in the right sequence to accomplish the right intentions. There’s a lot more I could say about this and how to design a process like that appropriately, but that’s enough text that it would require a whole other blog post.

For now, I hope that I’ve helped clarify that an engineer isn’t just “a person who writes code.” It’s a person with a very deep set of skills that go far beyond that. An engineer has almost infinite potential for growth across every area of observation, decision, action, sequencing, and intention.

Exactly how that work gets done might change. How much effort is spent on each of those parts might be different at different points in the future. How much one engineer can accomplish might change. But there will always be engineers, as long as there are people living on Earth.