It’s possible to build some pretty nifty applications without having a good understanding of how the code is working. You copy and paste some online examples here, you try random things until one of them works there, and eventually you’ve got a sort of copy-pasted Rube Goldberg machine that basically works even if you’re not entirely sure how.
Eventually, though, something is going to go wrong that cannot be fixed without a decent understanding of what’s going on under the hood. And when that does happen it is scary and stressful and not at all the best time to discover that the plumbing of your code is a deep, impenetrable mystery.
Getting practice understanding your code and fixing problems with it before things like that happen can be incredibly helpful. Unfortunately, the only way to get practice fixing broken code is for your code to break, and broken code doesn’t happen when it’s convenient and you’d like some practice.
Although I think most coding schools have debugging exercises here and there, I have spent a lot of time wishing that we had some better ways to give students more regular practice with debugging.
Recently, I finally got a chance to take the time to sit down and write a tool for debugging practice that I’ve been thinking about making for a while to solve this exact problem.
debug_trainer is a terminal program that breaks your code! Run the break command on a file of your choice and it will introduce a random breaking change into that file (or several changes if you’re feeling adventurous). Then you, the programmer, can put your debugging skills to work and try to find the change that was made.
Let's say you've got a file, my_file.py, that looks like this:
def greet(name):
print("Hello, " + name + "!")
greet("Stacey")
You'd run debug_trainer like this:
> debug_trainer break my_file.py
Breaking my_file.py...
...done!
Good luck debugging! I believe in you! Don't forget to make your program print things out if you don't know what they are. ❤️
And it might, for example, change the file to this (see the error?):
def greet():
print("Hello, " + name + "!")
greet("Stacey")
The changes it can make are all based on common issues I’ve seen students struggle with. It might change the first letter of a variable name from capital to lowercase. It might remove the word ”return” from a return statement in a function. It might rearrange or remove the arguments in a function declaration. Malevolent!
If you get stuck, you can ask debug_trainer to give you some hints with the error-type-hint and line-hint commands. error-type-hint will tell you what kind of change it made (for example, “somewhere in this file, debug_trainer changed the arguments to a function”). line-hint will tell you what line the change was made on. If you get really stuck, you can have it tell you exactly what it did with the explain command.
> debug_trainer error-type-hint my_file.py
HINT: somewhere in this file, debug_trainer changed the arguments to a function.
> debug_trainer line-hint my_file.py
HINT: The line where the change was made was line 1 of the original file.
> debug_trainer explain my_file.py
removed the name argument from greet on line 1 of the original file
And once you’re done, whatever file debug_trainer changed, you can reset it back to it’s working state with the reset command. Then you can do the same thing all over again as many times as you want!
> debug_trainer reset my_file.py
my_file.py has been reset!
I’m pretty excited about debug_trainer and I would love to get feedback, advice, suggestions for additional types of errors or new features, etc. I’d also like to give a special thank you to Dillon Kearns, without whose brilliant tools and examples I would not have been able to write this using my favorite language, Elm.
If you want to try it out yourself, just run
npm install -g debug_trainer
to get started, then run the debug_trainer command to have it list all the commands and how to use them. Or check out the repo here or the npm package page here for more details and usage examples.
And let me know on the issues page if you have any issues or feature requests!
[error image by Gerd Altmann from Pixabay]
Mark is a software developer and teacher. In his work he tries to write decent code, support diversity and social justice in tech, and energetically frown at people who use the word "disruption" more than they use the word "ethical”.
Outside of work, he hikes, attempts to commit to musical instruments, feels feelings about things, and silently guesses who uses Tumblr based on their word and spelling choices.