Read out your code, aloud, to a rubber duck and explain how it works. Often, we internalize our goal and how we want our code to work, and we lose track of how it's really working and how it should work. Speaking aloud can dispel this discrepancy, but it has to be aloud, otherwise you'll still be in your mental world with your bug.

One of the easiest ways to find some code which is causing an issue is deleting out code and running the program again - if the issue is gone, the deleted code was part of the issue, if it isn't, delete some more and try again. As you hone in on the part of the code that's causing the problem, it makes sense to delete less and less code to get a more accurate idea of which code is buggy.

You can print out variables and their values to the console in javascript, i.e. console.log(...) and with print(...) in python. Often printing out simple statements in areas of your code you're not sure are being reached is an easy way to see if that code is running, like adding a console.log('API result was not empty') to make sure the part of the code with the API result not empty is running. It might feel silly but this is called a sanity check, a simple check of your assumptions.

If there is an error code or error text, search it on StackOverflow or any search engine. Remove any personal information from the error text if necessary, as things like your username will be considered part of the search and result in many fewer results. You may also want to remove your own user input for the same reason.

i.e. if you have the following output

>>> os.opendir('/Users/mngyuan/Downloads/jnches-single-pay-spine-2023-24.pdf')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: module 'os' has no attribute 'opendir'
>>> 

you should search

AttributeError: module 'os' has no attribute 'opendir'

Common mistakes

• cropping screenshots poorly
• unannotated screenshots
• overusing vague words like "not working", "broken"
• failing to provide enough context
• unstructured report

Instead, you should

• Crop screenshots to show all relevant information, not just the error code. Ideally this includes the line of code which throws the error and the visual output on screen if applicable
• Annotate what is happening in each screenshot
• Describe what "not working" means by describing what "working" means, i.e. expected behavior vs actual behavior
• Provide context on the goal that you are trying to achieve and what you have tried
• Clearly structure screenshots, their captions, and body text using newlines, all caps, etc.

An example template of a bug report can be found below:

Operating system:        MacOS 12.6.3
Software:                TouchDesigner Educational 2022.33910
Expected:                Arduino serial communication with TouchDesigner serial CHOP sends numbers to TouchDesigner
Actual:                  Arduino IDE says "Error opening serial port 'COM6'. (Port busy)"
Steps to Reproduce (include screenshots): 
                         Open Arduino IDE
                         Open sketch.ino
                         Open visuals.toe in TouchDesigner
                         In Arduino IDE, Sketch -> Upload
                         arduino_ide.png, touchdesigner.png
Source code (attached):  visuals.toe, sketch.ino