#TECH

Sherlock Holmes guide to debugging a program

There is nothing more stimulating than a case where everything goes against you”

-Sherlock Holmes

If Sherlock Holmes was a programmer, he would have said exact same lines for a program with a bug wearing an invisibility cloak.

Debugging a program is one of the most challenging yet exhilarating parts of programming. You have to challenge your perceived notions and every failed attempt brings you a step closer to finding the proverbial “killer”.

Debugging is nothing less than a detective’s work.

You confront your code with clues and you are your own critic. You eliminate the impossible and step by step gather the broken pieces until finally, you know what’s wrong with your code.

Here’s a fun infographic of how Sherlock Holmes would debug a program-

Sherlock Holmes debugging a program

 

 

Investigate the cause of death of the code

It’s a perfectly fine Monday morning when you hear that your code broke down and crashed the server. The client is furious and you’re curious. What happened to the perfect code that you wrote? You obviously have no clue.

Welcome to the crime scene, Sherlock! Put your thinking hat and start investigating.

Look out for clues around you in the log files

Fortunately, developers have access to an incredibly convenient and sly informant which helps them extract every information about their application: the L.O.G.S. Whoever invented logs must have been a big fan of Sherlock Holmes. You just can’t assume that you’ll be able to reproduce the bug, but if you have log files in place, you will have enough evidence to proceed. No wonder, why it is repeatedly said that you need to follow logging best practices if you want to write a clean code.

Treat your IDE as Dr. Watson

Dr. Watson was a pretty badass companion when it came to saving life and grace of Sherlock Holmes. Who do you have by your side?

Your IDE.

So go on, fire away your project in the IDE and get ready for some action!

Recreate the crime scene by putting debugging points

“Data! Data! Data!” he cried impatiently. “I can’t make bricks without clay.” (The Adventure of the Copper Beeches)

You need the evidence to identify what broke the code. Once you have everything in place, prioritize your hitlist and put the most suspected clue at the top. Add a few breakpoints, view the content of the error code descriptions, put a few watches. Recreate the crime scene again and again, until you’ve diagnosed the problem.

Eliminate the impossible with console outputs

Whoever made browsers knew that you would need a helping hand with the errors. Look up in the dictionary and who will know the exact meaning of console- comfort someone at a time of grief or disappointment.

Spot on! The console will provide you with the error type, the location of the error and the line number.

Killer found! Broken server, ahoy!

*drum rolls*

Killer found! Who was it? WHO WAS IT?

Don’t be surprised if after all these efforts you find out that there was a missing semicolon which was throwing this stupid error. Well, atleast now you know that a semicolon is capable of causing catastrophic and unpredictable errors.


You know work is always fun if you think of it as you’re solving a mystery. You might not always get the right answers. But even when you screw up, you’ll learn something new.

Hope you get Sherlock-ed soon!