Notice Abstractions Early

It’s easy to think “I’ll copy and paste now and refactor later”. This is problematic for two reasons.

First, this line of thinking can be applied repeatedly, since we are human and thus by default bad at delayed gratification.

Second, refactoring later can be more difficult than you think. Ad hoc implementations tend to be similar but not exactly the same. Specifically because they are ad hoc, they can be tweaked to match the individual use case in the most tailored way. Pulling out commonalities into an abstraction will go smoothly for two-third of the use cases, but will be a serious pain for the remaining third because of the tailored use-case specific modifications. Note that this does not imply that the abstraction you’re trying to create is a poor one. Had the abstraction existed in the first place, the code that adapts the abstraction to the concrete use case would have been different as well, not better or worse, but different. This is generally true about refactoring code — there will always be a small portion of code that is far easier to rewrite than to adapt to the updated structure.

There’s an added benefit to abstracting early — it lets you put a box around complexity, give it a name, and hide the details from sight. This lets the reader focus on what the code does instead of how it does it, saving them brain cycles.

Next: Abstraction vs Boilerplate ⇒