The Problem Journal

Dear reader, although I’m sure that every other person who has worked through a bootcamp has written some iteration or another of this very blog, I have learned to understand that repetition is what creates the base for novelty and ingenuity. And, dear reader, if there is nothing new about this blog post please count it as written with earnest intent both that you might be better for it at the end, and that our Doge and Savior Elon Musk might one day invent a time-machine.

The first thing that I should have done throughout this entire bootcamp was to keep a journal of my errors. Dear reader, if you read no further (many of you have probably already stopped), and remember nothing else from this please remember this. Keep a journal of your errors. I started this habit only a month ago, just before I started my final project for this bootcamp, and I have gleaned a few things from this practice that have made me not only a better coder but also, a more mentally stable coder.

Now dear reader, allow me to walk you through the process that I have adopted and which will make your bug hunting, problem solving, and syntax sleuthing lives much more simple and relatively serene.

Let us imagine, for only a moment, that you have made a mistake. You try to execute a piece of code. Traffic red letters fill the screen and for a moment your stomach drops, your heart rate doubles and somewhere in the middle of your back panic crawls up your spine to tell your brain that IT’S BROKEN.

There will come a time where these error messages are not as daunting and will even become quotidian. The first few weeks of learning how to code is not that time.

The first thing you should do is to try to remember the immortal words of Douglass Adams, Don’t Panic. (GIF HERE) Errors are very normal things, and are in fact very helpful because they inform us as to where the error is taking place, what type of error is occurring, and as a result how to fix said error.

Before you do anything else, especially before you try to fix the error, take whatever journal or document that you have chosen to document your errors in, and file this error in. I highly recommend dating the error and then copying what your error is saying to you verbatim.

The first thing that this will accomplish is to familiarize yourself with errors that happen frequently. One of the most common errors is a syntax error, which can arise because of anything from a misplaced comma to a misspelled word.

Once you’ve documented the error, go back to the error in your program and try to figure out what is going on. Usually the error message contain very specific information on where you should be looking. For example, with syntax errors you will be told on what line of code the syntax error is (also how how many characters over it is, it will basically plot your error on an X, Y axis for you in your own code) and will usually provide you with possible solutions to the problem. (Include photo here).

Now set to work debugging your code. This is going to be a slightly different process every time you do it because no two errors are alike, but there are a few tools that will be handy for almost any occasion.

The first and most foundational one for Javascript (and React) is the console.log(). I am ashamed to admit that I spent the first four or so weeks of my bootcamp not actually knowing what console.log() did, which is too long. Console.log() essentially asks the console to tell us what something means to it. You’re asking the console to define and tell you (to log) whatever you put in the parenthesis at the end of console.log(). So if you put in console.log(“test”), it will print out test. If you put in a function it will look to give you the result of that function. In short, it is an identifier.

The second very useful tool is called a debugger. The function of a debugger is to give you a chance to look at what is happening in your code one line at a time. So after you’ve found around where your error is, you can put a debugger into your code and what it will do is actually stop your code from running beyond the point of the debugger and allow you to proceed one single line of code at a time. This is useful because you get to pinpoint exactly where the code is breaking down.

Dear reader, once you’ve found out where your code is breaking down, log the tools you used to find the problem (your console.log(), your debugger, google, and stackoverflow to list off only the most common) in your journal.

Finally, after you’ve figured out how to fix the error in your code, put the solution into your journal. Personally, I created three columns, the first for the error title, the second for the tools used to fix the problem, the third for the error solution, which looks something like this: (INSERT PICTURE).

Dear reader, while on the surface this seems redundant, and as coders we dislike repeating ourselves, that’s one of the biggest reasons we use computers, because they are much better are repeating themselves, it is going to do a few things for you.

The first thing is that this practice will allow you to grow quickly as a coder by making you more comfortable with errors. Coding is problem solving. There are no coders (as far as I know) who flush out deployment ready code on the first try and error handling is just a part of the life. The quicker you can become comfortable with errors, the quicker you can grow as a coder.

The second, and probably more important, function of the journal is that it well show you what the most common errors are. In my few weeks engaging in this practice, the top three errors that I encounter stem from A. Improper syntax (everything from typos to incorrect grammar, using () instead of {} for example). B. Not understanding a concept, essentially, being a coder is just a constant state of learning new things, because of this new concepts are being introduced to you and its unlikely that you’re going to pick everything up all at once and will simply make mistakes because of this. And C. Asking for a piece of information that the program does not have, I.E. “insert thing here” is not found. This is a more specific problem because it hones in on the passage of information between the different moving parts of your program and now need to find a way to get the right piece of information to the right part.

From these three most common mistakes I’ve become a better coder because I’ve become more focused on organizing before I start coding, which as the apps you will work on grow will become increasingly more difficult to accomplish. And to give myself more credit that I originally did. Coding is difficult at first and errors are abundant. Many of them come from small places and from not fully understanding what is actually going on in the code. Learning that is a process and the more time a person spends coding the more apparent it becomes.