In the interest of honesty, I'll admit it: no one could accuse me of being a fan of The Far Side, a widely-celebrated comic strip authored by Gary Larson. Several close friends have joined countless strangers in collecting every anthology available, but Larson's humor never quite did it for me personally.
Nonetheless I find myself thinking of one particular strip on a regular basis. The strip, called "Cow Tools", depicts a cow in front of a barn, displaying four objects that resemble human tools but have no purpose that a human audience could intuit. The resulting publicity sometimes reputed to have saved Larson's cartooning career, this strip confused and intrigued thousands with the bizarre implements it presents as belonging to a cow that needed to improve its... cow work?
The Wikipedia article on "Cow Tools", by way of the New York Times, gives the strip the dubious honor of "the most loathed Far Side strip ever". Anecdotally, I have to disagree. Every fan of the comic that I know has great admiration for "Cow Tools", seeing it as a pure distillate of the sense of humor fans enjoy. (For what it's worth, Larson eventually explained the strip. Kind of.)
My own admiration for "Cow Tools" comes from the fact that these tools are laid out before us by a cow who presumably created them - or at least found them necessary. The cow's face bears an indifferent expression, showing no interest in convincing us of the utility of its tools. To the cow, each tool has some obvious purpose, but if you or I attempted to use one, we would almost certainly do so incorrectly.
We all know the saying: "If at first you don't succeed: try, try again. If still you don't succeed, maybe read the instructions."
No one puts this wisdom into practice with quite as much dedication as software developers. Few of us have ever met a problem we wouldn't like to solve all by ourselves, maybe even before the heat death of the universe. But let me ask you: is a tool a kind of problem?
Many of us sure seem to act like it is. We attempt to solve our tools by (mis)using them in ways their designers would find baffling. We run emacs in vi mode. We make Windows behave like OS X. We give potential colleagues interview questions for which they write code that forces asynchronous programs to execute synchronously!
Maybe I digressed a bit with my last example. That one's for the therapist. The point is: we often only do half the work of using tools. We bring tools to our problems without bringing our problems to our tools.
This approach is so common that even the most powerful libraries for the most complex problems have to have some kind of "quickstart" guide. Sure, we happily pull in utilities provided by others, hoping to make use of their most elegant abstractions. Sometimes we do this too happily. But even as we make use of their solutions, we often fail to engage with them in terms of their conception of the problem, instead imposing our own.
The inventors from whom we receive these tools often acknowledge their work, almost proudly, as "opinionated". The fact that they are "opinionated" implies that those "opinions" are encoded in the tool, defining the perspective from which they approach the task we ask them to help us perform. Usually, creators graciously offer to explain those opinions, and as a matter of course, we stop listening before they even offer.
Thankfully most of us can afford the resulting technical debt. After all, we are not moving directly from "quickstart" to doing neurosurgery - at least, most of us aren't! But even affordable debt is debt: it costs more than paying up front, and when it's avoidable it's unnecessary.
We often approach our tools, no matter how expensive, as obstacles. We say "thanks for this screwdriver" and immediately use it to mistreat a nail.
Why? It's not like we don't have any screws available.
Simply put: we were already holding the nail.
What if we took a step back and asked if maybe we should use a screw instead?