Tools Matter More than You Think

Tools Don’t Matter

Guitarists have this idea: “tone” is in the fingertips.

The argument is, the distinctive sound of your favorite musician isn’t because of some expensive guitar, fancy pedals, or boutique amplifier.

Instead, their talent comes from years of practice, and no amount of expensive equipment is a shortcut to sounding great. So for new practitioners, it’s best to focus on your competency and technique, and forget about the tools.

Regardless of the tools you use, you’ll become great with practice, and that greatness will translate regardless of tools with mastery.

But Tools Can Improve the Quality of Practice

Believing this to be the case, I spent the first 7 years of playing electric guitar with a decent, but not great amplifier.

Why invest in an expensive amplifier and guitar when your skills don’t justify it?

But then the pandemic hit, and I got bored. Many of the “reasonable” guitars I wanted were sold out, and weren’t expected to be in stock any time soon. So I started looking at more expensive guitars and amplifiers, as they were the only ones left.

Out of desperation I bought a substantially more expensive setup than I ever dreamed of– an ESP E-II Horizon FR and a Mesa Boogie Mark V:35. When I plugged in and started playing, my mind was blown.

Why didn’t anyone tell me the difference was so big?!

I could now sound just like the musicians I grew up with, and my practice routine went from being a grind to a pleasurable experience. Thanks to my improved tools, I also started picking up on subtle sloppiness in my playing.

I literally bought myself a better practice routine, and a substantially better sound. Tone may be in the fingertips, but it helps to be able to hear what’s happening in those fingertips!

The Best Says He Can’t Work without His Tools

Given this personal discovery, I was again surprised while watching Tom Morello’s Masterclass on guitar playing. For those of you who aren’t familiar, Tom is widely considered to be one of the greatest guitar players of all time.

In his Masterclass session, Tom recounts a time when he and the rest of Rage Against the Machine went to South America, separated from their specific instruments, pedals, and amplifiers. They went to practice on rented instruments, and by his account, they sounded terrible.

If you’re one of the best guitarists in the world, and tools don’t matter, how could a guitar and amplifier make you sound terrible?

Choosing Tools as Creative Constraints

The answer in Tom’s case is that he has deliberately chosen his tools as his constraints. Tom’s sounds are unique to his tools, built through their limitations. Those constraints are what have determined his creative boundaries and possibilities.

Tom made a bold choice early on, deciding not to fiddle with settings on his amplifier, chasing the “perfect” tone.

Instead, he’s got a few specific guitar pedals, and importantly, a killswitch (which lets him mute with a press) built into his guitars that he’s decided as the constraints of what will shape his sound.

Early on, he decided to stop bouncing back and forth between tweaking and optimizing tools, and instead focused on what was possible using a deliberate, static set of tools. He dialed in a specific setting for his amplifier, and left it at that.

By minimizing his toolset, he determined the boundaries he’d explore within his creative world.

Tools Shape Creative Possibilities

I’ve since become increasingly convinced that a few deliberately selected tools as constraints, pushed to mastery, is what pushes people into creative breakthroughs and outlier performance.

And again, developers specifically have wildly different, deeply held beliefs about all of their tools.

These beliefs about tools are often in conflict with other, competent developers. A given tool is seen as either terrible or great, depending on the person.

With Python, I feel as though I’m supposed to explore my way to a solution. Rather than understand an entire problem space on a first go. I feel as though I can stumble along, and discover what my data structures should be as I write.

Python allows me to create a rough sketch for what my program should do, and iterate my way to an understanding of the solution.

But importantly, very little of the code I’m writing nowadays lives in any kind of production systems with tight requirements for performance or collaboration.

Someone who is working in a different problem space, with different constraints might find my tools quite terrible, or even impossible for the job.

Tool Switching Has a Deceptively High Cost (and we’re doing it all the time)

What has only recently become apparent to me is how often we developers are expected to substantially change our tools and processes. Tom Morello’s thousands of hours with his limited tool set empowered him to create his own sound of excellence for his chosen tools.

It seems every new engineering role comes with a new build process, release methods, and methods of working.

And those jobs we’re usually working within legacy systems, attempting to navigate our way around an old set of constraints, while introducing new constraints closer to the ways we think we’ll be most effective.

The way people are gated for these roles is usually via a coding challenge, in an interactive notebook, with minimal context. (We’re expected to solve a problem with an algorithm we’ve got memorized on the spot.)

Of course, the distance to the role itself has been a topic of debate, and the transferable nature of the work doubly so.

But what of the tools of the role? What about that specific knowledge?

The Musician and the Music

There is a difference between being able to play a piece of music, and being able to write one.

Some people achieve technical proficiency at playing music, without the context for writing their own. They master the restatement, but none of the creation.

What is the role we’re optimizing for? Is it obedience and adherence to the planning? Or is it something else?

Ideally, a person is capable of building the music to be played. Creating new music to be played, writing new things, is the role itself,. And the way you build up context for building new things is by building things.

And in an interview, we should be able to “jam” just like in a musical try out for a band. We’re seeing whether or not we can make music together.

We’re Imprecise When We Talk About and Evaluate Tools

In my current role, I often get the chance to see people experiment with new tech stacks.

And without fail, the people trying out new tech stacks underestimate the secondary knowledge costs associated with changing their stack. Beyond the programming language changes, the secondary knowledge of How the new language’s package manager works, which libraries are the best, what types of build and release process are most effective, and how to debug, all show up and end up destroying productivity.

And when we start paying attention to tools as constraints, it becomes apparent that each software development role we get into truly requires discovering its own@abut set of tools and approaches.

Your tools should narrow the fences of possibility, so you can focus on the immediate problem at hand.

Hypothetically, individual tools are fungible, and with enough talent and time, all of them are interchangeable. You could write great software in Python and Javascript and Rust and everything else. You could spend the time to relearn the intricacies of how Python’s pip, and Node’s NPM, and Rust’s Cargo all behave, how their debuggers work best for you workflow, and everything else.

But to truly break out creatively, you need to close doors aggressively. You need to cut until there is only the right amount of context, and nothing else.

At the very least, be deliberate about the tools you decide to pursue excellence in.