Disclaimer: All the information below is a summary from an interview of Elon Musk done by Tim Dodd the everyday astronaut. It has been extremely valuable to me, and hopefully it will do the same for you.

Problem

  1. Where does productivity come from?
  2. How are some engineers 10x more productive than others?
  3. You want (need) to move faster in your startup?

Solution

Make the requirements less dumb

all requirements are dumb especially ones from smart people, because no one questions them.

One of the projects I was working on, we wanted to raise some capital through an ICO. There was some back and forth in the team and a strong sentiment arose, that we had to build the hole system end-to-end. Meaning everything from the quotes, to the transaction matching, to the settlement (exchange of funds), to the reconciliation. We had the price quoting and transaction matching as part of the platform, however, the settlement and transaction reconciliation were unique to this use-case, so we’d have to build them from the ground up. Also, there was a lingering feeling of “what if we need it again in the future”, so that made it even more compelling to go with the full solution.

However, that would’ve been a huge mistake because:

  1. Implementing, testing and fixing all the bugs would’ve delayed the ICO given that we only had a month.
  2. The actual exchange and reconciliation of funds didn’t have to happen real-time.
  3. The last ICO was almost 5 years ago. The next time we need this would be at least 5 years from now.

Regardless, we started implementing it, given the collective confidence was so high. A week into the project we realised this was not going to work. We had done only 10% of what were supposed to and unexpected bugs were already cropping up. It was at that time we sat down and boiled down the requirements to what were the most fundamental parts, without which, there was no way of implementing this feature. And we found them.

Without a separate set of tables, more HTTP endpoints, thousands of lines of tests, multiple weeks of back and forth between developers and QA, only to miss a small bug that would make all investors pull their capital, we implemented the ICO with … a couple of Excel files and a small script to actually do the exchange. And it worked perfectly!

Whenever you start implementing a feature, think of the most basic, fundamental requirements that would achieve that feature. Usually the simplest ones, are the most correct.

Delete the part or process

You don’t actually need it.

This is going to sound super controversial, but you don’t actually need a database. When you think about it, there are two reasons we have a database in the system (or in general some form of state storage):

  • Because there is some non-ephemeral, non-reproducible input to the system, that cannot be derived purely through a set of initial conditions and logical rules.
  • If the above is possible, but too expensive to do on the fly.

Imagine you own an app that sells digital products. How would you setup the sales process?

I bet immediately some form of registration springs to mind with a database to store all the user, products, purchases and any additional metadata. To be honest that sounds pretty complicated.

What if, instead you kept all the products with their prices in flat file, let’s say JSON format because everything is in JavaScript. Once the payment goes through, you can use the paymentId as part of a download URL, which you’d probably send via email. Once the user clicks, you verify the unique payment id against your payment providers API and only then allow download of whatever digital product/access you are selling. As for people abusing the download link, there are three ways you can solve this:

  • if it’s a one off access based product, e.g. digital event, you could not have any protection really
  • if you are using an on demand ec2 instance you can keep everything in memory
  • if you are using Stripe you can add metadata to the invoice object that will signify it has already been claimed

That to me looks way simpler, than having to provision a DB, maintain it, setup backups, write a bunch of ORM code, etc. Always try to err on the side of not doing less work or outsourcing to a third party. Remove or push the responsibility. If you find yourself stuck or that there is no other way around it, only then introduce that part or process.

Simplify and/or optimize

the most common error of an engineer is to optimize something that should not exist

Unless you’ve been living under a rock you will have, if not used, at least heard of Kubernetes. A few years ago it became very “fashionable” to use clustering solutions.

Guess what - you don’t need Kubernetes to host your workload. You could instead host everything on ECS. Just have a Docker container, create a few lines of Terraform, and it’s there. And it scales! Automatically! Instead, if you are just testing out something, you don’t even have to Terraform it you can instead do it by hand in the AWS console.

However, when you think about it, the workload is mostly short-lived CRUD operations. Those you can just host on AWS Lambdas (or Google Functions; just joking I know you are not using GCP). Also, if you don’t mind using JavaScript/Typescript you can even have the deployment done for you with Serverless. If you want to have some jobs running periodically you get them for free. And let’s not forget that, if by some miracle you found yourself working on the next Facebook, those Lambdas are infinitely scalable.

But now that you think about it, if it’s only going to be a bunch of CRUD operations, why not just go with some no-code solution and only move to something less expensive or more scalable, once you are flooded with users.

The point is - don’t just jump on “what everyone else is doing”. Instead, look at what you are working with and ask yourself “is it really not at all possible to simplify this? 🤔”.

Accelerate cycle time

you are moving too slow - go faster!

I don’t know about you, but I am not very smart. It would seem that so is Elon Musk. He has figured out that it is impossible to produce the perfect solution on the first try. That’s why everything he works on has a process in place to iterate and get feedback as fast as possible. Take for example Starship. He and the team decided to go with steel, not in small part, because of how easy it is to work with. It gives them the ability to quickly assemble a prototype, test it out, see it fail (because it always does) and then, once they realise they had everything all wrong, tear it down and start from scratch. The biggest productivity boost I’ve seen in my career was having the ability to quickly get something out the door, gather some data and then, even faster, ship an improved version. In the software engineering world this translates to:

  • Writing tests first as you are developing functionality.
  • Making deployment transparent and preferably with(out) a click of a button.
  • Put a process in place to collect customer feedback and turn that into JIRA tickets.

Automate

Don’t repeat yourself

Once you are done with removing requirements, features, unnecessary technologies and you are left with 50% of you started with, it’s time to automate it. For me the biggest productivity boost was having the corporate VPN start automatically. To this day I can’t believe I wasted at least 5 seconds a day for 6 months, for a job that took me a couple of minutes to automate.

However, always remember the wisdom of the ancients and not spend automating something that just doesn’t make sense

when_to_automate

Do steps 1-5 correctly and in the right order

All of these are great suggestions, however, it’s important to do the steps exactly from 1-5. Depending on how wrong you get the order, you might not get any productive boost but instead slow yourself down even more. There is nothing worse than:

  • spending a week automating a painful issue
  • of a feature you developed too quickly
  • that was greatly simplified
  • which shouldn’t have existed in the first place
  • and it all came from a dumb requirement