Debugging is a skill you must employ when writing software and yet requires a uniquely different type of mindset. Software engineering (for most code) is largely process oriented, debugging is often non-linear and looks like it’s intuition oriented. But there process. is My #1 Rule in debugging is: Believe No One. It’s so easy to follow a wrong assumption when you are listening to another developer who has been debugging something to no avail who is sure the “error is in how we do foobar so we just need to change it to encode correctly” or “it’s a race condition in these two things” or “this is the code causing the problem, I just haven’t pinpointed it yet”. How many times have I been bitten spending time down the wrong path because I believed the other person and adopted their assumptions about how code worked or the root cause of the bug? Now, the only question I ask is: “How does this bug present itself?” Give me the root stack trace, the steps to reproduce it, the screenshots of the bug, the logs — however it presents itself. That’s all I want. Then I start with a clean slate, no assumptions. . A stack trace is one of the best things you can have when debugging. It literally tells you which places in the code the error is presenting itself. Yet, it’s surprising to me how many developers ignore the details of the stack trace. Don’t ignore stack traces Start first from the most recent frame and dissect that line of code carefully. Many lines of code are doing more than 1 thing and dealing with more than 1 piece of data. Confirm your assumptions about the code and the data state at that point with a debugger (or printf statements ;)), and compare that against how you believe it work. should Eliminate the possibility the error is in the logic or data in that stack frame (or confirm it), then move up a frame and repeat the process until you are at the root cause of the data or logic causing error. This is where things often go awry with novice debuggers. If you don’t have a clean crash or a stack trace, it’s very tempting to start formulating big theories as to why things are going wrong. This can happen when you are debugging things like performance issues, race conditions, etc. Start with data, not big theories. Examples: “The code is a mess in the CardProcessor module, and because I know it’s used at some point during when I click the button it must be there.” “The reason it’s slow is because writing to disk is slow so it must be where we write the files in the FileWriter package”. The danger here is wasting time going down an incorrect path. How do you know what theories are right and what is wrong? For problems like this, often people ignore valuable tools. You need the tools to give you the data to form good theories. If you are debugging C/C++, you must know how to attach gdb to a core file. If you are debugging a query performance problem, ask someone how the database query analyzer works. If the browser rendering is slow or you think you are leaking memory, use the chrome dev tools to profile. Know your tools. If it’s obvious you don’t have a lot of good data about the cause of the problem, you should be first thinking about how to get that data you formulate theories about root cause. Sometimes instrumentation tools can help, sometimes you must add logging. Again, the first place to start adding logging and instrumentation is where the error is presenting itself, (e.g. if the slowness is when you browse to the /foo page, profile that first). before Often times developers get so hung up on what they think is a problem — they’ve invested hours and hours in going down a path for debugging, . To avoid this, keep your theories as narrow and testable as possible. Start with the most likely first, and test the theory methodically, and eliminate along the way. After spending more than 30 minutes on a problem, asking yourself: am I sure this is really where the bug is? Be prepared to throw away a theory. they must be getting close It can help to bring fresh eyes to a problem — having a well documented bug (and again, your documentation should be focused on and how to reproduce it_,_ not your theories on its root cause) makes it easy to socialize it with other developers. how the problem presents itself is how hackers start their afternoons. We’re a part of the family. We are now and happy to opportunities. Hacker Noon @AMI accepting submissions discuss advertising & sponsorship To learn more, , , or simply, read our about page like/message us on Facebook tweet/DM @HackerNoon. If you enjoyed this story, we recommend reading our and . Until next time, don’t take the realities of the world for granted! latest tech stories trending tech stories
