I’m not just a developer, I’m also a detective

My relationship to errors and mini guide to debugging

If my years in the automotive industry has taught me one thing, it is to love your deviations.

Photo by Volodymyr Hryshchenko on Unsplash

I went through errors and tried to finish them off as fast as I could, hoping that one day there would be no more errors. That I would be finished. This pursuit led to somewhat of a brief existential crisis, as I reluctantly realized that no matter how many errors I solved, there would always be more. It never ended! When I tried to change my outlook, I discovered that in thinking of the problem as a part of my work, which it very much is, I found peace. I even learned to really enjoy getting to the bottom of the issue, finding the root cause and preventing it from happening again.

When I look back at my learnings and my most formative experiences, it’s not the times when everything has worked seamlessly that I remember, but the times I have run into issues and solved it, both by myself and in a team effort.

I try to bring this outlook with me into coding. And turns out, it’s even more fun when you get instant feedback on if your problem has been solved or not. It’s really the best part of coding, when you have been struggling with a problem for some time and then suddenly you get it to work. You feel on top of the world! Nothing short of a genius. And then you call your mom with the good news, and she confirms you’re indeed a genius.

Well, to be honest, most of the time it’s just an extra parenthesis that has snuck itself into my code (and then I feel equally relieved and stupid). But sometimes, I get stuck on something that cannot be explained simply by crosschecking my variable names, and have to dig deep into the web in search of a solution.

Photo by Danial Igdery on Unsplash

This is how I approach it:

1. First, I check for any obvious errors, such as misspelled words, incorrectly named variables, mismatched upper/lower case letters, missing parenthesis, or unclosed tags.
2. If the issue is related to CSS and styling, I first check that I have not set a fixed width or height somewhere, since this is usually where all my styling errors derive from. My most valuable tool is Chrome Inspector, which allows me to check and modify styling properties in real-time. I can easily turn on/off different properties and see how the site behaves.
3. Log the variables in different steps. My code is usually sprinkled with console logs everywhere. It allows me to check that the data we are recieving at a certain point in the code is the one we are expecting. If it gives you “undefined”, this is a great clue and you know where to dig deeper.
4. Isolate, isolate, isolate! Break out a part of the code and try it out in a sandbox. I have countless sandboxes open where I have put parts of my code through several experiments, just to see what happens if I change this or that. I found that practicing this has really helped take my skills to the next level, because it forces you to look at a piece of code and really understand the components that it consists of. What goes in, what should come out, what happens to the data inside, what is static and what will be changed? Once you understand each component, you can start looking at their interactions.
5. Understand the flow. If you understand the flow of the code, then it’s easier to break the code down into smaller pieces, and to understand where the bug might occur. Then you can iterate through the flow and find out where it stops working. As a lover of flow charts, I usually do this when sketching on a new project. I make a flow chart of what happens in the eyes of the user, and then try to translate it to what the code should do. What should happen when you load the page? What happens when you click on that button? What happens when you submit that form? What information, in what form, is being sent through all these steps?
6. Re-write it. Now you have probably tried a lot and by that gained more knowledge in how your code works. If you have time, take that time to re-write and refactor your code. Sometimes, when trying out different things you will leave out variables and styling that create issues for another part of the code, If you are lucky, you will suddenly find that removing some excess code have solved the problem.
7. Ask for help. A fresh pair of eyes can help if you get stuck. A lot of the times, explaining the error and your code to someone else might even lead you to find the solution by yourself before you can finish your sentence. Post a question on Stack overflow or reach out to your teammates. Maybe someone else has been struggling with the exact same thing you are?
8. And if your friends are unavailable, I always turn to my new bestie ChatGPT. In the last weeks of the bootcamp, I have been asking him daily to explain snippets of code and how he would modify it. This is a good thing to combine with number 4, since I have found that ChatGPT works best with smaller and isolated pieces of code.

Photo by Florian Olivo on Unsplash

If you encounter an error or bug, don’t get discouraged. Instead, take the opportunity to learn from your mistakes. Debugging is an important part of the development process and can help you become a better programmer.

These are my findings from my whopping 7 weeks as a frontend developer, and I’m hoping to continue adding to this list, ultimately becoming a better developer and detective.