Who Is an Engineer?
A working definition of engineering as a practice, not a credential, and a map of what this Journal is for.
Ask most people to define an engineer and you'll get a credential: a degree, a licensing exam, a job title on a business card. It's not a wrong answer. It's just an answer that stops being useful the moment you meet someone with the title who can't debug their way out of a paper bag, or someone without it who just quietly fixed the thing everyone else had given up on.
So before this Journal writes a single word about systems, failures, or architecture, it's worth settling what we actually mean by the word in the name.
The Textbook Answer Runs Out Fast
The standard definition, the one you'll find in most encyclopedias, describes engineering as the application of science to convert the resources of nature into things people can actually use. That's accurate. It's also incomplete in a specific way: it describes what engineering produces, not who is doing the producing, or what's happening in their head when the design refuses to cooperate at 11pm.
Definitions built around output describe a profession. They say nothing about the person running it. And that's the actual gap — most writing on this subject stops at describing the job, never the mind doing the job.
The Person Before the Job
Start over, from the person instead of the profession. An engineer is not a certificate. It's someone who can look at a mess and see the shape of the problem inside it, then build something that resolves it. The certificate is one way of proving that capacity exists. It is not the capacity itself.
Which means the real question was never "what does an engineer do." It's "what does an engineer's mind do that a non-engineer's doesn't." And the answer to that question is not tools, or languages, or CAD software. Those are what an engineer picks up after the thinking has already happened. The thinking is the actual profession. Everything else is just the current generation of instruments for carrying it out.
The Actual Operation
If the person is primary, then what's primary about the person is a specific way of thinking: the ability to model a system, form a testable view of why it's behaving the way it is, weigh the environment it sits inside, and predict what happens three moves after the fix — before making a single change.
That's a sharper claim than "engineering is design under constraint," though it's related. Constraint is the terrain. The thinking is what lets someone move across it without getting lost. Anyone can be handed a budget, a deadline, and a river that doesn't care about either. What separates the engineer is the internal method: notice the system clearly, build an honest model of it, test the model against reality, and revise the model — not the reality — when the two disagree.
There's a cleaner way to say what separates this from science: science describes the world as it is. Engineering acts on the world as it could be. A scientist explains why a bridge stands. An engineer decides where to put the next one. Isaac Asimov put it better than most: "Science can amuse and fascinate us all, but it is engineering that changes the world." But the changing only happens because a mind first ran the model, checked it against the ground, and predicted the consequence before committing to it.
The Beauty of It
Here's the part the textbook definition can't reach at all: the beauty of engineering isn't in the bridge, or the payroll system, or the app. It's in the method of approach. It's in the creativity required to hold variables that refuse to sit still — people, economics, weather, politics, a client's real need versus their stated request — inside one coherent model, and still ship something that works.
Handling a beam is a solved problem. Handling the people who'll use the beam, the budget committee that approved it, and the decade of maintenance nobody's yet agreed to pay for — that's where the craft actually lives. Anyone can be taught the physics. Fewer people can be taught to see a payroll system, a school, and a city as the same kind of object: a system, with feedback loops, failure modes, and unintended consequences waiting a few moves out. That act of seeing is the whole discipline, compressed.
Wider Than the Job Title
Once engineering is a way of thinking instead of a credential, the category gets bigger, not smaller. It shows up anywhere someone is working on a system that pushes back: a civil engineer routing water around a city, a founder wiring together a payroll compliance system for businesses that have never had one, anyone building infrastructure and discovering, in production, exactly which of their assumptions were wrong.
That's the lens this Journal writes from. Not because software is the only place engineering happens, but because it's a clean, fast-feedback example of the same mind at work everywhere else the word applies.
Why This Journal Exists
If that's what an engineer actually is, then a stream of tutorials isn't the point. The point is getting better at the thinking itself: noticing systems clearly, building honest models of them, weighing the variables that don't behave, and paying attention when the model turns out to be wrong — which it will.
That's the whole editorial thesis, and it's why this site isn't organized as a chronological blog. Different parts of that thinking need different kinds of writing:
- Mental Models are the lenses you bring to a system before you start changing it.
- Deep Dives follow one failure mode all the way down to the mechanism, like why distributed systems fail in cascades.
- Post-Mortems and Teardowns are what the model looked like once reality corrected it.
- Learning Paths connect all of the above into something you can actually build judgment from over time, instead of a pile of disconnected posts.
None of it works if the definition at the center is a credential. It only works if the definition is the person and the thinking, because that's what's actually transferable from one system to the next.
What to Expect
New pieces land here on a regular rhythm.
If you write code, pour concrete, design policy, or build anything that has to survive contact with reality — and think it through before you touch it — you're the reader this was written for.
Further reading: Encyclopedia Britannica, "Engineering" · Michigan Technological University, "What Is an Engineer?" · American Council of Engineering Companies, "What is Engineering?"
