Depends. If there's an error message, I tend to skim it over to get the sense of where the problem happened. Then I go back to the code, waste 5 minutes trying to figure out what went wrong, then go, "ok... what does the error actually say"? Once I read and understand the error message (if it isn't too terribly vague), then I can narrow down the issue. I'm a huge believer in logging and my application logs every single database error, along with the SQL statement and parameters/values used.

If it's database related and it's not immediately obvious what a dope I was, I'll copy/paste, or reconstruct the SQL in SSMS and try to narrow it down from there. At that point, if I still can't get it right away, I'll start commenting out certain joins until I can figure out which one was causing the issue. Process of elimination.

If it's front-end code, Chrome debugger or console.log will be my choice. Again, depends on the situation. I have the JavaScript Errors Notifier extension, and that is super helpful to locate errors. Every now and then, Chrome and Firefox are totally fine, but IE encounters the error instead. Say what you will about IE, one thing it is good at is finding tag-related errors that others quite forgivingly skip over (e.g. unclosed tags, misspelled tags, etc.). Those are far and few between for me, but it happens. The Chrome debugger throws those javascript errors, and gets you right to the line that caused the problem much of the time. Of course, that's not the whole story there. Why was that variable undefined, for example? Go through the obvious stuff: did the value get initialized? No? Is it a function parameter? Yes. Did it get passed in from the calling function? Yes. Hmm... time to step through with the debugger or do some console logging.

If it's back-end code, again, it depends. I rarely use a debugger with PHP server code on for a web-application, but every once in a while I do, especially for more complicated stuff. Most of the time, I start putting log debug statements in and watching my log. Sometimes, it's as simple as logging how far the process gets before it errors out. Again, process of elimination. Once that's figured out, the next question is: is it a programming problem or a data problem. Many times, it's a data problem, so dumping objects to the log to inspect the data is useful and often exposes what the problem is.

These methods let me find bugs within just a few minutes 80% of the time. The rest of the time, things might get a bit more involved, especially when I have to delve into a third-party library to figure out what's happening. I had to do that yesterday. Fun times!

I personally have a different approach. I try to be proactive about my workflow.

Debugging when there is an error

IMO If I can't read the error message and understand the issue, I am doing something wrong.

Simplest way to do this is to not be lazy about handling errors/exceptions. I bubble up all my exceptions and errors and if for some strange reason I find a stack trace without a legit handling issue, I check the exception stack trace.

Debugging when there is a business logic mistake

TDD - There is no better tool to never make a business logic mistake. It saves a ton of time in long run. Integration Test Cases - Overall runs should yield expected results.

If for some reason a mistake escapes your notice after these two, put a debugger and inspect values at each level

First step is always a guess, I go through my code, check if I missed anything obvious. And counter checking with my notes on what I wanted to achieve and the process or the method. If I don't get the problem I proceed now to the technical parts, checking and testing conditions, commenting out any line thats not in use, at the same time console.log() of anything Javascript/Node and print or var_dump() on PHP(Yeah am still using it).

I google to check if am missing something, check documentation of the language(This has helped me in getting an indepth knowledge), check on forums, and SO(2nd Last problem)! and lastly post on SO. I also have a team so I share the code and they too help. Mostly, I get my answers in the 1st or second step and in rare occasions in SO.

I mostly run into one of two types of bugs: typing errors (good content, bad formatting) or I'll get to a point in coding where I can't figure out what's going on but what I want to happen isn't happening.

CSS Debugging Questions

• did I spell color with a "u" by accident somewhere? (This one gets non-US english speakers all the time)
• are all my braces } and semicolons ; in the right place?
• is the selector written correctly?
• even if the properties from this rule aren't applying to my element, can I see that the rule itself is finding the right element using browser dev tools?
• If the rule is applying and the properties I want aren't applying, is there another rule that's overriding these properties (and if so, what is ITS selector and where does its stylesheet live in my HTML document relative to where I had previously been adding styles?)

Usually with CSS the problem is that I've been in a rush and typed something incorrectly, incompletely, or that I'm trying to apply styles into a codebase I don't fully know or understand, so I might be unaware of (all of) the rules already applying to the elements I'm trying to style and where those rules are located.

JS Debugging Questions

• did I misplace a bracket ) or brace }?
• if I do alert(), console.log(), or console.dir() on that thing…is it what I think it is?
• if I delete that line and re-type it, is the problem still present (was it a typo I'm not seeing?)
• is it my code failing, or is some feature missing from the browser and my code is OK?
• if I delete or comment out this section, does the rest of the code run (aka: can I isolate the problem)?

JavaScript is harder to debug than CSS since you can do the normal programming things like creating infinite loops and having type errors. I know there are browser tools for debugging JavaScript, but honestly most of the JS I write is the least important JS - it's cosmetic enhancement and extending HTML and CSS, rather than being application code that's doing something important - so usually I can manage to alert() and console.dir() my way through the types of roadblocks I run into as I'm learning!

• Log everything & analyze the results
• Hardcode expected values into functions. Run each function until I find the one which isn't proving expected behavior when given hardcoded values.
• Take out half of the app at a time, look at which half is still working, and know it's the other half which is the problem. Keep doing that until I get to the lines which are causing problems. Obviously this is hard to do with larger apps.

1. For most of the problems while debugging, I mostly read my own code and try to make a sense of what I've written instead of blissfully starting to debug (which wouldn't make sense if you had written wrong code logic). The best way to ensure this is TDD. I've only realised this recently and I've started learning how to simultaneously test code before / while I write it.

2. If everything seems right there, I go for the call stack. But especially for lazy loaded / set values, debugger is the best bet. For example read this conversation and see the mistake I made (also tell me if you understood the last pic a guy posted there, I couldn't figure out if it was a joke, or what the joke was if it was 😅)

3. Good Error Handling in the code. I recently made a small automatic comment syncer component/app for an interview process. While making it, I learnt what good error handling can do for you.

4. Following the point, know what kind of errors can appear generally in the type of application you are making. While having my hands on server side programming for the first time in the above mentioned app, I didn't know what http status codes meant what, what kind of errors are there in Javascript, different kind of errors generally. As a person who identifies themselves as beginner / intermediate or between, this can help save time.

5. For UI bugs, if I know which part of the UI the bug is happening (say it's in hashnode's comment / post markdown editor), I can specifically break on the code that is fiddling (adding a node, changing attributes, subtree modifications) with that part of the UI. It's very similar concept to what Mutation Observer API enables one to do, but for debugging purposes

6. Conditional Debugging — for example a use case could be – only break if an xhr request contains a specific string.

7. To check Unintended Body Overflow

---

PS: This seems like a wonderful resource for error handling in nodejs / javascript. Since I mentioned error handling a lot, it would be worth checking out (I'm yet to)

Some great responses so far and all great methods many of us use or have used when needed. However, debugging goes way beyond writing code. When coding, set yourself up for success by doing the proper planning of your architecture BEFORE you start coding. Pseudo code your logic out on paper or in a the editor. Make sure your code is modular, flows logically, and clear enough so when (not if) you have to come back and read it it is easy to follow the flow and understand. If you can do that you are halfway there!

Next make sure you have a clear understanding of testing methodologies and tools for your language and utilize them. The main thing Ruby has taught me over the years is test test test!

Also, learn your debugger! EVERY modern language has one. To most developers the debugger is an after-though. Take the time to learn it inside and out so you can utilize it to it's fullest.

Learn the other tools of your language. Many language have supplemental tools that let you do things like view/monitor memory or call stacks outside the debugger. Learn and use those tools!

Finally, my personal process for debugging is as follows. First I take a hard look at the error stack to get a clue of the flow to that bit of code that blew up. Usually these are logic errors as my tests usually catch the obvious stuff. So I step through the code with the debugger watching all the variables I need to watch and that usually gives me a clue where to look. At that point it's just a matter of getting your hands dirty digging into the code.

I am probably mostly logging stuff and carefully studying the output. I know automated tests are sort of the "right thing" to do, but it's just not always the best way for me to debug it as I feel I have to make sure the test is testing correctly too then. So manual process.

Depends on the environment I’m using.

First I always try to make a guess. I usually know my code enough to know why it fails. Sometimes, however, it’s not that easy, or I don’t debug my own code.

If I can attach a debugger (like in case of my programs written in C), I just do that immediately. It can show me the stack trace, variable values, and a lot more. If that’s not going to help, nothing will.

If there is no debugger available, I just add some debug log/print statements. That’s much more dirty, especially if reproduction of the bug is time consuming. Still, it’s better than nothing.

And if I can’t find anything, I simply ignore the bug and start working on a different problem. Bugs are careless, and if they see you don’t try to squash them, they will come out in the plain, so whenever you go back squashing them you will have an easy time.

1. My first point of debugging starts from the Error Stacktrace from the exception thrown.
2. I'll dry run the execution flow to check if any logical error
3. If I could not find the issue in step 2 then I'll start step-by-step debugging via IDE/Chrome Debugging Tools.
4. Most likely I'd find the bug in step 3 if not I'll go out for the coffee and comeback and repeat the process