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 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 theses 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 the old days. I hate reading man pages and semi-relevant forums look for answers to questions about how to overcome silly barriers and problems. 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 back 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 participate 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 too far behind.
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.
Source ; http://www.jeffwofford.com/?p=835
