The Engineering Mindset

Nikos Liokalos
ATCOM
Published in
4 min readSep 29, 2021

I have always loved space. It is this charm of the unknown, I imagine, that draws me to it. Escaping Earth’s gravity, the possibility of different physical laws, the otherworldly conditions of another planet — all of them so captivating. Mankind may have landed on the moon in 1969 but up until today, 50+ years later, it hasn’t done anything remotely like it, as far as manned space flights are concerned. In fact, even the task of simply trying to go back to the moon, would not be a given today.

In this context, the existence of a visionary like Elon Musk, who actively builds a spaceship (Starship) with the capability for crewed flights to Mars in a few years and the establishment of a human colony there, is undoubtedly impressive. In just a few years, Musk and the companies he runs (Tesla, SpaceX, the Boring Company, Neuralink, Starlink), have managed to disrupt several established industries and open up new ones. For example, automotive, aerospace, tunnel drilling, satellite telecommunications, solar power generation and storage, and even brain implants to power human-computer communication.

Having made his first millions founding X.com, the company later transformed to paypal.com, and known to delve too deep into what he does, Elon Musk is not the classic entrepreneur. On top of the CEO position that he holds in all the aforementioned companies, he also holds the roles of Product Architect and Chief Engineer at Tesla and SpaceX respectively. He can discuss technical details of the construction process, Rocket Science, Artificial Intelligence, as well as details of the software that runs the rockets and the cars that he builds.

With all this experience, it was very interesting to hear him, in a recent interview, compare Software Engineering with Rocket Science. I am sure his remarks apply equally in all industries, too.

Rocket Science as Software Engineering

Software Engineering is not Rocket Science, Musk says, but Rocket Science is a lot like Software Engineering.

Eliminating bugs in software is just as desirable as eliminating bugs in any product or service. These errors (in Software Engineering or anywhere, for that matter) largely reflect the organisational problems of a company.

Communication and domain-understanding problems result in irrelevant requests. Architectural problems result in suboptimal solutions. Implementation and quality control problems result in problematic products.

Get hold of your interfaces

Which is the source of these errors?

Individual departments of a company are where, just like between software components, your interfaces exist. Usually, each department presents its constraints, Musk says. Constraints that the adjacent department takes for granted. These are constraints pushed forward from the Commercial to the Technical Department and vice versa, from Legal to Financial, from one Business Unit to the other, and so on. What is certain, is that these constraints are, at least to some extent, wrong.

Why?

Because otherwise, it would mean that they would be perfect — and nothing is perfect. It is as simple as that.

Whichever way you look at it, you have to challenge these constraints.

  • Why is it like that?
  • Why can’t it be done in another way or in less time?
  • Why do we have this limitation? Is there another way to overcome it?

Even the questions asked must be themselves challenged. Because these questions are often wrong. There is no gain in looking for an answer to an irrelevant question.

The software engineer’s fallacy

One trap that some of the best Software Engineers often fall into, is trying to optimise something that should not exist in the first place, building a feature that no one needs or optimising the performance of a piece of code that is never or barely executed.

One must re-evaluate the importance of what he/she is working on every step of the way, whether this is code or just anything else.

What is the value of what we are building?

What do we have to gain from the effort we put into it?

What product, feature, service should we focus on for maximum results?

Best solutions Vs. egos

In addition, one thing that no one likes is someone else pointing out that they are wrong. We usually hold a defensive position and try to explain the sometimes faulty logic behind a technical implementation or a commercial decision.

But this is the greatest gift, according to Musk.

Because whoever is not open to accepting someone else’s possibly better solution is doomed to stick with his dumb implementation or decision.

To summarise the engineering mindset… (which interestingly applies everywhere):

Be curious, challenge yourself, ask the right questions, build and optimise only what is needed — and be open to accepting others’ better ideas or solutions.

Now let us fly to Mars!

Originally published at https://www.atcom.gr on September 29, 2021.

--

--

Nikos Liokalos
ATCOM
Writer for

An experienced e-business professional involved in strategy, consulting, and product development. Chief Technology Officer at Atcom.