Enjoyment of one’s tools

Here’s a quote from Donald Knuth I’ve been thinking about lately:

The enjoyment of one’s tools is an essential ingredient of successful work.

That makes a lot of sense. So does a quote from Joe Armstrong that I blogged about a few weeks ago:

Forget about the tools …

I don’t think Knuth and Armstrong necessarily disagree. I’ll explain the context of each quote and how I think they fit together.

The context of Knuth’s quote is a discussion of floating point arithmetic. It’s the last sentence of Section 4.2.2A of Seminumerical Algorithms. He’s saying that even though floating point arithmetic is inherently inexact, it’s important that it still has certain nice mathematical properties. I believe he intended the quote to be taken more broadly, in part because he italicized it. In any case, his immediate idea of a “tool” was very low-level.

The context of Armstrong’s quote is his advice to stay away from unnecessary software tools, especially when first learning a language. He says that

IDEs and build tools are the single biggest obstacle I know of to getting started.

He goes on to say that his basic programming set up is a shell, makefiles, and Emacs. These are tools, and I imagine Armstrong enjoys using them. They’re high-level tools compared to floating point arithmetic, but low-level compared to IDEs and build tools. (Incidentally, Knuth also uses Emacs.)

So, one way to synthesize the advice from Knuth and Armstrong, along with my personal opinion, would be this:

Pick a small set of tools that you enjoy using and learn them well.

Or possibly this:

Pick a small set of good tools and learn them so well that you enjoy using them.

Related post: Doing good work with bad tools

16 thoughts on “Enjoyment of one’s tools

  1. Excellent post John,

    Also you can say:

    The more you deliberately practice a tool beyond your cuurent ability, trying it, analyzing your performance while and after, and correcting any mistakes,
    the more you will enjoy the tool.


  2. The modern programming experience is like trying to find the little excuse for a screwdriver in a borrowed over-sized multifunction tool, pull it out without cutting yourself on the blades surrounding it, and then attempting to use it for serious carpentry. In the good old days you had your trusty real screwdriver right where you needed it in your own personal toolbox.

  3. Excellent points in this article. My favorite software tools are the ones that I understand what they are doing most of the time. For larger tools the problems are usually people, not technical.


  4. But how do you know you have the right tools to begin with?
    How do you know you wouldn’t be exponentially more productive using good tools built by smart people?

    Professional developers are duty bound to at least be familiar with major development tools, if only so that they can work with others.

    Scientists, however, may learn one or two tools well enough to forget that they are there.


  5. Yes, you have to spend some time deciding your toolset. And you’ll need to revisit that decision periodically.

    I’d say first to start with tools that people like you recommend. Don’t ask just what’s the best widget, but rather what widget do people use who I admire, who work on similar kinds of problems, etc.

    Also, I’d say that at some point you have to make exclusive decisions. Don’t try to keep up with two or three similar tools. Pick one in each category one and run with it. And as I said, you’ll revisit this decision occasionally.

  6. Great post. I completely agree. Over the years I have assembled a set of tools (hardware and software) that I use to create with. It’s easy to become overly distracted trying to figure out your tool set but once you’ve managed to figure it out it’s nice to be able to just focus on what you use the tools for instead of constantly upgrading them and buying new ones.

  7. I think it’s really about learning to go “full-stack”. I think the best thing you can do is grab an old PC download some version of Linux and go to town. Try several different distros. Use their package management system to build your stack. Try out all the different editors and desktop environments.

    You don’t have to stick to anything for long, the point is to kick the tires and to see how all the different tools work. If you want to take it to the next level, try and build your stack from source. The best part is, if you get your system all jazzed up, you can simply reinstall, it’ll only take a few minutes.

    Linux helped me understand all the parts and pieces which make up my “Operating System.” It gave me the freedom to choose the tools I use without being dependent on them.

  8. Or maybe you’re saying just use emacs?

    (this was meant in humour, not to start a flame war – but I think there’s a sort of unixy point about mastering some simple but powerful tools that specialise)

  9. I don’t think this has *anything* to do with platform choice — AT ALL.

    In my particular case my chosen tools (at this point in the game) happen to be:
    Microsoft Visual Studio 2008
    Grape City – Active Reports 6
    Microsoft SQL Server 2008 R2

    … and a spattering of auxilliary tools like Notepad++, GEdit and Axialis Icon Workshop and Microsoft Office 2003.

    I produce primarily Windows desktop applications. I’ve found the above to be what I consider a well-rounded and extremely powerful set of tools with which to build pretty sophisticated (but kept simple) applications.


  10. @Max Peck I’m not advocating a platform choice. I suggest using Linux to understand the full stack. This is definitely more applicable for web-based programming, but the point is to gain a better understanding of how tools interoperate.

    I don’t know if the suggestion would be applicable to Windows desktop programming, although I do think that learning other operating systems can give perspective of different tools. Essentially, it’s important to know the command line and Linux is a fun way to become familiar with it.

  11. I get the same feeling when I write software as I do when I play music. I play both drums and guitar, and when I find a good instrument that feels right, I’m not even thinking about the instrument while I’m playing. I’m focused on the sound and feel of the beat or melody. If I’m playing a good instrument that feels right I’m not actively thinking about my finger holding a pick and everything that happens when I strike or bend a particular string. If I’m playing a bad instrument I feel vibrations, resistance… the instrument gets in my way and reminds me too often that it actually exists.

    It’s the same with a good software development tool. A bad tool forces me to focus on the individual tasks of software development because it makes me focus on the tool itself. Good tools feel right, have a nice rhythm to them, offer little resistance, allow me to stay immersed, and let me completely focus on what I’m creating rather than the mechanics involved.

  12. I think I’d qualify it as “Pick a small set of tools that operate at a level at which you are comfortable…”.

    Full-blown IDEs provide a lot of high-level assistance but can also get in the way with busy, intrusive interfaces, slow start-up times, etc. Emacs and comparable source code editing environments have a different set of pros and cons. The best choice is going to be dictated by how you like to work and the size/complexity of the task.

    I think Kevin hits the nail on the head: it is all about rhythm, immersion and focus. A good tool will allow you to maximise those characteristics of your work (once you have climbed its learning curve).

  13. It is very true as Knuth says “The enjoyment of one’s tools is an essential ingredient of successful work”. Unless you enjoy a tool, you cannot bring the best out of it.

    As Armstrong says, “Forget about the tools …” is very necessary for developer to get a deep knowledge on the platform. How many see through the abstraction of Visual Studio on .NET?

Comments are closed.