Elon Musk biography by Walter Isaacson is having a great success. In the first weeks after its release I have seen many people on social network reading it (and of course sharing pictures of pages).

The major idea contained in the book is (or seems to be) the so called Algorithm that Musk applies to any of his job activities as illustrated in this post by DHH.

Actually of that post I appreciated also the idea that “You can absolutely learn from people you wouldn’t want to be”. This is a lesson that I will try to implement in my life and career.

The Algorithm

But back to the Algorithm. Being an algorithm, consists of steps. Here it is in full:

  1. Question every requirement. Each should come with the name of the person who made it. You should never accept that a requirement came from a department, such as from “the legal department” or “the safety department.” You need to know the name of the real person who made that requirement. Then you should question it, no matter how smart that person is. Requirements from smart people are the most dangerous, because people are less likely to question them. Always do so, even if the requirement came from me. Then make the requirements less dumb.

  2. Delete any part or process you can. You may have to add them back later. In fact, if you do not end up adding back at least 10% of them, then you didn’t delete enough.

  3. Simplify and optimize. This should come after step two. common mistake is to simplify and optimize a part or a process that should not exist.

  4. Accelerate cycle time. Every process can be speeded up. But only do this after you have followed the first three steps. In the Tesla factory, I mistakenly spent a lot of time accelerating processes that I later realized should have been deleted.

  5. Automate. That comes last. The big mistake in Nevada and at Fremont was that I began by trying to automate every step. We should have waited until all the requirements had been questioned, parts and processes deleted, and the bugs were shaken out.

Debugging

During a session of debugging (that took days), after reading this piece, I realized that some steps of the Algorithm are used (or could be) in debugging. Let me explain.

  1. Question everything. If the code or system is not working, don’t take for granted where the problem lies. Not even if you have spent hours writing the code or a senior team mate tells you that the error “it’s impossible to be there”.

  2. Delete any part you can + Simplify. Produce a minimal reproducible example of the issue. In this way you can focus on a way smaller area to find the bug.

  3. Accelerate cycle time. Reduce the feedback loop. Especially if you are working on cloud environment, pipelines runs can take a lot of precious time. Summing up extra time for each run, if you need many attempts, can translate in valuable hours wasted. The faster you can test your hyphotesis the better.

  4. Automate testing. If you use tests (and we all should), add the test to avoid the problem in the future.

Probably it’s nothing new, after all I don’t plan to disrupt the automation industry or send people to Mars, but I thought it was nice to see debugging under a different light.