{"id":835,"date":"2011-10-14T16:05:19","date_gmt":"2011-10-14T22:05:19","guid":{"rendered":"http:\/\/www.jeffwofford.com\/?p=835"},"modified":"2022-08-19T10:58:51","modified_gmt":"2022-08-19T16:58:51","slug":"a-programmers-greatest-enemy","status":"publish","type":"post","link":"https:\/\/www.jeffwofford.com\/wp\/?p=835","title":{"rendered":"A Programmer\u2019s Greatest Enemy"},"content":{"rendered":"

\"\"A programmer\u2019s greatest enemy is getting stuck<\/em>. A crucial skill in programming\u2014and one that many of my beginning game programming students<\/a> lack\u2014is the ability to recognize when they\u2019re stuck, to get out of being stuck, and to avoid getting stuck in the first place.<\/p>\n

Indeed, it\u2019s a skill I\u2019m still learning myself, although the contexts in which I still get stuck are shrinking with time, study, and experience.<\/p>\n

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\u2014checking email, reading news\u2014anything to avoid what looked to be a tedious round of programming.<\/p>\n

I asked myself what it was I was dreading exactly, and it took me a moment to figure it out. Getting stuck<\/em>, came the answer.<\/p>\n

It wasn\u2019t the debugging that bothered me. Crash bugs don\u2019t 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.<\/p>\n

Ah, but those pesky crash reports. That was the source of the dread. You see, I\u2019ve 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?<\/p>\n

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\u2014no 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 \u201chook it up\u201d? And did I even still have the .dSYM file around?<\/p>\n

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.<\/p>\n

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\u2014but then sometimes these little bureaucratic processes are<\/em> 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.<\/p>\n

Or worse\u2014what if I didn\u2019t have the .dSYM files around any more? How could I use the crash reports without symbols? Maybe they\u2019re buried in the app package? If not, maybe I had a backup of the files on Time Machine somewhere. What if I didn\u2019t have a backup\u2014what if I had to try to interpret the reports by hand, without symbols, using mere memory addresses? Ack! Tedium awaits.<\/p>\n

Now I know all this sounds pitiful. It is. But I\u2019m exposing my morning whinery to illustrate a certain kind of thinking that all programmers wallow in at times.<\/p>\n

In my years of experience as a lead programmer and a teacher of programming, I\u2019ve learned that when a programmer is really<\/em> struggling\u2014when his or her productivity has really sunk to the bottom, and days go by without much getting done\u2014dread<\/em> is usually involved. That programmer is stuck<\/em>. And when a programmer gets stuck frequently, or stays stuck for long, unemployment can\u2019t be far behind.<\/p>\n

\"OriginIn 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\u2014had already moved that way, in fact\u2014and 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.<\/p>\n

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\u2014Tony 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.<\/p>\n

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.<\/p>\n

Only a couple of months later\u2014just a few months into my own career\u2014that programmer got fired. I was shocked, I was horrified\u2014nothing 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\u2014unemployment isn’t a pretty thing.<\/p>\n

“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\u2014real stuck\u2014and he couldn’t get unstuck in time.<\/p>\n

Most stucks<\/em> aren’t as bad as that. Most are half-day or one day affairs\u2014maybe 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<\/em> hurt the soul.<\/p>\n

A programmer\u2019s greatest enemy isn\u2019t 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\u2019s greatest enemy is getting stuck.<\/p>\n

Therefore a crucial step to becoming a better programmer is learning how to avoid getting stuck, to recognize when you\u2019re stuck, and to get unstuck. More on this next time.<\/a><\/p>\n","protected":false},"excerpt":{"rendered":"

A programmer\u2019s greatest enemy is getting stuck. A crucial skill in programming\u2014and one that many of my beginning game programming students lack\u2014is the ability to recognize when they\u2019re stuck, to get out of being stuck, and to avoid getting stuck in the first place. Indeed, it\u2019s a skill I\u2019m still learning myself, although the contexts … <\/p>\n

Continue reading “A Programmer\u2019s Greatest Enemy”<\/span><\/a><\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"jetpack_post_was_ever_published":false,"_jetpack_newsletter_access":"","_jetpack_dont_email_post_to_subs":false,"_jetpack_newsletter_tier_id":0,"_jetpack_memberships_contains_paywalled_content":false,"_jetpack_memberships_contains_paid_content":false,"footnotes":""},"categories":[18,15,17],"tags":[],"class_list":["post-835","post","type-post","status-publish","format-standard","hentry","category-productivity","category-programming","category-thinking"],"jetpack_featured_media_url":"","jetpack_sharing_enabled":true,"_links":{"self":[{"href":"https:\/\/www.jeffwofford.com\/wp\/index.php?rest_route=\/wp\/v2\/posts\/835","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.jeffwofford.com\/wp\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.jeffwofford.com\/wp\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.jeffwofford.com\/wp\/index.php?rest_route=\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/www.jeffwofford.com\/wp\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=835"}],"version-history":[{"count":12,"href":"https:\/\/www.jeffwofford.com\/wp\/index.php?rest_route=\/wp\/v2\/posts\/835\/revisions"}],"predecessor-version":[{"id":1920,"href":"https:\/\/www.jeffwofford.com\/wp\/index.php?rest_route=\/wp\/v2\/posts\/835\/revisions\/1920"}],"wp:attachment":[{"href":"https:\/\/www.jeffwofford.com\/wp\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=835"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.jeffwofford.com\/wp\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=835"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.jeffwofford.com\/wp\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=835"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}