There’s kind of this unspoken basic training you go through when you start working with code. It’s why there’s this image of programmers drinking energy drinks into the dead of night, surrounded by empty bags of chips – eyes bloodshot and unmoving, half blinded by a single source of pale blue light as the echoes of keyboard keys being tapped by seemingly autonomous fingers fill the room.

It’s when you write your code, you go to run it, and nothing works. Forget fixing bugs, you’re pretty sure this thing shouldn’t even compile. And that’s the worst, at least compile errors give you, you know, errors, but the worst is when you write all your code properly, but apparently you wrote it all wrong. And if you’re one of the people that has to work on some of the less user friendly languages like C (FORTRAN users burst out laughing in the background) then you know just how much of a pain it can be to iron out the issues.

My old professor, Ed, taught me a great mantra. “Test, don’t guess.” I’m pretty sure it’s supposed to rhyme but I didn’t have the heart to tell him. That’s back when I was learning assembly and instead of stepping through the debugger, I would try to work out why it didn’t work in my head. He said that you can spend hours trying to figure out why maybe something isn’t working, but at the end of the day you’re going to have to test it anyways, so you might as well just start immediately. And in assembly, that means stepping through every line of code, watching those variables. Step… Step… Step… It was horrible.

But in fact, it ended up saving me a lot of time that I would’ve spent trying to philosophize about my code working in the realm of maybes, making small adjustments and recompiling hoping for a fix. Debugging assembly taught me a valuable new mindset of doing the small, tedious, mind-numbing tasks which you think will take a lot of time, that in reality save you a lot of time and effort. You just have to not be lazy.

With that I like to do my own little thing that, as I like to call, “count your way to victory.” In your respective language of course. Get some test variables and see what the console says at every stage in the code, then you catch what’s wrong a lot faster than guessing what some edits will do to a function and hoping you’re making the right call.

And with that I found myself applying this kind of “disciplined” mindset to other parts of my code, and even my life. That is, take the time to do the tedious to save yourself a lot of headache in the future. Take the time to declare those constants. Take the time to take notes so you don’t forget important information after the meeting. Take the time to read the manual before building that cabinet. Take the time to make sure you’re going to do it right, before you try to do it at all

So thanks, Ed. I still don’t appreciate your insane workload that makes people switch programs, but I appreciate the two lessons that workload taught me. Do the tedious work now to save yourself a lot of work in the future, and never take another one of your classes again if I value sleep.