Software and Science of Deduction

I'm a huge mystery buff. Plain and simple, I love them all. I read mystery novels, watch police procedural, you name it. There's something truly awesome about figuring out and solving some puzzle that no one else could solve.

It's surprising how many people I know who work in software development that are the same way. I joke with my students all the time that I love what I do because I get to solve puzzles all day. What we do isn't that much different than what many of pop culture's greatest detectives do, we figure out and trace a problem, determine the cause and act accordingly.

Now, I know usually Sherlock Holmes is trying to find a murderer, and lives hang in the balance. If you don't think that's our job... then you clearly have never gotten a phone call when a production enterprise system crashes. We may not be solving a murder, but I'm pretty sure we are working to prevent one.

That being said, whether it's in academia, or in a professional setting, it really does surprise me how many programmers, both junior and even senior developers don't really know how to debug or trace down a problem correctly. It just surprises me how many people run into an error and throw their hands up.

Here's a word of advice, if you want to go far in this industry... don't do that.

The reason I say that is a simple one. Many of the senior developers and mid level developers I know are very busy. They work in a situation where they have everyone wanting a piece of them. Now I'm not saying that to sound egotistical, it's just a fact. The more you distinguish yourself in this industry, the more people will want your time, just like any career.

So honestly, the best way to earn respect in this industry is to tackle your own problems and learn to debug. Honestly, learning to debug is the most important skill any developer can have. It allows you to quickly identify problems, and impress your colleagues with quick and efficient solutions.

So, here are my tips for learning to debug better.

Tip #1) Nothing beats boots on the ground (Know what tools you have in the tool box)

This is a pet peeve of mine, and it's something that honestly isn't that difficult but continues to be an issue with many developers of all levels. Visual Studio is a very robust IDE, and it provides many tools for helping to debug errors. At the lowest level there are breakpoints. But even after that, there are traces, logging, the immediate window, etc. All of these tools are designed to help you get a better picture of what's going on.

Learn to use these tools, honestly. It will pay dividends quickly. Knowing how to use the tools that can give you a complete picture of what is going on in your application is the best way to determine the cause of a problem. That and I can't tell you how many times I've had this conversation:

Developer: I've gotten this error..."{Usually a screenshot of the message, or just reading it to me}".

Me: Ok, and what did you find when you stepped into the code?

Developer: {Blank stare}

Honestly, this is infuriating. There, more frustrating, because while I or any other senior developer is receiving this blank stare, here's what we hear.

Developer: I've done absolutely no work to figure out this problem... why aren't you handing me the answer.... Give me the answer, I can't work for this.

Now I'm exaggerating a bit, but honestly it's frustrating, because we do feel like you are expecting all answers to be given to you. Know the tools and do your research.

Tip #2) Take a good hard look at your victim (Read the error message, and I mean REALLY read it.)

This seems like a no brainer, but again, you'd be surprised how many times I've been brought a runtime error, where it blatantly says the cause in the message. Usually, this is because the developer who ran into the error just saw it and brought it to my attention. When you get an error, don't look at it as something preventing you from doing your job. Runtime or syntax errors aren't roadblocks to you doing your job that a Senior Developer or Manager needs to remove. THEY ARE PART OF YOUR JOB! Honestly, look at them as a learning opportunity. A chance to see why what you were doing doesn't work. Or a chance to get a little better handle on the .NET Framework, or the platform you are working with.

Tip #3) Check the scene for clues

Much like Sherlock Holmes, when you arrive at the scene, you've already got a wealth of tools at your disposal, and you've already taken a good long hard look at your victim, so now it's time to leverage the most important tool in your arsenal... your mind.

Start looking around the part of the application that is failing to determine the cause of the error. Start asking yourself questions and looking around the offending line of code for potential reasons for failure. For example, I would look for some of the following cases:

• Are there any recent changes to the code? Is this a case where it was working up and until today and now it started failing... if so, then it was something in the changed code.
• What does the stack trace say? The stack trace is like your own personal footprint trail, follow it to see how things failed.
• Are there any bad practices at play? Cases of not checking for null values, or failure to follow coding standards? Usually, these can be signs that code was rushed, meaning there could be a problem.

These are just some of the questions that can be asked, but this gives you a good idea of the types of questions you need to ask. Because they will help to guide you to your solutions.

Tip #4) Identify suspects

At this point, you should have some idea about what's going on, or what the error at least relates to. Compile a list of the possible reasons for the error, and identify what the offending line of code is. Before you can fix the problem, you need to identify the problem. And honestly, knowing what that problem is can bring you a long way to solving it.

Tip #5) Consult other devs

Now I know this seems kinda backward, especially given the lecture I just gave about not wasting time. But here's the difference. At this stage of the game, you at least have something, if you are really running into a wall, there is nothing wrong with soliciting opinions from other developers. In fact, this is a great idea, I just argue that you should know what you are talking about when you have this conversation.

Also, when you feel like you want to play this card, be smart about it. Ask other people at your level in the project, before you start moving upward. If you are a junior developer, then ask other juniors before you go bother the project lead. Odds are the project lead will see you doing this, and then by the time you get to him / her, they will be more willing to help you, as they feel like you exhausted options before you came to them.

Tip #6) When all else fails, pray for a miracle

When all else fails, offer it up to the Google and bing gods. I kid but in all seriousness, there are two constants in this industry.

1. All programmers love to solve problems.
2. Those same programmers love to brag about how they solved problems.

Look at this blog or any other and you'll see why, no question.

Those are my tips to bringing in the art of deduction into software development. If nothing else, I hope this gave you some ideas, and trust me when I say the debugging process is a great way to learn, and a fantastic way to impress people as you work through this industry.