DEV Community

Cover image for A Study in Programming
Christoffer Wallenberg
Christoffer Wallenberg

Posted on

A Study in Programming

A big part of learning programming is about one's way of thinking and building mental models. In this guide, we will look at how we can use Sherlock Holmes' "Science of deducation" as a way of solving various programming problems. You may be wondering why Sherlock Holmes has anything to do with programming? See this as a way of thinking and as an aid when analyzing and solving various programming problems.

Sherlock Holmes' "Science of deducation" consists of three parts Observe, Theorize, Test which are described in more detail below. Please keep in mind is that even if these are made in order, they are also individually good to keep in mind constantly when programming.


Let's start with the first part observe and this quote:

"You see, but you do not observe." Sherlock said. "The distinction is clear."
"For example, you have frequently seen the steps which lead up from the hall to this room."


"How often?"

"Well, some hundreds of times."

"Then how many are there?"

"How many? I do not know."

"Quite so! You have not observed. > And yet you have seen. That is just my point."
"Now, I know that there are > seventeen steps, because I have > both seen and observed."

This conversation between Sherlock and Watson is a good example of how easy it is especially in the beginning when writing your code that you only write without really reflecting on what you do and why. An important part when programming is to continuously reflect on why I write my code like this, what does it do and what do I want to achieve? As an example, you can in Javascript code a event listener over 300 times, but if you do not understand that this is what you do, it does not matter how many times you do it.

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.

The gist of the quote above is that you need to go through the data you have before you can start thinking of a solution to your programming problem. The risk otherwise is that you get a solution that is deficient or does not cover all requirements.

In a new project, start by going through the requirements and all the functionality that should be available, what parts are there? What is the data and what is the expected result / goal?

In an existing project where you have to add functionality, it is important to understand go through the existing code and test around to get an understanding of how the program works before you start on a solution.


After you have gone through all the data and gained an understanding of what to do and what you expect for results, it is time to think about how. Two parts here that are important, to filter out all the data that is unnecessary for the current problem and focus on your problem and avoid any side tracks.

Start by asking yourself the question, what is the least I need to make this work? It is otherwise easy to start thinking about side problems that take focus and risk complicating your main problem.

After you have done that, you can start developing a few different possible solutions. Keep in mind constantly what it is you want to achieve and the data you have when working with a solution.


Now you have a possible solution so now it's time to test it! The important thing here is to apply an analytical and critical mindset when you test and be prepared that the solution may not work och work as you intended. Even Sherlock Holmes did not always succeed on the first try with his theory but he went back, went through all the data and tried to see what he missed and added new pieces to the puzzle. You can apply the same mindset in programming, go through the code step by step and tell yourself what is happening, try to see if you missed something.

This quote by Sherlock fits in very well with programming.

It has long been an axiom of mine that the little things are infinitely the most important.

Armed with this knowledge, try applying this the next time you are going to solve a programming problem.

The Game is Afoot!

Top comments (1)

dhruvgarg79 profile image
Dhruv garg

Really liked this article.