When I was a younger dev, I could remember seeing these things with lots of words and numbers and dismissing them as garbage. Words… numbers… they didn’t mean anything to me. Keep in mind that I started as a hobbyist who eventually landed in development professionally. The hobbyist didn’t have anyone to really explain things to her. And college… while the theory was okay, the application wasn’t covered well enough for me to make sense of it completely. So these words and numbers… without knowing what they are… it just seemed like the compiler was yelling at me – “YO, DOOFUS! YOU BROKE IT!” Grr….
Words… Numbers… What is this garbage?!?
Before we get into the words and numbers, let’s look at a current situation that brings this garbage back out.
Pushes, pops, and writing data structures from scratch… oh my! Lots of repetitive code – thankfully only for learning about stacks and queues – but it’s easy to get lost in this jungle of semi-colons and parentheses.
The questions I’ve been getting are along the lines of
- Why doesn’t my
push()work? - Why does my
prepend()not look right? - Heads, tails, firsts, lasts…?!? Help!
Then I get either exasperated sighs or the look of “How do I get out of this data structure hell?”
Thankfully, I look forward to teaching them how to work with the debugger. All I ask is for a little patience from them – as I tend to get a little too excited when I get some time in the debugger, and sometimes I wonder if that excitement tries my already on-edge and typically exasperated apprentices.
Bring on the words and numbers!
After setting some breakpoints on some pop() calls, I stepped into the calls to see what’s going on and hopefully sort through their questions.
But when I see repetitive code like the stuff above and also get easily distracted, even I get that feeling of “Which pop() is this? How’d I get here?!? HELP!!!!” Debugging tools to the rescue!
When I get lost in code while in the debugger, I turn to the Call Stack.
Words… words… words… and some numbers… what is this garbage?!?
The Call Stack is your best friend for figuring out how you got to a line of a code. The Call Stack shows the stack of entry points that led to here. These entry points are breadcrumbs – akin to those left behind by Hansel and Gretel. They tell me how I got here and just which pop() I’m looking at. When I’m debugging, I find stack traces – tracing through these steps, from current backwards or sometimes from the beginning to the current point – to be super helpful.
In the above Call Stack, I have this story:
- I started an application – that’s in Program.Main on line 38.
- My application runner then dropped me into an Array Stack Driver workflow, line 35.
- From there, I’m now on a pop() in LinkedListStack on line 41.
The words… those are the the things that tell me my entry points. They tell me the method that called this other method that called the method I’m currently in.
The numbers… those tell me which lines were calling those methods.
What used to be garbage to a younger me has been an extremely helpful tool once the light was shown on it and once I truly understood what it was and how to work with it.
One man’s garbage may actually be that man’s treasure, once you understand what that garbage is. Hopefully, this demystified the “garbage” a little.