If you ever ask an engineer what engineering entails, you will usually get some noun. Compilers, circuits, engines, bridges. The fancy names and nouns differ, but the verbs repeat. Every engineering domain is a discipline of constrained modelling and creation, imagining something that does not exist, representing it as a human understandable model, and then persuading reality to accept that representation at an acceptable cost, all for the goal of making our lives easier or better. Maybe modernism too eh.
The art is not in the tools, but rather in the judgments the tools cannot make for you, and a man's imperfect vision of a perfect solution.
Science questions you on the fact. Engineering tells what is possible with sacrifices.
The budget may be mass, watts, milliseconds, dollars, memory footprint or the number of people who can understand the system at any point in time (big ask if it is 3 in the morning). A vision of a solution that disregards constraints is not ambitious, it is unfinished and crude. The first act of engineering is therefore not construction but questioning yourself on what is it that you need AND accounting. Yes accounting, what are we spending, and on what?
A bridge spends steel to buy span. A database spends memory to buy latency. A compiler spends compile time to buy runtime. Optimization is never free. It is the deliberate choice of which scarcity to tolerate. And the most annoying of it all, is the situation when the constraints are in a conflict, how does a good Engineer choose between multiple constraints that are equally important?
Every field reasons through models. Beam theory, type systems, queueing models, finite elements, statics. A model is a compression of reality that keeps the part you need and throws the rest away. Nothing but a proposition to reality, to bargain your needs.
The engineer's question is not "is this model true?" but "is this model true enough for the decision at hand?" A type system that ignores aliasing is fine until two references mutate the same object. A benchmark that ignores the cache is fine until the working set grows madly.
So the art here is knowing, which part of your model is important and load bearing, and which part is eye-candy.
No one holds a complex system in their head. We build them out of parts that other people designed, tested, and documented. Abstractions are the contracts that make this possible.
A good interface hides a decision and makes a fair promise. A bad interface hides a bug and whacks you in the face on a fine good day. The art is choosing the seams. Where to fold or cut the system so that each side can be understood, visualized, tested, and replaced without messing up the whole.
Every abstraction leaks. Well it is meant to?? Well, I don't know, but the art is not avoiding leaks, but to let what you want the other side to see and pass through the joints. It is putting them where failure is observable and cheap and importantly, stupid easy to understand.
Every field has some vocabulary or fancy nomenclature for the same idea. DO NOT DESIGN TO THE EDGE.
Civil engineers call it a safety factor. Mechanical engineers call it tolerance or something. SREs call em an error budget. Some or the other fancy term, they all mean the same.
Engineering is the art of modelling materials we do not wholly understand, into shapes we cannot precisely analyse so as to withstand forces we cannot properly assess, in such a way that the public has no reason to suspect the extent of our ignorance.
~ A. R. Dykes
Margins are not timidity or fear of failure. They are the price of uncertainty that you can't calculate, just paid in advance. And the art is knowing how much to buy.
Give two engineers the same constraints, the same everything, and they will still produce different things. Why?
The difference is judgment, knowing what is worth solving, when good enough is realllly good enough, when to break an abstraction, when to stop optimizing, and when a warning sign is worth a week of investigation (Or maybe AI tokens nowadays). Intuition is abstract, but good intuition remains falsifiable. The best engineers I have seen hold strong opinions loosely and test them cheaply or well try to ig.
Drawings, specifications, units, schemas, tests, commit messages, incident reviews. All these exists because the artifact must survive contact with other people AND to appease others.
Ambiguity is a defect. An unmaintainable system is an unfinished one (thanks to unplanned AI sloppery, this is the hardest). The system includes the people who operate it, who debug it at questionable times, and the people who inherit it after you leave. Engineering is not done when the thing works. It is done when the thing can keep working without you. Well technically it is never done, because you pawned it off on someone else, but you get it.
Strip away the fancy nomenclatures and the same stance remains. Treat constraints as the medium, models as instruments, interfaces as promises, feedback as the method, margins as the price of uncertainty, and judgment as the part that cannot be outsourced.
That is why engineering is an art. Not because the finished result is aesthetic or perfect, but because it requires choosing well when the rules do not choose for you but instead fight you back.