Ode to Console.log()
Being a beginner coder is so much fun. There’s a whole world of knowledge at your fingertips just waiting to be discovered. And the learning process is just intoxicating — if you’re anything like me, you knew you were hooked on coding from the moment you first programmed words to simply display on the page. It’s easy to build that learning momentum quickly, especially if you (again, like me) are learning to code at the breakneck pace of a programming bootcamp. But unfortunately for us beginners, it’s just as easy for all that coding progress to come crashing to a halt when we run into bugs in our code and we don’t know how to move forward.
In time, we’ll certainly build the muscle memory and intuition that’ll help us troubleshoot and debug our code almost automatically. But until then, beginner coders have to deliberately figure out how to get unstuck when our code stops running, And, as I’m sure everyone knows, figuring out how to get unstuck can sometimes be the hardest part to think through.
As a coding learner myself, I’ve found console.log() to be one of the most useful tools in getting myself back up and running with my code after hitting a bug. These experiences and personal tips come from my experience learning vanilla JavaScript and React.js, but I believe that this kind of thinking-yourself-unstuck applies to many different languages. I hope these tips and tricks can help some other beginners out there — feel free to drop me a comment if these helped you, if you’ve already implemented these or other debugging methods in your code, or if you have any suggestions. Thanks for reading!
When I’m first building a project, I console log basically everything. It helps keep me grounded in exactly what’s happening in my code, and it’s my number one tip for beginner coders to apply while debugging. I find that I console log a few different things regularly — contextual messages for myself, variables and other pieces of data, and typeof.
Console.log( ‘contextual messages for yourself’ )
A general helpful tip here is to console log not only pieces of data from your program, but also messages to yourself. I’ve found that console logging little contextual messages for myself really helps me understand exactly how my code is flowing. For example, if you’re building a program that’s flowing through a bunch of different functions and click events, it can be hard to figure out where the issue is coming from when your code breaks. If you give yourself contextual messages, it’ll help you know what’s not broken so you can narrow down the suspects. Here’s an example:
While the first console log above works fine and will get you the data from that actors variable, the second example would be more helpful in a sea of text because you’ve left yourself that note to lend some context and a sense of place. It’s a great example of the kinds of notes I leave myself — it lets you know what data you’re actually seeing in the console log, and it also tells you where it’s passed from. And, since you’ll be deleting these notes as you go along, informal is perfectly fine here.
Console.log( ‘while passing data around’ )
This tip is really similar to the previous one, just taken to the next level. When integrating many different chunks of code — like functions, event handlers, and even if/else statements — I usually start by console logging something inside of each chunk. That way, I can click around and visually confirm that each chunk is doing its part. Before you feel the need to actually build out the functionality of each chunk, this is a good first step because it helps us to understand exactly how we’re going to move from step to step in the code.
For instance, if I’m creating a form and adding some submit action that should occur when the user clicks the submit button, I’d likely first just console log some kind of string on submit. Then, once that’s working, I know that the event listener was in fact added to the correct element (which is easy to mess up as a beginner). At that point, I’m ready to refactor my code so that the event actually triggers the intended function. For a first pass, I’ll probably make the function just console log a string again, to make sure that everything’s working as intended. Then, once that’s confirmed, I’ll actually execute the intended actions.
Here’s another code example, below:
As you can see, I’d choose to simply console log a message when the submit button is clicked, first. Once that’s good, it’s easy to refactor the code so that your handleSubmit function is called instead.
In this case, the input fields of my example form have been adding info to a formData state, so before my handleSubmit function actually does anything with that data, I want to make sure that my state is looking and acting how I planned. So, as you probably have guessed, my first move is to console log that formData state, and once that’s looking good I can move on to my fetch POST to persist what I got from the form.
Console.log( ‘working with iterators’ )
When working with iterators like .map() and .forEach(), console logging each item that you get in the iteration is always a safe place to start your work. It’s always where I start mine! It’s a great first step because it ensures that I’m actually reaching the data that I intended to. Here’s another code example:
As you can see from the comments I added in the code, I’d first just console log each movie item to make sure I know what I’m getting there. Then, once I’m confident that’s actually what I wanted, I can comfortably move on to doing some action with each item.
While this isn’t always necessary for super simple iteration, it’s a great learning tool for beginners, and it can be helpful for advanced beginners when we get into some more complicated nesting. Here, we can see that we’re actually doing that map() iteration inside of another .map(). and there’s also some extra dot notation to get us into the right data level to perform our interior .map() action. With nested data and iterations it can be hard to visualize exactly what data we’re dealing with, which is why console logging is still a great first choice here.
Console.log (‘the typeof operator’)
If you’re not familiar with the typeof operator, here’s a link to the MDN documentation — check it out!
I found the typeof operator to be immensely helpful when I was getting comfortable with vanilla JavaScript and React.js. Wrapping our heads around coding and working with data can be hard since it’s not tangible and not easy to picture, so I found myself console logging the typeof different pieces of data all the time.
I often chose to console log the type of data when I was accessing inner levels of nested data, when passing props between React.js components, even as the result of a fetch. Console logging the item and the typeof the item were incredibly helpful in my imagining where the data was going and what it looked like at any given time. For instance, it’s easy to forget that your array prop is wrapped in an object when passed down to a child component, but console logging both the prop and the typeof the prop can help you see the truth.
Furthermore, I find the typeof operator especially helpful when my code isn’t behaving the way I had anticipated it would. Often, if I console log the item and the typeof the item, I’ll realize that I thought it was an array but it’s actually wrapped in an object, which means array methods won’t work immediately — or I’ll find that my .map() isn’t working because my variable is undefined at the time that the array method is being executed.
While console logging won’t solve all beginner coders’ problems, I believe it’s an incredibly useful tool for all of us learners because it helps to alleviate some of the problems caused by the abstract nature of coding. Namely, it can help us see where we are in our code while it’s running, where things might be breaking down, and it can help us to see all the pieces of data more clearly.
