
I've been using the metaphor of blacksmith and cobbler recently in discussions about craftsmanship. Why?

Blacksmiths and cobblers are renowned as dedicated to their craft. Repeating the motions every day. They both take raw materials, perform a process of actions using a set of tools to refine those materials, and consistently produce something of practical value that is ready to use. For blacksmiths, the tools and materials are quite different from the cobbler's, but they share a lot of the same fundamental disciplines in practice.

With a little bit of Google research, you can find that a blacksmith today uses basically the same tools as blacksmiths before the industrial revolution, and those tools went largely unchanged for centuries. Of course, the Industrial Revolution changed our reliance on the local blacksmith, but the toolset of any blacksmith of any period would be quite similar to any blacksmith from any other period.

Similarly, the cobbler's tools have remained relatively unchanged. When new tools have come into the scene, they come by absolute necessity. The blacksmith and the cobbler wouldn't spend all of their time searching out new tools, constantly on the lookout for something to bend iron in a new way. More likely, the blacksmith would always be on the lookout for great scrap iron, and the cobbler on the lookout for good deals on leather, or building relationships with the people who fashion the cloth and buy the boots he makes.

<h2>We have a tooling problem.</h2>
Notice that neither the blacksmith nor the cobbler are careless about their tools. Both of them are highly focused, and highly skilled with their tools, and actually rely quite heavily on them. Their jobs depend on having a reliable toolset that they are experts at using.

I think developers today have a fundamental problem with tooling, and it's simple: <strong>we are constantly shopping for new tools.</strong>

You might be thinking, "I'm not shopping - these tools are free!"

But that's not totally true. Certainly, free and open-source projects don't cost you the currency available in your bank account. But they cost you another, perhaps more valuable, currency: time. You spend time looking, adopting, and deprecating your tools. You spend time reading blogs and books that compare tools, just for the sake of picking one. You spend time switching your code from one set of tools to another. You spend time retraining muscle memory, sometimes to accomplish the same goals.

<h3>Admission: this analogy isn't perfect.</h3>
Of course, we have a different trade from blacksmiths and cobblers. Our trade requires that we do, at a much faster pace, adapt our toolset to new demands in our industry. And perhaps it's because the product we make is virtual, not physical - the materials we use are thoughts, not iron and leather. And, it's also important to know that picking the right tools absolutely has an undeniable value proposition for your work. But the underlying truth is this: our constant shopping for new tools costs us that precious currency of time. The time you spend browsing the endless aisles of new programming libraries is time that could be spent becoming an expert craftsman, learning your existing toolset inside out.

I know, it's a hard problem to solve. I know, it seems like not knowing about a particular tool or another might put you behind the ball. So I'm going to make a very clear distinction here:

<strong>I'm not saying to bury your head in the sand, and never investigate new tools.</strong> Some very smart, influential programmers recommend learning a new language every year. I don't disagree; this keeps your brain sharp, and helps you stay aware in a constantly changing landscape. What I am saying is this: if you are constantly trying to <em>master</em> something new, you'll never master anything. Instead, you should be consistently <em>aware</em> of new things, while focusing on mastering <em>few</em> things.

<h2>When to pick tools: 6 guidelines</h2>
<em>Note: this is not a cohesive list of the only times you should pick tools, but it should give you some idea of how to think.</em>

- When you've got a problem that is proveably unsolvable or otherwise extremely inefficient to solve with current tools, especially if that problem has already been solved elsewhere. (If you're a C programmer and you need to serve a webpage, it's probably a good idea to learn about an existing tool like Apache instead of rewriting a web server in C.)
- When switching provides undeniable and exponential long-term gains. For example, switching to a new text editor that will increase your productivity every moment you are using it (I did this recently by moving to vim).
- When the tool is an easy win. Pick tools that are easy to adopt and provide obvious value without much investment.
- Lest we be hacked, upgrade your tools when there are security vulnerabilities in that tool.
- If You rely on your tool having adequate support or community involvement, it might be a good idea to choose a new tool when an old tool's support or community become dormant. With that said, choose based on your values in the first place. If the community is an extremely important value to you in the long run, only choose to invest time into tools that have a thriving, vibrant, and committed community.
- When the tool stacks well on your existing toolset. For example, if you have already learned HTML and CSS, it's probably a good idea to learn JavaScript, as the gains you receive by learning JavaScript are naturally complemented and increased by your knowledge of HTML and CSS. Other stacks you could learn:

  - You know Assembler? Learn C.
  - You know PHP? Learn Laravel.
  - You know LISP? Try out emacs.
  - You know Ruby? Learn about Rack or mruby.
  - You know Objective-C? Look into Swift.
  - You know JavaScript? Learn about how Node/IO.js works.
  - You know Java? Learn about virtualization, or learn Scala.
  - You know Apache? Learn some Linux sysadmin basics.

Pro tip: Be certain that you differentiate your <em>learning</em> efforts from your <em>tool-picking</em> efforts. You might choose to learn a new language that doesn't stack well with your current toolset, just to expand your brain's ability to adapt and think in new patterns. This has value, even if you never use that language as an actual tool. This is the whole idea of <a href="https://developertea.com/episodes/6877">code kata</a>.

<h2>5 step guide to picking tools</h2>

1. Look at your materials (read: consumer devices, browsers, iOS APIs, your unique service offering, etc)
1. Look at the available toolset (languages, frameworks, hardware, outsourced efforts)
1. Imagine your product (you fill in the parentheses on this one)
1. Pick the tools that can turn your materials into your product (make your best educated guess)
1. Repeat every 2-3 years, keeping a majority of the tools you picked previously, and dropping only the ones that didn't work so well.

<h2>Conclusion</h2>
You use your toolset every day; it's natural to want to refine that toolset. But changing your toolset constantly might mean that instead of spending time becoming a craftsman, you are just wasting your time constantly tool shopping. Learn to say no when your tools are perfectly capable of doing the job you need for them to do, and learn how to properly adopt new tools when the time and situation are right.


The Infinite Toolset, Craftsmanship, and Developer Sanity


I recently did a talk on some of the concepts in the book I'm working on. The talk really helped clarify some of the ideas I want to share with the world, and I'm sharing that talk with you today. Specifically, I discuss why our perception of creativity as it relates to logic is wrongly constructed, and a better way to understand our differences.

Hope you enjoy!

<div class='iframe-holder' style={{"position": "relative", "width": "100%", "height": 0, "padding-bottom": "56.25%"}}>
<iframe src="//www.youtube.com/embed/EooBGZpsE_Y" frameborder="0" allowfullscreen style={{"position": "absolute", "top": 0, "left": 0, "height": "100%", "width": "100%"}} /></div>


Talk: Creative DNA

Dustin Curtis wrote a <a href="http://dcurt.is/voice-interfaces">fantastic article</a> discussing the shortcomings of voice interfaces. I'd like to discuss a few further points in relation to this problem.

Go read his thoughts first, then come back. I'll wait.


<h3>Contextual Awareness</h3>
Dustin outlines that a lack of contextual awareness makes voice interfaces less than simple to use. I'd argue that this contextual awareness goes beyond voice interfaces and software, and affects the full product and experience design. At the end of Dustin's article, he tells people to imagine what could be done; here are a few ideas I have about contextual awareness as it relates to our devices today.


<h4>Why do I have to tell my phone when I'm holding it with one hand?</h4>
The Freaking Huge iPhone 6 Plus and the Slightly Less Huge iPhone 6 bring to light some important contextual issues related to human factors. Specifically for those who have smaller hands (most applicably, women), using the phone with one hand becomes difficult. In fact, Apple has introduced a strange accessibility mode that brings the top of the screen down by hitting the home button a few times in a row.

That's nice of them to help out, but why do I have to tell my phone how to be accessible every time I use it? Personalized accessibility should come as a standard. It shouldn't be that difficult of a task. In fact, how cool would it be if I could tell my phone how well I could reach, and it remember that? Perhaps adapt my interface to work with my hand better. Or maybe track where my thumb is and move the icons nearer to it, magnet-style. Seems relatively doable if Amazon's phone can track my eyes.

This kind of context is the low-hanging fruit; the things that continuously provide a positive return in user experience. This is the evolution of "user account preferences".


<h4>My life has modes; why doesn't my computer?</h4>
If you are like me, you have different modes of being. While I'm at work, I'm in work mode. Not everyone treats this issue in the same way, but perhaps you've experienced this before. This is especially important for people who use their computers in multiple contexts. I'd like to have a "mode" switcher on my computer. I should be able to flip a switch and open an environment on my computer that helps me focus, relax, or accomplish a specific set of tasks. For example, to record a screencast, I need my desktop cleared, a specific wallpaper set, a particular resolution on my screen, Do Not Disturb turned on, and an array of programs opened.

This should be a contextual setup on my computer, but it's not.

Maybe you have kids that you want to allow to use your computer, but you don't want to set up full user accounts for them. Why can't you easily set access control and flip a switch to change contexts?

It's very simple to make this happen - in fact, on a few occasions, I have set up scripts to make these kinds of contexts happen with a simple command. But unfortunately, my operating system doesn't do this on its own, and my contexts shift over time. Thus, maintaining scripts to handle this for me is unrealistic.


<h4>Mobile isn't replacing my laptop any time soon - it's just expanding it at a different resolution.</h4>
It seems that our desktop/laptop computers are staying relatively stagnant. The atmosphere of operating systems have changed in our lives because of mobile, but the desktop isn't keeping up. My computer should have sense-abilities that are currently reserved only for my phone, or at the very least it should be tightly connected with my mobile devices and use the sensors in my phone to inform it of context. My health tracking should be <em>most accessible</em> on my laptop, and should change in resolution as I move from the larger and more flexible laptop to more limited devices.

My laptop should be as smart or smarter than my mobile device. Until the resolution of interaction on a phone matches or surpasses that of the interaction on a desktop computer, desktop OS innovation <em>must</em> keep up.


Jonathan Cutrell

Talk: Creative DNA