# How to narrow down the source of an error: a step by step guide to good old fashioned manual debugging
You’re stuck. You keep getting an error and you have no idea why. Debugging tools have failed you. Error messages are vague and unhelpful. Ideally your development tools would help you out, but right now they’re just not giving you what you need. Google yields no helpful results. You don’t know how to proceed. Should you quit software development? Should you copy and paste the error message into StackOverflow, forums, Twitter, Slack, Discord, and every other resource you can think of? Not yet! First, let’s find exactly what lines of code are the perpetrators of this crime.
## 1. Verify that you can run your app on a previously working commit
First, you should find out if you can get an old version of your code working. Save your current changes to a branch, then check out the last known working commit. Reinstall your dependencies and clear out anything from your git index if it’s dirty (maybe some leftover files from some work you were doing before that you didn’t want to commit, for example).
Ok, does that work? It should, because modern package managers like npm and yarn both include lockfiles and so you should be installing the exact same versions of your dependencies, and git is pretty good at ensuring that your code is the same as you left it when you committed it.
If it does not work, it’s time to debug your system environment or an external service. Did you change versions of any software recently? Did you change the redirect URI on your OAuth provider endpoint? Did you sign in to a different account in your development tool? Your gut reaction will be to say “no” - you’re frustrated and looking for something external to blame, I know this very well because this is often me. Fight that and take a step back and verify anything that seems relevant. Maybe you updated to a new version of Node, npm, or yarn, or maybe you installed a new version of a CLI tool.
You know at this point that the issue is not with the code in your project, but you may still find the “disassemble and reassemble” section below to be useful to trace it further if you’re not sure where to look.
## 2. Narrow down the specific changes that cause your error
If you were able to get a previously working commit running, then you can pat yourself on the back because your project is working again. It’s comforting to know that at the end of the day you can always go back to this state.
But that is often not so helpful, because presumably you had made some changes that you wanted. So we have two options for how to proceed now: incrementally add or remove changes, or disassemble reassemble. Over time and repeated application, you’ll get an intuition for which situations are best suited for a particular approach. Regardless of the strategy, you should always be able to identify the specific changes that cause the error. You may not understand the root cause, but this information is vital for your next research steps and for getting help or reporting a bug if needed.
This file has been truncated. show original
