Engineering as a Dialogue with the World: An Engineer’s Manifesto
Since childhood, I’ve dreamed of becoming an engineer. Whenever someone asked what I wanted to be when I grew up, my answer was always the same: I wanted to be an engineer, just like my father. To me, being an engineer isn’t just a line on a diploma or a job title; it’s a way of interacting with reality. It’s an attempt to decipher how things are built, why they behave the way they do, and what happens if you tweak even a single parameter within a system.
Beyond the Tech Hype
I stopped viewing engineering as a mere collection of mastered technologies a long time ago. Tools change too rapidly to build an entire expertise upon them. There is little point in taking pride in a list of learned programming languages, frameworks, operating systems, or PC specs—those are merely shifting backdrops.
Once, a professor called me the “worst kind of engineer” because, while solving a problem at the chalkboard, I couldn't recall the specific parameters of a microchip and suggested looking them up in a manual instead. Now, thirty years later, I am convinced he was wrong. In today’s world, the volume of reference data required for daily work is too vast, and it becomes obsolete too quickly to keep it all in memory.
The technological landscape shifts just as fast. Think back over the last twenty years. Where is Dial-up now? Where are the DVD players or PDAs? They became obsolete faster than we could get used to them. What remains, however, is engineering logic. The ability to deconstruct the complex into simple components, to see cause-and-effect relationships, and to make decisions in the face of a data vacuum—that is what defines an engineer.
Respect for Reality and Its Constraints
Engineering thinking demands a respect for facts and data. Every system—whether it’s code, infrastructure, or a human organization—has its own parameters, functions, and inherent constraints. A system always behaves exactly as its conditions allow.
Over the years, I’ve learned not to fight constraints, but to work in synergy with them. An engineer shouldn't impose their will upon the world; instead, they should seek that unique form where the solution feels natural and viable.
Furthermore:
Simplicity beats flashiness. Complexity is a "tax" you’ll have to pay later for failing to grasp the essence.
Predictability beats flexibility. A system whose behavior cannot be forecasted is unreliable, and sometimes dangerous.
Idealism is a compass, not a destination. We strive for perfection, but we build in the real world.
These principles aren't always easy to apply, but they are exactly how one creates systems that survive beyond their first iteration.
Working with the Unknown: Korolev’s Lesson
True engineering begins where ready-made answers end. The hardest thing for me to learn was how to make peace with uncertainty—not to avoid it, but to accept it as part of the input data.
I’ve always admired the story of Sergiy Korolev during the development of the first lunar rover. Scientists were arguing: was the Moon’s surface solid rock or a layer of cosmic dust? The entire design of the craft hinged on the answer. When the debate hit a dead end, Korolev took a piece of paper and wrote: "The lunar surface is a sufficiently firm soil of the pumice type"—and signed his name.
That was pure engineering risk. Korolev took responsibility for an assumption so the team could move forward. I often use this example in both engineering and management. When expert opinions are split, someone has to say: "We’re doing it this way. I am responsible for the consequences." The world (and the universe) tends toward increasing entropy; the engineer’s job is to bring order to that chaos.
In real-world projects, ideal solutions don't exist—there is only the "best possible at this specific moment."
Time as the Ultimate Judge
Time is the harshest critic. What looks elegant today may prove non-viable tomorrow if the engineer failed to account for all conditions. On the other hand, sometimes a system arrives too early, and Time gives it a second chance later.
The Concorde was a triumph of engineering but lost to economic reality.
The Tacoma Narrows Bridge was graceful but collapsed because it ignored the laws of aerodynamics.
Python, created by Guido van Rossum back in 1991, waited decades to become the foundation for AI.
These examples teach us to think in terms of time horizons. How long will this be used? How will the system be maintained in five years? How will it adapt to change? Where will it break?
The Systemic Dimension
As scale increases, problems stop being technical. They become systemic: sitting at the intersection of technology, processes, and people. I’ve seen brilliant software fail due to poor communication, and mediocre solutions thrive for years thanks to intuitive interfaces and the persuasiveness of their creators.
This is felt most acutely in the public sector. There, the "laws of physics" sometimes operate differently, and the dimensions of space are far more numerous. An engineer must be more than just a "techie"; they must be a communicator capable of aligning complex contexts.
This also applies to my fascination with AI. To me, it isn't magic; it’s a powerful, multifaceted tool. It requires more than just technical or mathematical knowledge. Every technology changes something in the world, and we must understand exactly what that is and what the consequences will be.
An Honest Dialogue with Reality
Engineering is a path of searching, doubting, and cautious optimism. It does not tolerate falsehood because it is grounded in an honest dialogue with reality—a place where you cannot "negotiate" with gravity or logic. It is a constant process of discovery, where there is always room for new ideas and the professional recognition of those who see the essence of things.
