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 better with practice, and over time that developed greatness will translate to your output, regardless of the current set of tools you work with.
Some 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 used 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 make sounds just like the musicians I grew up with! As an unbelievable bonus 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 Can’t Be the Best without Their 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, having been the lead guitarist in Rage Against the Machine and Audioslave.
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 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, how is this possible? If mastery matters most, and tools don’t really matter, how could a guitar and amplifier make the best sound terrible?
Tools as Creative Constraints
The answer in Tom’s case is that he has deliberately chosen his specific tools as his unique 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 his guitar signal entirely with a momentary press) built into his guitars that he’s decided as the constraints of what will shape his sound.
As he progressed in his musical career, Tom 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 (which was a good amplifier!), and left it at that.
By minimizing his toolset, he determined the boundaries he’d explore within his creative world.
Tools Shape Our Potential
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 here, 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.
As an example, with Python, I feel as though I’m supposed to stumble my way to a solution. Rather than understand an entire problem space on a first go, I feel as though I can experiment 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 conversely, 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 do it too often)
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 unique 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 communicating.
And those jobs we’re usually working within the constraints of legacy systems, attempting to navigate our way around an old set of assumptions, while introducing new constraints closer to the ways we think we’ll be most effective, while also steering closer to the upcoming needs of the business.
Worse still, the way people are qualified for these roles is usually via a series of coding challenges, in interview specific editors, with minimal context. The arbitrary nature of these interviews has led to plenty of discussion on their irrelevance.
The Musician and the Music
Notably, there is a difference between being able to play a given piece of music, and being able to write a new one from scratch.
Some people achieve technical proficiency at playing music, without the context or ability for writing their own. They master the restatement, but none of the creation. They can respond to the leetcode challenges, but they can’t navigate discovering the right problem to solve.
And so maybe in a technical interview, we should be able to “jam” just like in a musical try out for a band. We should see whether or not we can make music together as a team.
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, everyone trying out new tech stacks underestimate the secondary knowledge costs associated with changing their stack.
Beyond the programming language syntax, the 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 timelines and estimates.
In the hypothetical, our knowledge of computer science fundamentals should make for an easy transfer across languages. But in practice, those intricacies end up mattering. It takes time to build up knowledge and context and proficiency in any given language.
Let Your Tools Narrow the Solution Space
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 unique set of tools and approaches.
Your tools should narrow the solution space, so you can focus on the immediate problem at hand.
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 a bit more deliberate about the tools you decide to pursue excellence in.