Move fast and break things might work for a disruptive business, but as a long term coding strategy it leaves a lot to be desired. In fact, it’s a self-defeating strategy.
One of the biggest superpowers you can give your code is optionality. You can do that by making sure you have clean boundaries between components. And that the components themselves stay that way.
We think we want a one size fits all solution because it will be easier and save time. But it never does.
Knowing how to do something doesn’t mean you know when or where you should do it. Or even if you should. That’s the difference between skill and experience.
Similar to MMMSS, you can also break your tasks down further.
Can you design for change and re-use? Should you? Isn’t doing one thing and doing it well the goal?
Trying multiple things at once is NOT faster
60 years in, the Unix way still makes a lot of sense