Elon Musk Interview

During an interview series on the Everyday Astronaut YouTube channel, Elon Musk gives a tour around Starbase while answering a slew of highly informed questions by the channel’s host. With a massive rocket booster in the background, Elon mentions his five principles that are largely responsible for the immense success of the SpaceX team.

Although the CryptoKing (Elon) tries, he admits that he is not perfect and continues to talk about instances where he had difficult time following his own rules – and paid the price. This interview covers it all, from grid-fins to fibreglass battery coverings, Elon doesn’t hold back during this interview. The only exception being details about the recent Raptor booster optimizations.

I’ve published a few thoughts on crypto, read about why I think Bitcoin Won’t Replace USD, or learn about Helium Mining.

Software Implications

Since the purpose of this article is not to simply recap Elon’s principles, review the infographic below and let’s jump into how these principles related to software development.

Elon's Engineering Principles from CodeTober
Engineering Principles of Elon, graphic by CodeTober

I can relate to Elon Musk, maybe not in financial success, but through anecdotes where I’ve failed this process. Hard. I’ll step through each principle and talk about how it applies to software development.

Make Requirements Less Dumb

Not unlike the commonly adopted Keep It Simple Stupid (K.I.S.S.) methodology, this step is all about reducing the project scope. By reducing the number and complexity of requirements, the end result becomes that much closer.

In the software world, we are all too familiar with projects that are packed with unnecessary requirements. While designing the requirements of User Interfaces is where I fail the most. My tendency is to assume that all users are power users that require the ability to touch every configuration possible. Because of this, I tend to crowd screens with options – which just creates clutter and wastes development time.

By understanding the user’s requirements, I’ve learned to reduce the clutter in my UIs and better adhere to Elon’s first principle.

When designing a digital watch face, I found a handful of bells and whistles most of which were not necessary:

  • Stopwatch
  • International times
  • Date functions
  • Clock
  • Lap Timer
  • Lunar Cycle Indicator

By reducing the requirements that I thought would be neat, I severely reduced the amount of effort and time spent implementing the watch face.

Delete Part or Process

Elon says that if you’re not adding 10% back into the project you are not cutting enough. I’ve never thought of it like this, but, makes sense to me. By consistently trimming and adding back small pieces, you can almost guarantee to minimize the complexity and cost of a project.

I like to delete the unit tests from my code in order to reduce the complexity…just kidding, I wish! Instead, I find that the easiest place to look for deletions is to first examine external dependencies. Especially dependencies that are error-prone or conflict with other packages.

Simplify or Optimize

To a software developer, this should be the easiest principle to recognize. Refactor! If you’re anything like me, the first time I write a particular piece of code I’m so far in the zone that some best practices like code reuse and design patterns escape me.

It’s usually only after I lean back in my chair with a triumphant feeling that I spot the cumbersome process taken or code duplicated in 10 different classes.

Because this should only happen after already removing unnecessary requirements and deleting unnecessary snippets, the output from this step should be production-ready code.

Accelerate Cycle Time

Until you’ve repeated this process several times, it’s likely that we are spending more time looking at ways to optimize rather than actually optimizing. Each iteration of the principles makes us faster at realizing our current step, but, also gives us practice at knowing which “gotchas” to look out for.

Chances are good that next time we go through the process that it will be faster, that’s good, but, keep up the pace.


Sometimes you can automate a process directly in your code, but, often this step falls on the DevOps and infrastructure teams. This might look like a CD/CI workflow where your commits to the master branch get automatically built and deployed. 

Even if CD/CI seems heavy for your pet project, this automation steps enables faster and more accurate testing of larger and production systems.

For smaller development projects, such as web services using NodeJS + Express, simply enabling Nodemon saves a huge amount of time. Not only because you don’t need to manually initiate the build. I’ve also found that by having a build run automatically, I’m more likely to continue debugging and fixing. If each build is a chance for me to move on, I might just take it.

So What?

Personally, I feel inspired to hold myself to a higher standard by implementing these principles. The original reason I created the graphic in the article is to print it as a poster and hang it next to my desk. With a daily reminder from Elon Musk, I have no doubt that my project quality will go to the moon.