Musk’s product tips

I was reading this post by DHH about Musk: https://world.hey.com/dhh/the-musk-algorithm-977bf312, and it’s interesting in many ways. 

First, I agree that it’s hard to see the things that work in such a divisive person (like Musk). We’re all polarized, and I suffer from this too.
Through many years, I’ve learned how to take the good things out of a book, even if the book was mediocre, exaggerated some lines, or expressed them as if they were the solution to all problems in the world.

Of course, there are no books like that, but it was hard for me in the beginning to detach the content from how the message was conveyed.

Applying this rule to people is even more difficult, and Musk is a good example of that.
I’m fascinated by the protocol highlighted in the DHH post because it has some hidden consequences that are not visible on a first reading.

Question every requirement.  +
Delete any part or process you can. 
I think these two rules are much more intertwined than they look. 
To me, these two elements serve the purpose of not being attached to any idea, of not being a “fan” of an implementation, but of looking at them from a distance.

Loving an idea, a solution, or an implementation is risky. You might defend it even if it’s wrong; you might, more or less intentionally, steer away from other solutions only because you feel they are not as good.

We should be ok with abandoning a project, an idea, or an implementation, but as with people, we tend to care about them and will miss them. We tend to protect the things we struggle for, but that is often a sunk cost to us.

Simplify and optimize.
Accelerate cycle time
Automate. 
These last three steps instead, focus on improving efficiency: first by reducing complexity, then by speeding that up.

Reducing complexity is an interesting topic. As a developer, I was deeply fascinated by very abstract, very dynamic code that could “do everything”.
Now I think that the simplest the code is and the more straightforward it is, the better.

Because, at the end of the day, we don’t know who will need to touch that code or in what state they’re in (maybe they’re in the middle of an emergency, and they need to act fast).

Simple code helps everyone, it’s easier to maintain, debug, and fix, and the same rule applies for processes, for features, and for plans.

The simpler, the easier to manage.
Some things are inherently complex, but even that complexity can be reduced.

For example, Apple is not yet providing a calculator on the iPad. It’s a simple thing to implement, right? But they chose not to have it anyway. This reduces the complexity (even though it seems silly, that’s what it does). Fewer features, less complexity.

Reducing features or customizations is an interesting way to simplify, especially because you can always change your mind and add them back in.