The ancients recognized the wisdom of sharpening one’s tools.

If the iron be blunt, and he do not whet the edge, then must he put to more strength: but wisdom is profitable to direct.

– Ecclesiastes 10:10

In more modern times the same sentiment is apocryphally attributed to Abraham Lincoln.

Give me six hours to chop down a tree and I will spend the first four sharpening the axe.

While these adages are obviously true, they have an extra meaning in software development. But what does it mean to use a dull axe? It means to do something that is harder than it would be with the proper knowledge or tools. For example:

• Making repetitive text changes instead of using editor shortcuts or a regular expression.
• Manually rerunning shell commands after changing a file instead of using a file system watcher.
• Not learning and using a build tool.
• Failing to document infrequent but repetitive tasks.
• Not using automated testing.
• Recognizing repetitive code and making another copy instead of extracting the functionality.
• Working at too low or too high a level of abstraction.
• Reinventing the wheel when a perfectly good library exists.
• Not reinventing the wheel when existing libraries are misaligned with your needs.

But why is a it doubly important for programmers to use a sharp axe? The cost of a dull axe is not just the additional time spent on a particular part of a task. The additional cost is a context switch. Programmers are quite familiar with the how exhausting a yak shave can be. Context switches drain productivity and sap mental energy. Any time a dull axe causes you to switch contexts you pay twice – the initial time cost and the cost of switching back to the original context. Conversely, any time you sharpen the axe by improving tools or skills you gain twice – first in saved time and second in less context switches.