First make the change easy,
then make the easy change
This line is from Kent Beck, the software developer and creator of extreme programming. It arrived in my life at the right time and never quite left.
First make the change easy, then make the easy change.
Refactoring code can be a challenge. Software grows with time; left unchecked, it thickens into something hard to reason about. Spaghetti is never far from the word that comes to mind. When I need to add a feature to a tangled module, the temptation is to reach straight for the feature — but the feature is usually not the hard part. The hard part is that the module wasn't ready to receive it.
So I've learned to pause and do the boring work first. I'll rename a variable that's been quietly lying to me. I'll split a function that does two things into two functions that each do one. I'll move a helper to where it belongs. None of this is the change I came to make. All of it makes the change I came to make trivial.
The shape of the idea extends past code. When I'm stuck between choices that feel equally uncomfortable, it's almost always because my thinking isn't organized enough to tell them apart. The honest move is not to pick faster — it's to do the work I should have done already. Write the thing down. Separate what I know from what I'm guessing. Remove the options that don't actually exist.
After that, the decision tends to make itself. Which is the point: the quote is really an instruction about preparation1, dressed up as an instruction about code.
1 Or, less charitably, an instruction about not being in a hurry.