Sherlock Holmes is the most famous fictional detective ever created, in any medium. Even those who have never read a line of Arthur Conan Doyle’s stories know who Sherlock Holmes is, and many of them are familiar with that oft mis-attributed quote, “Elementary, my dear Watson!”1. I’ve been a fan of Sherlock Holmes since I was about 10 years old, and I’ve read all four novels and all 56 short stories more times than I can count.
It’s been recently though, that I’ve begun to really see a correlation between the thoughts and principles of Holmes, and the work that I do every day. I’ve lately been using a lot of Holmes quotes when I’ve been talking about software development, especially to newer developers. As it turns out, a lot that Holmes has to say has an application in programming, it’s just a matter of interpreting the axioms he used for the detection of crime into something that can be used for a different line of analytical reasoning.
With that in mind, I was thinking over some of my favorite Holmes quotes, and wondering how the rules he talked about might be applied to programming. I came up with the following observations…
When you have eliminated the impossible, that which remains, however improbable, must be the truth.
This is probably Holmes’ most famous accurately attributed quote, (see the note on “Elementary…” below). Be that as it may, far fewer people have actually heard this one, even though it’s repeated in various forms throughout the stories. It’s the one principle that Holmes relied on above all others.
This principle in my own work gives me an approach for tackling problems, particularly bugs or unexplained behavior in a program. In a large enough system, it can be very difficult to know where a problem might lie, or where the next new feature needs to be placed. This basic process of elimination, where you are identifying not what something is, but rather what it definitely is not, is a great way to save time and keep you focused.
Of course, the “elimination of the impossible” is not necessarily easy to do. It requires work to figure out the details and understand what you’re looking at. Everything is “possible” from the perspective of someone that knows nothing about what’s in front of them. That actually brings me to the next axiom:
It is a capital mistake to theorize before you have all the evidence. It biases the judgement.
This is another statement that Holmes made more than once, and yet another axiom he held tightly to. There are a number of instances in the stories where Watson marvels at Holmes’ ability to detach himself completely from his work when he was waiting on new information, or before he’d actually had a chance to gather data. Despite Watson’s impression of this act as a superhuman feat, being able to duplicate it as a software developer is a valuable skill.
There are two immediate applications that I can think of. The first has to do with fixing bugs or correcting problems. The first rule of bug hunting in software development is that you must reproduce the bug. The point of doing so is to allow you to gather information. Attempting to solve the mystery, (that is, to fix the bug), before you have enough information to reach any good conclusions is pointless.
This same principle applies when you’re providing estimates for a task or job too. Even giving a ballpark or a WAG2 is irresponsible and likely to turn out incorrect, until you’ve had a chance to investigate your code and analyze the task that’s been put in front of you. Even if it involves pushing back against the demands made of you, (Holmes had a habit of deliberately turning the conversation towards music or poetry when people pestered him for theories), in the end your estimates will be more accurate if you take the necessary time to gather the information you need.
The principle difficulty in your case lay in the fact of their being too much evidence…What was vital was overlaid and hidden by what was irrelevant…Of all the facts that were presented to us, we had to pick just those which we deemed to be essential.
Information overload is the primary occupational hazard of the software developer. Not only are the systems we work on often large and complex, but for any given challenge or problem, there is a deluge of information, some of it very relevant to what we’re trying to do, some of it completely useless. Finding the right solution for a problem, or the right tool for the job is often a matter of being able to tell, (as quickly as possible), how much of what we’re looking at is truly relevant to what we’re trying to accomplish, and how much of it is just so much noise.
The ability to pick through the noise and find the essential details is a skill that one grows with time. A trend I’ve observed time and again with junior developers is their tendency to make their problems worse, simply because they couldn’t zero in on the one or two small factors, (usually correctable through a simple fix), that were standing in the way of all their progress. Suddenly, they’re up to their ears in stack traces, trying to monkey-patch the ActiveSupport gem, and completely and utterly confused. As you gain experience, you remember some of the pitfalls of running too far down certain rabbit holes, and you learn to look for shortcuts, to find the essential information, and act on only it.
Even without years of experience under your belt though, you can always use Occam’s Razor as a guide. Of course, this isn’t an article about William of Ockham…but Sherlock Holmes found this principle to be important as well, so we find yet another quote from him on the subject:
We balance the probabilities and choose the most likely. It is the scientific use of the imagination…
There are a number of related ideas and sayings in the software development industry that echo either Occam’s Razor or this distillation of it. In a large enough system, even if you’re adhering to the first axiom, (eliminating the impossible), it’s absolutely conceivable, even likely, that you’ll end up with more than one possible explanation. The general rule of thumb in that case is…choose the most obvious or likely possibility.
Another way to sum this idea up is presented brilliantly by the Pragmatic Programmers in this tip. Speaking of the Pragmatic Programmers, that brings me to my final quote:
Mediocrity knows nothing higher than itself, but talent instantly recognizes genius.
I love this quote. It’s probably my favorite Holmes quote, and that’s really the biggest reason I’m including it here. It does have application to software development, but I also think it’s one of the most important as far as “life guidance” goes too.
The ironic thing is that this appeal to humility was spoken by Holmes in a moment that seemed pretty full of conceit. In his comparison, Holmes was calling himself the genius, and a lesser investigator whom he happened to like the “talent”. Be that as it may, I think the sentiment is a valuable one, and it forms one of my personal moral guideposts.
Programming is a field that is full of people smarter than you. I don’t care who might be reading this, (myself included), unless you randomly happen to be the most brilliant person in all of computer science, (and who measures those things?), there is someone in this field that is smarter than you are. Early and open-armed acceptance of that fact will lead you to a happier life as a developer, and as a person because:
Relying upon the work of the smart people that came before us allows us to be free to do our own brilliant work. There is a tendency amongst all programmers, even the really experienced ones, to want to reinvent the wheel every time someone asks for a car. We’re a proud and creative lot, we software engineers, and deep in our soul is the private conviction that we really could do it better than the last guy did. The fact is, we’re probably wrong, and we’ll save time and heartache by re-using the generously offered solution that’s already out there.
There’s another benefit to “recognizing genius”: Learning from it. If you’re convinced that you really can do it better than anyone, and that no one can teach you anything, because you’re already in possession of everything you need to continue blazing your path of glory…well, you’ll stagnate. This was really Holmes’ main point…The talented person wants to be a genius…and will therefore acknowledge and emulate the geniuses they see. The person that’s just so-so is perfectly happy with their mediocrity, because they’ve never bothered to look beyond themselves long enough to realize that there’s a higher plateau to be reached.
Programmers work in an industry full of extremely intelligent, talented people, and we’d be foolish to believe that these people can’t teach us something…the fact is, most are absolutely willing to do it too, hence the proliferation of a million tech and programmer blogs and websites.
So — this are just a few quotes from, and a few thoughts about my all-time favorite fiction. Hopefully, if you’ve worked for me and you hear me randomly quoting Sherlock Holmes, I’ll have pointed you to this article, and you’ll gain a little deeper understanding of what I’m talking about.
For those of you who are wondering, Part 3 in my series on building a chat application in Ruby is well on it’s way and will be available soon.
1. Holmes never actually says this. The closest he comes is from a passage in “The Crooked Man”:
“I see that you are professionally rather busy just now,” said he, glancing very keenly across at me.
“Yes, I’ve had a busy day,” I answered. “It may seem very foolish in your eyes,” I added, “but really I don’t know how you deduced it.”
Holmes chuckled to himself.
“I have the advantage of knowing your habits, my dear Watson,” said he. “When your round is a short one you walk, and when it is a long one you use a hansom. As I perceive that your boots, although used, are by no means dirty, I cannot doubt that you are at present busy enough to justify the hansom.”
“Excellent!” I cried.
“Elementary,” said he.
2. Wild Ass Guess