In design work, you cannot simply ignore errors and hope they won’t become an issue later. They tend to remain unnoticed until the precise moment they become critical.
A well-known example of this is the positive scram effect in RBMK reactors. The shutdown system is intended to reduce reactivity, but under certain conditions, inserting the control rods temporarily increased reactivity instead. This phenomenon wasn’t unknown; however, it was left unaddressed, accepted, and worked around rather than fully resolved. The likelihood of such conditions arising was considered unrealistic, as it was believed that the power would never peak at the bottom 30 cm of the core.
On April 26, 1986, it did peak. This highlights the nature of design errors: they don’t have to be active all the time; they just need the right combination of circumstances to cause problems.
If something is wrong, do not just move on. You must isolate it, understand it, and fix it properly—even if it doesn’t seem strictly necessary at the time. Not because it will always lead to issues, but because one day it might.
Good engineering, in part, means refusing to leave loose ends unresolved.
***
Engineers should still know how to use a slide rule, not out of nostalgia, but as a discipline.
I carried one for as long as I could. While a slide rule shouldn’t be an everyday tool, it should be a part of every engineer’s training.
Using a slide rule prevents you from hiding behind digits. You have to estimate the magnitude before you even begin your calculations. If you don’t know whether the answer is 30 or 3,000, you’re not ready to calculate.
This habit of estimating first could eliminate a surprising number of engineering errors.
A slide rule also encourages you to think in terms of relationships instead of just numbers. Multiplication, division, and powers are represented as distances on a scale. You begin to understand how different factors scale—such as flow versus pressure, temperature versus density, and power versus reactivity. That is where true understanding comes from.
Additionally, a slide rule enforces precision with three significant digits—no more. This constraint prompts you to evaluate whether the inputs or even the model justify anything beyond that. Most of the time, they don’t.
Modern tools can provide answers with twelve digits but rarely indicate whether those digits are meaningful.
Using a slide rule means you are involved in every step: choosing the scale, placing the decimal, and interpreting the result. You remain in control.
When the model deviates, when the system behaves unexpectedly, or when the numbers seem “fine” but something feels off, you revert to that mindset: estimate, perform a sanity check, and rebuild from first principles.
That’s engineering—not simply generating numbers, but knowing when those numbers make sense.
***
The simpler it looks, the more design work it takes.
Simplification isn’t cutting corners - it’s designing better to get rid of excess complexity. Putting more effort into planning, not less.
Ideally, you don’t see any of the effort when looking at the final product. But it is there.
***
Copying an idea is easy. Transplanting it, however, is not.
Every idea is built on a series of assumptions. These assumptions can relate to various factors, including physics, user behavior, constraints, and potential failure modes.
Many of these assumptions remain invisible, operating in the background to make the idea functional. When you attempt to copy an idea without fully understanding these underlying assumptions, you are not truly replicating the idea; you are merely copying its surface. And the surface is the least significant aspect.
An idea works because certain things are true. Change those, and it becomes something else.
Changing any of these factors can result in the idea behaving very differently. Sometimes it degrades, sometimes it fails, and at times it may even become dangerous.
Engineering history is filled with instances where a solution that was “proven” effective in one scenario failed when applied elsewhere. This often occurs not because the idea itself was flawed but because the original assumptions did not transfer successfully.
This tendency is particularly tempting with elegant solutions. When something appears clean, simple, and efficient, the instinct is to reuse it. However, elegance is often conditional, depending on a very specific environment where trade-offs were carefully balanced. Move that solution to a different context, and the balance can be disrupted.
To truly understand an idea, you must ask:
What must be true for this to work?
What underlying factors were silently relied upon?
What was intentionally overlooked?
What is likely to fail first if conditions change?
If you cannot answer these questions, you do not fully understand the idea. Without that understanding, you cannot safely reuse it. You are no longer engaging in engineering; you are simply hoping for success.
Good design is not about copying solutions. It is about comprehending why those solutions worked and then purposefully determining whether those reasons still apply in a new context.
***
At twenty, I spent a summer in a shipyard, building pieces of offshore structures that would never be seen again once they left the quay. The work was loud, heavy, and indifferent to elegance.
One week, I was given a simple task: take 250 steel disks—ST52, half a meter in diameter and 100 millimeters thick—and drill and tap two 20 mm holes into each. They were meant for threaded lifting eyes, the kind you screw in, not weld on.
On paper, it was straightforward. In practice, it was a slow negotiation with mass. Each hole began with positioning, clamping, and aligning. Then drilling—steady pressure, careful feed, clearing chips, listening for the tone that says the tool is no longer cutting cleanly. Then tapping, which in that thickness becomes less a motion than a commitment. You feel the steel resist, then yield, then resist again. Back off, clear, advance. Repeat. Two holes per piece, 250 pieces. The rhythm set in, but it never became light.
Somewhere around the second day, the question arrived and stayed: why are these threaded at all?
A welded lifting lug would have been quicker. Cut, place, weld—done. No long drilling, no risk of broken taps buried deep in a hundred millimeters of steel, no week spent feeding a machine through work that felt, even then, avoidable. Perhaps there were reasons—standardization, removability, inspection conventions, or simply a habit carried from another context. But standing there, covered in cutting oil and steel chips, the choice felt distant from the reality of making.
You learn something in that kind of work that drawings do not quite convey. Effort is not abstract. Every additional operation has weight, time, and failure modes. Threads that look neat on paper become torque and friction, and broken tools. Thickness is not a number; it is resistance.
I finished the batch. The disks moved on, the structures were assembled, and the week disappeared into the larger project. But that small question remained. Not as a complaint, exactly, but as a calibration: design choices propagate all the way down to the person holding the tap. And if you have never stood there, it is easy to miss what those choices really cost.
***
An engineer who never builds tends to misjudge what is practical. The same is true of an engineer who never writes a model: the results are taken at face value, as if they were measurements, rather than the outcome of a chain of choices.
On paper, many things look equally easy. In the workshop, they are not. A layout that is “compact” in CAD leaves no room for a wrench. A tolerance stack that closes neatly on a spreadsheet refuses to assemble without force. A control loop that is stable in simulation hunts because the sensor lags and the actuator sticks. None of this is unusual. It is simply how real systems behave.
Without contact with that reality, judgment drifts. You assume alignment is easier than it is, access is better than it is, signals are cleaner, and delays are shorter. You design for ideal components rather than for how they are installed, wired, heated, and handled. The result may look coherent and still be difficult—or impossible—to build and operate.
Building corrects this quickly. After a few assemblies, you begin to see the hidden costs. If a fastener cannot be reached comfortably, it will be skipped or mistorqued. If parts do not self-align, assembly becomes a fight. Variation accumulates and shows up at the worst interface. Systems that were “steady” on paper reveal lags, saturation, trapped air, and small nonlinearities that dominate behavior. Measurement turns out to be the most fragile part: what you thought you could observe cleanly is often the noisiest signal in the system.
The same loss of touch appears in numerical work. A model produces a clean curve, and it is tempting to treat that curve as the truth. But a numerical result is built, not discovered. It depends on the discretization, time step, solver tolerances, boundary conditions, and the closures used to represent what is not modeled. Each choice leaves a trace.
An engineer who has written even a modest solver recognizes those traces. A smooth profile may be numerical diffusion. A sharp feature may be driven by a boundary condition rather than the physics. “Convergence” may mean only that the residual decreased, not that the solution is correct. Stability can be purchased with damping that, in effect, removes the effect of interest. Agreement with one dataset may reflect tuning rather than understanding.
Without that experience, it is easy to over-trust. Grid independence becomes a box to tick rather than a question of what has truly converged. A single time step or solver setting is accepted because it runs. Fitted parameters are read as physics instead of compensation. A good-looking plot carries more weight than it should.
Writing code changes how results are read. You begin to ask practical questions. If the mesh is refined or the time step reduced, what moves? Where do boundary conditions dominate? Which term in the equation is doing the work, and could that be an artifact of the scheme? What was tuned to make this case fit, and what breaks when conditions change? You also gain a sense of cost: a model that is only slightly more detailed can be much slower, harder to stabilize, and more fragile.
With that experience, designs—physical and numerical—become more robust. You leave space for tools and hands. You add features that guide assembly and allow adjustment. You specify tolerances that reflect variation. You place sensors where they tell the truth. In models, you test sensitivity, separate what is known from what is tuned, and resist the urge to overinterpret clean outputs.
The difference is not philosophical. It is the difference between something that looks reasonable and something that can be built, started, understood, and trusted.
***
Calling someone a “specialist” often sounds like praise. It isn’t always.
It can be a subtle way of shrinking a person’s scope.
When you call someone a specialist, you are not just describing expertise. You are drawing a boundary around it. You are saying: "This is where your thinking applies — and outside of it, it doesn’t."
In real systems, especially complex ones, the problems don’t stay inside neat domains. They live in the interfaces — where disciplines overlap, where assumptions collide, where no single “specialty” owns the outcome.
Label someone a specialist, and you risk implying:
– their competence is narrow
– their judgment should be consulted only within a predefined box
– their responsibility ends at the edge of their field
It becomes a permission structure for others to ignore them outside that box.
Worse, it can be used defensively. If a “specialist” raises a broader concern, it’s easy to dismiss it:
"That’s not your area."
The label is not only descriptive. It’s also limiting.
The irony is that deep expertise is often what enables broad understanding. The people who understand one domain properly tend to see where it connects — and where it fails.
They are often the first to notice when something is off outside their “assigned” scope. In fact, having a deep understanding of one field is a prerequisite for becoming a true generalist.
So calling someone a specialist can invert the truth:
- it presents depth as narrowness
- it turns capability into constraint
There is a difference between having a deep understanding of a matter and being confined by it.
The first is strength.
The second is how organizations miss problems.