Everyone Is a Process Engineer

All of us have a conception of reality, a framework for making our way through the world. Paul Copan states it well: ”everyone is a philosopher”. Not because everyone is profound, but because everyone is operating from some model of what is true.

One does not need to apprehend some high degree of profundity to be a philosopher. Far from it, the simplest frameworks are often the most pragmatically successful. A philosophy does not have to be impressive to be useful, but it does have to correspond to reality.

If this is true, then on any given topic the whole human race can be split into two camps: good philosophers and bad ones.

As software engineers, we put our philosophy to work. We have expectations around how software should look and feel, how collaboration should happen, and which methods of working toward a goal produce the best results. When a software engineer is excellent at their craft, it isn’t magic. It is that their framework is well calibrated to reality, that they are a good philosopher of the process of engineering.

Much of the inefficiency of the software development process exists downstream from bad philosophy. Sometimes this is because the framework doesn’t correspond to reality, but sometimes this is because there are multiple competing frameworks which are incompatible with each other. This risk becomes exponentially worse in the context of teams, where a diversity of opinions requires hard work to be harmonized.

We are not all doomed to be a prisoner to our existing processes, we can reflect and improve. The highest leverage way to do this is to externalize the process. Sir Francis Bacon, the father of the scientific method, puts it this way:

Reading maketh a full man; conference a ready man; and writing an exact man

So how do we improve?

• Read and listen to excellent Engineers
• Talk with other engineers about your ideas
• Write your process out on paper

That third point is the most important one. Writing out a process is like taking a design session and putting it into code. The incoherent pieces become glaringly obvious when you externalize them.

Large engineering orgs have always meant that processes needed to be externalized. Before the advent of coding agents, many small organizations could get by without externalizing their processes. This is no longer true. With agents, even an individual engineer faces the large org’s challenges. We all have to externalize our system in order to ensure the actions of agents align with our intentions.

What might this look like in practice? Check out this article for a concrete application of this given 2026 conventions.