Some folks use the word “craftsperson” to describe what they do as programmer. Up until recently, I thought it was a dubious way to describe what we do.

However, recent reflections have led me to realize that, of all the silly titles programmers use to describe themselves, “craftsperson” is actually one of the more instructive1, for a simple reason:

A craftsperson cares deeply about their work.

Everyone should have a craft, and aspire to greatness in it. And that greatness comes from caring.

Do you find yourself mostly trying to hack together something that works, or do you really care whether you’ve found the best solution for the problem, one that will stand the test of time, other programmers, and – most of all – change?

If so, then congratulations, you can (correctly) call yourself a craftsperson. If not, you may have some work to do.

Caring leads to better systems.

It leads to deeper knowledge, better skills, and richer experience.

When we care, we become concerned with how things work, not just the high level interfaces we need to accomplish a task. We are mindful about how we go about our work, and we constantly look for better ways to accomplish our goals. Each step of our journey is meaningful for the improvement it brings to our craft.

So how do you “care” more? Fortunately, in this case, I think caring has much more to do with how we act rather than how we feel. The idea is to generate a positive feedback loop where improving our work habits leads to heightened care, which in turn leads to further improvement in our habits, and so on.

Which actions to take depend on where you typically least demonstrate care in your work. Here are some things I remind myself to do:

  • Read the full documentation, and not just the section that relates to your current problem.
  • Plan before your code. Write pseudo-code. Sketch out diagrams. When you think you’re ready, try to come up with one more alternative solution.2
  • Read science and technology papers. This can do wonders for filling important knowledge gaps.3
  • Get more disciplined about code quality (testing, code reviews, pair programming)
  • Continuously improve your tools (editors, automation, hardware)

I’m still not going to call myself a craftsman, even of software, but I try every day to care as much as one.


  1. How exactly do you “spin” code? 

  2. See Rich Hickey’s talk “Hammock-driven development”

  3. If you’re wondering where to start, try Werner Vogel’s Back-to-Basics reading lists on All Things Distributed. Just search the archives - unfortunately there’s no index post.