Debugging Mindset
"Debugging is like being the detective in a crime movie where you are also the murderer." ~ Filipe Fortes
"Practice doesn't make perfect, it makes improvement! Keep improving."
Links:

Steps to think when debugging and coding
-
Acknowledging, understanding your mistakes, and that no one is perfect.
-
Read your error messages, and say out loud what the error is telling you.
-
READ DOCUMENTATION carefully.
-
Console log (or Print) to view what is going on with your code.
-
Think of the simplest ways of handling challenges.
-
Break down your problem into the smallest tasks possible.
-
SPELLING SPELLING SPELLING is essential; some of the biggest mistakes are caused by spelling errors. The same goes for Case Sensitivity.
Apple
is not the same as
apple
Apple
is not the same as
Aple
-
Pseudo code: Pseudocode, or structured English, allows a programmer to use English-like sentences to write an explanation of what a program is supposed to do. A.K.A writing out instructions on how your code is supposed to work in detail and in your own words.
-
Plan it out! Draw it out! Break everything down into the smallest pieces possible to make things easier on yourself when building.
-
Breathe!
-
Rubber Duckie. The rubber duckie is having either a person or an object that you can explain your code to see where your error might be. https://en.wikipedia.org/wiki/Rubber_duck_debugging
-
Point and say: The shisa kanko (指差喚呼) method is where you point and say what you are about to accomplish. Reading your code aloud (in detail, line by line) helps show yourself where you might have gone off the rails. https://en.wikipedia.org/wiki/Pointing_and_calling
-
Manage your time wisely; you can end up in tunnel vision. It's another piece of stepping back from code to be able to go further in code.
-
Take notes. Creating a snippet library of code you know that works will help when it comes to building. Also, going back through your notes and finding more ways to update the code will help with your development.
-
What you think vs. What it is. Going through code, there are moments where you think something happens a certain way but happens in a different way altogether. For example:
- Location: Where you are placing variables, pulling elements and triggering functions think about the location of where you are actually doing the calling of them.
- Objects (dictionary), arrays (lists), string, or integer? A gotcha moment is figuring out what you are using. Ask yourself, is it an object (dictionary), array (lists), string, or integer? We ask this because one huge bug-causing moment is treating what we are working with incorrectly, leading to error messages.
- Name of variables: You could have a variable declared in one spot thinking you have used it for a certain but, but end up inserting a different variable instead of the one you needed, which causes chaos down the line.
- Wrapping: Checking where you wrap your elements in html:
HTML:
<body>
<div>
</body>
</div>
<!-- watch out where and what you are wrapping --!>
Python:
#Make a function that prints out the argument to the console log
apple = "Something completely else"
def thePrinter(insertData):
print(apple) # this is the wrong variable
thePrinter("The should print out")
Javascript
//Make a function that prints out the argument to the console log
let apple = "Something completely else"
function thePrinter(insertData){
console.log(apple) // this is the wrong variable
}
thePrinter("The should print out")
Ask yourself some of these questions:
- What do I need to do?
- What am I looking at?
- What am I doing?
- What am I supposed to do?
- What is the smallest instruction that I need to do?
- Did I leave a tag, function or something open?
- What data do I need to pull?
- Am I using the correct tags/syntax?
- Am I spelling the tags/syntax correctly?
- What and where am I storing my data?
- How much do I need to pull?
- Am I actually pulling the right thing?
Mindset tools:
Programming allows you to think about thinking, and while debugging you learn learning. ~ Nicholas Negroponte
When dealing with debugging, there are some mindset tools to help visualize your problems:
-
Remember, your errors are not permanent failures or make you a terrible programmer but are learning processes.
-
There are different ways to get to the same solution.
-
Sleeping and allowing your body to rest are important tools in debugging.
-
Don’t compare yourself to others. We all struggle when it comes to code. We all have a unique way of going about coding.
-
In a couple of months, no one knows everything about coding; don't expect yourself to know everything.
-
Sometimes understanding "why" will not happen quickly, sometimes it can take days, months, and even years to understand why certain things happen in code. Repeating code over time will help you to start to understand it. So don't stress yourself if you don't get it at first.
-
Senior Devs are developers who experienced more error messages than you. So be prepared for a life filled with error messages. Your code will never always be perfect but can be worked towards something incredible.
-
There will be tears. There will be moments where you want to cry, so let those tears flow.
-
Take a break. If things are stressful, take a break; when you haven't eaten anything, take a break.
-
Allow yourself to be a mad scientist. When the questions come of wondering what will happen, don't stop on, just wonder. Test out the theory and document the outcome.
-
Along with the mad scientist, keep building projects (outside of Udemy/Youtube courses) to help you understand coding.
-
Telling yourself that you are terrible keeps you in a repeated mindset that you will be terrible. You will be more likely to sabotage yourself to stay in that mindset.
-
Be proud and embrace the errors. Seeing errors, not as the end of the world but a moment in code, helps bring the stress level down some to be able to focus. Also, you now know how to work through that error when it shows up again.
-
Maya Angelou Quote: If you don't like something, change it. If you can't change it, change your attitude. Don't complain.
-
You are not your code; you just built some small wonky code.
-
You are not a machine, and no one expects you to be one.
-
Always study, keep learning and keep going. Never settle. There's a reason why things constantly update!
-
I don't know vs. I haven't grasped it yet. It's a part of the growth mindset. Your mind is in constant change, especially when learning. Just like plants, we need certain things for growth, and when it comes to learning, what you say can determine how you grow.
- Growth Mindset Cliffnotes youtube version:
- Understanding mindset: https://www.understood.org/articles/en/growth-mindset
- Growth Mindset youtube: