I learned to write code procedurally. “Here’s a problem; tell the computer what steps to take to solve it.” That’s cool for learning how to tell a computer what to do. It’s an invaluable mental model, and it’s worth practice and attention to keep that skill strong.
But after you master that way of thinking, you pretty quickly want to transcend it. When you start to consider the lifecycle of production code – the fact that it needs to be read and changed and maintained – you benefit from orienting your thinking around transformations.
The thing we work with isn’t code, it’s code-over-time. Your ability to make sensible transformations to your code over time is what makes you effective. Making your changes simple and coherent means you can evaluate them quickly. Refactoring? Make a small change, then review the bigger picture. Adding a feature? Add a small piece, review the whole.
You’ll start to live in the feedback loop this creates, so you’ll want it to be short. You want builds, tests, and deployments to be fast. You’ll want mistakes to show up as soon as possible. That makes their causes clear. It makes fixing them fast.
This is valuable outside of code, too: Make a small change to your routine, evaluate. Make a small change to your team, evaluate. Make a small product decision, evaluate. Make a small change to the org chart, evaluate. Et cetera.
Delaying feedback creates fragility. That happens when we give in to the temptation to make our transformations too big.