As the saying goes, only poor artisans criticize their tools, or in what amounts to the same thing, better artisans don’t criticize their tools.
And what does that make an artisan who is focused primarily on a particular tool or technique? Perhaps a person more likely to imprecisely answer whatever question we’re not exactly asking.
Morphing problems to meet the requirements of tools is a time-honored practice, and an equally time-honored headache for project stakeholders, who can sometimes feel like the family who wanted their vacation home repainted.
A local contractor was engaged before the season and asked to spruce things up. He immediately set to work, and reported that all would be in readiness when the family appeared for their annual holiday.
And ready it was. As parents and impressionable children arrived for their holiday, they were greeted with the vision of a dichromatic acid trip, their home now resplendent in a basecoat of Federal Safety Orange, overlaid from top to bottom with informational and inspirational sayings in chartreuse – the front door being adorned with “Be Ye Separate” on the left, “There is No Queue Like FIFO” on the right, and of course, “Welcome” on the top.
When the contractor was called and informed that “repainting” entailed limited creative license, he was unmoved. “You’re missing the point. The result is consistent with your request; the craftsmanship is top-notch; and only the most sophisticated tools, techniques, and creativity could have converted your living space into a space of living art.”
To this day, part of me stands with that contractor and says You tell it, brother. But when our tools start looking for problems to solve, or morphing the problems they are supposed to solve, watch out.
Especially when we build up expertise in a particular tool, it’s tempting to use that tool for any problem that comes to hand, whether it’s optimal or not. It’s comfortable, and fast, and seemingly enables our creativity – we can think about the problem at hand, rather than think about the mechanics of tool-based manipulations.
It’s also a deception, with the hidden cost of forcing problems to conform to the confines of what our favorite tool does well. I’ve seen data-transform scripts running to thousands of lines when a better tool would do the same thing in fifty lines; I’ve seen complex visualizations deployed when a simple exploratory analysis would be more transparent; I’ve seen any number of non-linear quantitative models applied to the mystification of all, when a simple linear model would have done as well, if not better.
Learning multiple tools well is the best antidote for this trap. Even by itself it’s a great problem-solving technique, not because we suddenly become all-around experts, but because we gain perspective beyond one mode of problem-solving expression.
Learning multiple tools is a great deal like learning multiple languages, and with many of the same benefits – there is no better way to know our home language than to learn another language, and there is no better way to learn new modes of expression than to learn from other cultures. After the first new tool, the next one will be a lot easier – also like languages.
And you really never do know when that seemingly obscure tool or language will be just the right thing. A couple of times a year I still write and compile an awk script (like perl, awk is famously “write-only,” as no one can actually read that crap).
Personally, I’ve found that the more tools I have in hand – even at a modest level of skill – the more likely I am to identify simple and transparent solutions, as I’m more likely to bring the right tool to the problem, rather than engage in the distorting act of moving my problem to the tool I know best.