On Sharpening Your Tools

Using a Tool and Knowing Its Uses Are Not the Same

Save some time to dream
Save some time for yourself
Don't let your time slip away
Or be stolen by somebody else

— John Mellencamp, Save Some Time to Dream

Confession time, as a child, I have a distinct memory of using one of my father’s chisels as a screw driver. I suppose I should apologize for that.

Yesterday I received a lovely email that included the following question:

Is it common for programmers to spend a bit of their working hours fixing/sharpening their tools?

As I wrote up my response, I asked for permission to reference their question. The sender obliged, so here’s what I wrote (with some editing to reflect a broader audience).

The Value of Fixing/Sharpening Your Tools

This is a great question and I have two trains of thought.

First, I don’t know if you’ve heard of DEV but this kind of question is one that the community loves to interact with. I work for the Forem, the maintainers of the software that powers DEV; so I’m a bit biased on sending people there.

Second, let’s look and my specific situation and understanding.

It is my assumption that in the process of using my tools, I explore those tools for further utility or “productivity” gains. This builds on the idea that I am looking for outcomes not time in seat/at keyboard.
And please know that one outcome I consider absolutely enjoyable is the puttering of time simply playing with a computer. Much like idly whittling wood with a knife is quite enjoyable; and while the tangible outcome is a pointy stick, the intangible is a sense of wonder.
A case in point, I spent about 2 hours writing an emacs lisp function that helped me tidy up the the blend of our pull request template and the commit message). There are (or were?) a few outcomes of taking time to do that:

First, the solution saves me about 20 seconds of time each pull request. I’ve used that function about 150 times since writing it, so I’m at 50 minutes saved with a 2 hour spend. In addition, those 20 seconds saved also included micro-decisions.

By automating a bit of those tasks, I’ve reduced one location that might cause decision fatigue.

Second, I now have a mental pathway of how to do this or what might be possible; which helped me quickly write a script to facilitate writing end of week reports (10 minutes or so?).

I now use that new function about 3 times a week. I likely saves me 30 seconds of copy paste plus the context switching of multiple tools.

This pattern repeats itself in other tasks.

I have long mapped Cmd + . to toggle between spec/test and file. That alone has helped me always think about my test as well as the predictable file system structure necessary to sustain that pathway.

I have watched other developers open their project navigation tree, and click through folders to get to the related test. That consumes decision-making resources.

I recently fiddled with installing tmr.el, a timer package for Emacs. Why? Because I can now easily set a timer within Emacs. I don’t need to grab my phone (which the vary act of doing already breaks my mental thinking).

Do I anticipate using tmr.el much? No, because it’s not often that I want a timer while I’m at my computer. But it’s there. And I practiced setting it.

A final case of working with Emacs is work I did to help with my org-roam contexts. I can select a set of tags (or a named group of tags) to auto-filter my Org-Roam commands: capture, find, insert, or CaPF.

What this has meant is I can easily write work notes and play notes in the same directory. I can then both interconnect those notes but also help me not “accidentally” inter-connect them. This helps me remove a decision-making point.

It has also helped me begin moving my blog posts from stand-alone Hugo files into my PKM system.

And I try to do all of this “exploration” of my editor when I’m working on a well understood to me problem.

When I’m trying to reason through something more complicated or vague, I avoid trying to also dive into my text editor. But I might make a quick note to tell myself “Hey you did this thing…maybe spend some time thinking about it after you’re done.”

I hope this provides some context on why you personally would want to do it, and how it’s not about asking for permission but to instead have that be part of your software development process.

Ending with a Question

Now I’m wondering, what have you learned in sharpening your tools?

Credits

Photo: Tools on wooden background with copy space by Marco Verch under Creative Commons 2.0