What Programmers Can Learn From Sherlock Holmes

What Programmers Can Learn From Sherlock Holmes

As you, my dear reader, will have undoubtedly deduced by now, I am back on the train to work, back to scouring the 30-cents-a-book isle in our local second-hand shop for readable material, and managed to lay my hands on a most peculiar example of the papery kind: A collection of Sir Arthur Conan Doyle’s The adventures of Sherlock Holmes.

I have since studied it to great detail and realized a certain undeniable congruence to my daily work, findings that I have taken to paper and want to share with you today.

Self-evident truths are not always self-evident to others

This may just be my biggest takeaway so I shall put it to the front: Watson, even though far from an imbecile himself will often times struggle to follow the train of thought that lead to Holmes’ conclusions. Even more: he is by now trained in Holmes’ general approach, but comes to different results and only half the way — does that sound familiar to you?

Have you ever inquired someone for help on a most challenging matter, then found it reduced to a five-minute endeavour at the hands of a skilled expert?

Have you ever tried to do an absent programmer’s daily work, wondering whether it is time to hand in your gun and badge and live a life as a monk?

These roles can change at a moment’s glance, the teacher becoming the apprentice — it’s a wild world of tech and teach out there.

The result can often times tell us the source

In The Red-Headed League Holmes deduces that the tedious, but well-paid job falling into the store owner’s lap can only mean one thing: The criminals wanted him out of the building for several hours at a time.

In conclusion of that he looks at the neighboring buildings, finds a bank and rightfully deduces that a heist must be underway — even narrows the time frame down to Saturday evening knowing the bank will be empty at that point.

Code is very much like that at times, we see an error arise and realize the only logical chain of events that could lead to this result.

I save most of my time when, thanks to me understanding the system I can look at an error and deduce that the logical source can only be located in one of the three systems I maintain. That takes out a lot of guesswork and I can immediately focus on that system and drill down until I get to the source. Sometimes that goes even further where I can tell that an error can not exist unless the underlying data itself is faulty, look at the entry in the database and find it was improperly entered.

Sometimes it helps to bedazzle people

You know how Holmes will often times begin a conversation with clients or other people by telling them things about themselves that confuse them? You will also realize how that establishes both a certain expertize and trust that Holmes might not even need as his results speak for themselves.

Us programmers have the same resource at our finger tips, it is just a press on the Windows key and the letters c-m-d away. Just as most people are wowed by the deductions of Holmes they suffer from terminalophobia and become momentarily confused and awed by your mastery of the machine in front of you — when all you really did was cd into a folder instead of using the mouse to do the same.

Other such small tricks exist in our playbooks and their effects should not be underestimated. They level the playing field and often times shift the discussion to a point where both parties can work together, where your warnings may not fall on completely deaf ears.

Just make sure to do it with the same mix of panache and eloquency Holmes proclaimes his deductions with — or else you lose the benefit and end up being perceived as arrogant.

The power of flexibility

You will find both Holmes and Watson quite flexible, a client’s arrival never once seen as disturbance. In the same vein Watson receives a letter before the start of The Boscombe Valley Mystery that inquires whether he has time to accompany Holmes.
Watson receives it as the breakfast table together with his wife, with only an hour to spare and yet reaches the train in time — proclaiming that he was thankful for his time in Afghanistan that taught him to travel light and have a bag at the ready at all times.

Related  How To Become A True Keyboard Warrior And Stop Using Your Mouse

You will also find that when Lestrade proclaims only him and Holmes can go to see the prisoner (for reasons I did not quite understand) there is nary an issue for neither Holmes nor Watson. The latter just goes about his day, explores the town for a while and ultimately begins to wonder how a head wound on the back seems to contradict the most likely course of events.

In code we need the same, few of my days ever end like I thought they would in the morning. Systems break, people quit, new projects arrive with a deadline that requires a certain urgency on our parts — you name it.

Lestrade is an imbecile

I wager that every developer has at least one Lestrade in their lives, the person who seems so awfully sure of themselves that they don’t listen to reason, will not accept the truth until it hits them in the face — and then act as if the praise belongs to them.

We all have them, but I find Holmes’ approach to the matter admirable. At one point during The Boscombe Valley Mystery he says

Alright, I have given you the chance. Here are your lodgings. Good bye. I shall drop you a line before I leave.

Holmes then drops him off at his hotel to clear the case without him. There is a very Zen acceptance of the other man’s inadequacy in there, of the inevitability of life and how pointless it is to try and change a man who does not want to be changed.

We could all use a bit of that in our lives.

The need to unwind

Both Watson and Holmes display utmost dedication once a new case arises, but you will find them both together in their house on Baker Street with Holmes organizing and cross-referencing his files while Watson is there in a seat, engulfing himself in a book that matches the weather outside.

Another thing that struck me as peculiar is how they will frequently rest until the morning, postpone their actions where modern-day thriller detectives would come knocking at unsuspecting people’s doors in the middle of the night.

There is nothing more to be said or to be done tonight, so hand me over my violin and let us try to forget for half an hour the miserable weather and the still more miserable ways of our fellowmen.
— The Five Orange Pips

I noticed this a while ago on myself with the way I enjoyed ten-hour days even on a routine basis during projects — but twelve hour days gnaw on my patience, put everyone on edge and stop being productive as they could be.

The importance of preparation and data collection

It is a capital mistake to theorize before one has data. Insensibly one begins to twist facts to suit theories, instead of theories to suit facts.

I just wasted five hours last week in the help to search an error where we should have been able to tell the root cause almost immediately — but we lacked one key bit of data that would have made that case obvious. An internal webservice was broken and we tried debugging the server behind that — eventually finding out that this server itself was running fine, but could not connect against a third one due to an invalidated certificate.

This day-long search could have been easily avoided if the error logs had been even remotely useful instead of defaulting to a “html file not found” error. We lacked data, so we had to guess and we guessed totally wrong, wasting time.

Summary: Doyle was probably a disgruntled back-end developer

I hope you enjoyed this post, I had a stupid amount of fun coming up with these similarities. Also I am proud to say that I finished my first book in like three months, finally finding back to my old ways.

And always remember:

There is nothing more deceptive than an obvious fact.
— The Boscombe Valley Mystery

Related

Comments

No Comments Yet!

You can be first to comment this post!

Post Reply