One of our cherished stories, at least of one of my cherished stories, is the account of Don Knuth and Doug McIlroy solving the same problem. The problem was
Given a text file and integer k, print the k most common words in the file (and the number of their occurrences) in decreasing frequency.
The TL;DR is that Knuth wrote a 10 page WEB program to solve the problem while McIlroy solved the same problem with a 6 line Unix shell script.
You can imagine the lessons that were drawn but they all omit a crucial bit on context: Knuth was asked to demonstrate literate programming by solving the problem so McIlroy’s solution wasn’t really on-point.
These days whenever the story comes up the usual reaction is to cry foul because of that missing context—here’s a representative example—but I draw a different conclusion and always have. The two solutions represent two ways of approaching a problem: (1) write a program de novo to arrive at a solution or (2) leverage existing software to solve it.
Many of us—me included—tend to reach for Knuth’s solution first and even think of the quick and easy shell solution as cheating. That’s silly, of course. The point is to solve the problem not to write code. Yes, in the particular case of the story, Knuth’s answer was the best one but usually, absent other special circumstances, McIlroy’s is clearly superior. It’s worth remembering that we have tools other than the hammer of writing code and that not every problem is a nail requiring that hammer.