A programmer’s greatest enemy is getting stuck. A crucial skill in programming—and one that many of my beginning game programming students lack—is the ability to recognize when they’re stuck, to get out of being stuck, and to avoid getting stuck in the first place.

Indeed, it’s a skill I’m still learning myself, although the contexts in which I still get stuck are shrinking with time, study, and experience.

This morning, as I downloaded crash reports from Apple, I realized I was dreading my job today. I started looking for other things to do—checking email, reading news—anything to avoid what looked to be a tedious round of programming.

I asked myself what it was I was dreading exactly, and it took me a moment to figure it out. Getting stuck, came the answer.

It wasn’t the debugging that bothered me. Crash bugs don’t scare me. Usually I find that crashes are easier to fix than more insidious problems like memory leaks or uninitialized variables. With a crash, at least you know where to start looking: right where the crash report says to look.

Ah, but those pesky crash reports. That was the source of the dread. You see, I’ve used crash dumps for debugging before, but never from Apple, and never in Xcode. What would be involved in using these reports? Could I just drop them into Xcode and have them point me to the source code, or would I have to painstakingly read through the report myself and interpret it manually? How helpful would these reports be in directing me to the actual source of the crash?

Part of the problem was that the reports lacked debug symbols. I could see what module caused the crash, but apart from that there was only a byte address—no source file name, no line number. So to use the report properly I would need to find the .dSYM file associated with the version of the app that was causing the crashes, and hook it up (somehow) to the crash report. How would I “hook it up”? And did I even still have the .dSYM file around?

All of these thoughts were mere intuitions, haunting the back of my mind as I browsed the reports. It was only when I stopped and thought about them that I realized: I was dreading programming this morning because I was afraid of getting stuck.

What if the process of symbolicating the crash reports was complex and finnicky? I could spend hours reading man pages and trolling through forums, look for tips on how to symbolicate a report. Sounds ridiculous—but then sometimes these little bureaucratic processes are ridiculous. Ask anyone who tried to get codesigning working for iOS in ye olden days. I hate reading man pages and semi-relevant forums looking for answers to questions about how to overcome silly barriers. I was dreading that.

Or worse—what if I didn’t have the .dSYM files around any more? How could I use the crash reports without symbols? Maybe they’re buried in the app package? If not, maybe I had a backup of the files on Time Machine somewhere. What if I didn’t have a backup—what if I had to try to interpret the reports by hand, without symbols, using mere memory addresses? Ack! Tedium awaits.

Now I know all this sounds pitiful. It is. But I’m exposing my morning whinery to illustrate a certain kind of thinking that all programmers wallow in at times.

In my years of experience as a lead programmer and a teacher of programming, I’ve learned that when a programmer is really struggling—when his or her productivity has really sunk to the bottom, and days go by without much getting done—dread is usually involved. That programmer is stuck. And when a programmer gets stuck frequently, or stays stuck for long, unemployment can’t be far behind.

In my first “real” game programming job, at Origin Systems circa 1995, I befriended a programmer who had been there for years. He was a terribly nice chap, and he was kind to me as a newbie in the games industry. I liked him, but after I had worked there a few weeks, he confessed that he was struggling with his coding. He had been weaned on C, and all this C++ tomfoolery mystified him. The company was moving toward Object Oriented Programming—had already moved that way, in fact—and he was being left behind. Although I was a n00b, I had studied C++ while at college and understood it pretty well. So I explained OOP concepts to him, showed him why C++ really was a better C, and tried to help him modernize.

I didn’t realize it at the time, but it was too little too late. He understood the concepts I taught him. But something had happened to his confidence. He kept showing up to team meetings with new excuses for why he hadn’t made any progress that week. “I had this terrible bug that took a couple of days to track down. It was a killer—Tony helped me with it, you remember that don’t you Tony?” (Tony, looking unconvinced:) “Oh yeah, that was a killer.” “And then I had to go and help the other team get their installer working and then I got sucked into a design meeting they needed me for…” He had all sorts of stories about useful things he had done that week, none of which were getting his assigned programming tasks done.

Since then I’ve seen this a thousand times. Shoot, I’ve done it more times than I’d care to admit. Showing up to progress meetings with beautiful excuses.

Only a couple of months later—just a few months into my own career—that programmer got fired. I was shocked, I was horrified—nothing in business is as scary as the first time you see somebody get the axe. It’s like watching a death. Rational or not, you can’t help but feel you just dodged the bullet yourself. Axes, bullets—unemployment isn’t a pretty thing.

“He wasn’t making progress,” they told me when I asked why they let him go. “He just wasn’t getting things done.” He got stuck—real stuck—and he couldn’t get unstuck in time.

Most stucks aren’t as bad as that. Most are half-day or one day affairs—maybe a few days of avoiding the boss’s searching eye, playing a few too many rounds of Robot Unicorn Attack when you should be coding. But it still stinks to be slinking around at work, not doing the job you (usually) love, just because you can’t figure out how to move forward. Big or small, stucks hurt the soul.

A programmer’s greatest enemy isn’t the tools or the boss or the artists or the design or the legacy code or the third party code or the API or the OS. A programmer’s greatest enemy is getting stuck.

Therefore a crucial step to becoming a better programmer is learning how to avoid getting stuck, to recognize when you’re stuck, and to get unstuck. More on this next time.