Tega Brain, This tutorial was made by the Education Working Group, during the p5.js contributor conference at the Frank-Ratchye Studio for Creative Inquiry, Carnegie Mellon University in May of 2015. The contributors to this tutorial include Jason Alderman Taeyoon Choi and Luisa Pereira

This is a field guide for debugging for everyone—whether you are beginning to code or whether you have been coding for a long time, this guide breaks down the mysterious process of solving problems.

0. Debugging is a Creative Act

At all levels, programmers encounter bugs and will often spend more time debugging than actually programming the application. You can expect to spend a lot of time doing this and so it is important to develop good strategies for identifying and working through bugs as you learn to program in p5.js. A bug is a gap between what you think your system is doing, and what it is actually doing. Clay Shirky aptly describes a bug as "the moment when there is both a technical problem with your code as well as a problem with your mental picture of what is happening in your code." You think you are telling the computer one thing, but it is doing something else. It may also be crashing or throwing errors. In order to close the gap, you must investigate. When you are working on a project, you may play many different roles. You are an architect when designing and planning your program, an engineer when you are developing it. Then you will be an explorer, discovering the problems and errors and testing it in all the situations in which it needs to run. You are trying to find out where it might break. Finally, when debugging you are a detective, trying to figure out how and why things broke. So how can you become a good detective and debug your program? Here are the ten steps that can help you become a good code sleuth.

1. Change Perspectives.

Don't panic. When you encounter a bug that you do not know how to solve, stop, pause and take a deep breath. Stand up, say hi to the dog, take a walk or if it's late go get some sleep. When you are frustrated, tired and upset, you are not in a good frame of mind to learn or solve a problem. To find your errors you will need to change perspectives and become the detective. The goal is to find out what the program IS doing, rather than why it's not doing what it's supposed to. We need to get the computer to show us what it's doing. The clues are in the values of variables and flow of program.

2. Observe the problem

Walk someone through the issue even if they themselves do not know how to program. If no one is around, draft an email explaining what you have done and breaking down what the problem is. You probably won't need to actually send this email as often the act of writing it will help you to locate and identify what you need to do next. Some programmers have even been known to explain their problem to a friendly inanimate object like a rubber ducky. This is also a good time to add comments to your code that tell you exactly what each of your functions is doing. Some coders also print out their code (or a section of it) and go through it line by line, tracing the path of variables and making notes.

3. Before you start...

Before doing anything, save a copy of your code that you can go back to. While debugging you are likely to introduce other problems, break things or accidentally delete good work. You don't want to make bigger bugs in the process of debugging. If you make a mistake or your problem gets more worse, you can always UNDO or revert back to your saved file. You can try version control such as GitHub. Write a list of what you are trying, so you can keep track of what still needs to be checked. Be methodical, it will save you a lot of time in the long run. Only ever change one thing at a time. As you debug, you will be turning parts of your code on and off. Every time you make a change, test your program. If you make multiple changes before testing, you will not know which change has what effect and are likely to break things further.

4. Check the basics

Many bugs end up being very basic mistakes, equivalent to forgetting to plug in the power cord. These mistakes are so obvious they are often invisible. Check the dumb stuff like... Are you editing the file that you are actually running (and not, for example, editing the local file, and looking at a different file on the server)?

Are all of your external files where you think they are?

Are your file dependencies correct?

Are there any typos in your paths?

Check your server? etc.

5. Black boxes

A black box describes any part of your system you do not understand the