You are probably thinking about how can I speed up if I slow down. I will explain with an example. Let's say you just launched a large project to production. While you are enjoying your success someone mentions that a big bug was found and it is blocking users from being able to use your new product. This project was a large portion of your work life for the past six months and you want it to be successful. You want it to be bug-free (no such thing as bug-free code... maybe that will be a future blog post). You might think you need to dive right into the code and fix the bug, and you would be mostly correct. Your brain may be thinking of all the possible causes of the bug and you want to dive in and correct each of those potential causes. Instead of diving right into the code though, you should instead spend a little time absorbing the problem that users are seeing. Read the bug report, read the steps to reproduce, and absorb the information. Is the bug an actual use case? Are multiple people experiencing the issue? Are there steps to reproduce? Do the steps to reproduce make sense? Just because someone says they found a bug does not mean a bug exists. It could have been a user error. It could have been a bad network connection. It could have been any number of things. This is why you must slow down in order to speed up. You will solve the problem much quicker if you spend a little time going over all of the available information. After you have spent some time going over the information and confirming it is in fact a bug then you can dive into the code to find the root cause. If I hear there is a bug in a project I worked on, my first instinct is to find the bad code and fix the problem as quickly as possible, but that first instinct might make it take longer to solve. Unless you are working on life-saving medical equipment I doubt your app is life or death. If you take your car to a mechanic because the engine is making a sound you would not expect them to just replace the engine. You would hope they would listen to what you say about the issue, investigate the issue, and determine what, if anything, needs to be done to solve the problem. Slowing down your brain is difficult when you hear there is a blocker production bug, but it can be the best thing to do. A couple of the things I do to attempt to slow down is to take a few deep breaths and make sure my debugging environment is set up, such as having a database client open, my IDE/text editor of choice open, and the bug report visible. I may even put on some calming music or background noise. The next time you find yourself rushing to solve all of the problems as fast as you humanly can try slowing down and studying the issue.