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.
An author should always keep his audience in mind. The trick is to know your audience. Even when there are 2 or more different audiences.
Just like the code we write is going to be read far more often than we write it, the amount of code we change/extend is MUCH higher than the amount of code we write from scratch. So don’t forget, when writing code, you, or someone you know, is going to have to extend it. So be prepared.
Biases blind us to choices. Usually without us even knowing it. No matter how boolean a computer is, the world is an analog place, and things are on a continuum. Our choices should acknowledge that fact.
Comments are a code smell. You should always look at your code smells. But that doesn’t mean you shouldn’t comment your code.
All languages are not equal. You should use the language you’re using.
You can only keep so many things in your head at once. The trick is making sure they’re the right ones.
It’s important to distinguish the how from the what and the why.
When you say you want quality software, what are you really asking for, and how can you get it?
The trick is to know which models to use, and when to use them.
Because what you test is as important as how you test it.
That’s pretty clever, so fix it.
Why does focusing on finishing rather than starting get more done?
Tradition is more than just doing what your ancestors did
We aspire to uncouple with clear boundaries, but we need to work together