Last week I wrote about how J wants to work for the NSA. This weekend, in the middle of the National Cyber League competition, he coded a bubble sort in C in an online IDE called JGrasp. But he ran into an error in his output that he could not figure out.
His array showed extra letters after the sort. I looked through the code and nothing jumped out at me as wrong.
Bing! I had a revelation.
“Do you know what a breakpoint is?” I asked.
He said, “No.”
“Do you know what a debugger is?” I asked.
“No,” he said.
I saw this opportunity and jumped on it. At the conclusion of our meeting I had J install Eclipse on his Windows 7 machine. He got a little stuck installing cygwin on his machine – windows 7 does not come with a c compiler. He had even more trouble setting the path in Eclipse to compile and debug from within the Eclipse IDE.
His shift was just about to end as he set the path to cygwin in Windows. We were not going to have enough time to debug in Eclipse. I pivoted and had him write hello world in notepad, he navigated to the directory on the command line and gcc’d the c file to an executable 5 minutes before his shift ended.
“We’re not going to have enough time to debug in Eclipse today.” I said. “Let’s wait until Wednesday to pick this up again. In the meantime, see what you can learn about setting the path to cygwin in Eclipse and let’s start debugging on Wednesday.”
He agreed and I got up and started walking back to my office.
As I walked I thought about how best to describe the process of debugging to someone who has not used a debugger before. I thought of Mr. Freeze in batman. He has a freeze gun right?
Then I thought of Frozone from the Pixar movie, The Incredibles.
Why am I thinking of these frozen characters so much?”
I thought to myself. Then it hit me. Debugging starts with a breakpoint. A breakpoint stops all program execution. Almost like freezing a bad guy, mid-bad. Or Frozone freezing the policeman in the bank to get away.
When we debug we freeze the program. But we’re not freezing to get away from something. We’re freezing the program so it doesn’t run 10,000,000/second. We can’t see the program run if it’s going so fast. So we leverage tools, like a debugger, to see exactly what the computer is thinking at the place in code that we set the breakpoint.
Looking forward to freezing J’s C program to investigate the internals and catch this bug that is ruining his output.
I remember the first time I stepped into a function. The superpower of forcing the computer to stop. I can’t wait to see his reaction when he learns that this is possible. Looking forward to Wednesday 🙂
David Neely 