First Make the Change Easy

You open the file
to add one small thing.

And the file fights you.

The seam you need isn't there.
The logic is tangled
in three places at once.

The temptation is to force it.

Wedge the new code in
sideways,
where it doesn't fit,

and leave a mess
for the next person
who was probably going to be you.

Stop.

There is an older move.

First make the change easy.
Then make the easy change.

Spend the first ten minutes
not adding anything,

just moving things
until the shape of the code
has a place for what you want.

Pull the tangled part into a function.
Give the seam a name.
Separate the deciding
from the doing.

Now the file is ready.

Now the thing you came to add
is one line,
in one obvious place,

and it reads
like it was always meant
to be there.

The refactor and the feature
are two different jobs.

Do them in two different commits,
so the person reviewing
can see the shape move
without a new behavior
hiding inside it.

This feels slower.

It is not slower.

It is the difference
between paying now
and paying with interest
every single time
you touch this file again.

The easy change is a lie
told by a hard codebase.

You don't get to make it
until you earn it.

You earn it
by making room first.

So before you write the feature,
ask the quieter question:

what would have to be true
for this to be easy?

Then go make that true.

The best code
is not the code
that solves the problem.

It is the code
that made the problem
look simple.

– Serguey Asael Shinder