I love stories. I love telling stories, and I love listening to stories. I learn from stories. I believe that we, as a programming community, don’t tell enough personal stories around the campfire.

Some may think it heresy, some may think “well duh”, but I believe that the programming profession is still really primitive. At the level of stone knives and bear skins . I air quote around the “engineer” part of Software Engineer. We employ voodoo (How many times have you restarted Xcode to fix a Weird Mysterious Problem? And it worked!).

Fundamentally we’re still dealing with punched cards. I can easily imagine taking my Objective-C code and xib file XML, putting them on cards, and feeding them linearly into a room-filling mainframe for compiling and linking. Sure, our card punches are much better than they were before (IDEs with refactoring), but it’s still just productivity increases within an order of magnitude or two. A great deal of software development’s difficulty comes from mapping this linear sequence of the lines of code in our card decks to the complex multidimensional pathways of the machine’s behavior at runtime. Do I have any ideas for making software development better that isn’t just a slightly better card punch? Unfortunately, no. Just grousing.

As an industry, we keep reinventing stuff thinking it’s new. The mouse was introduced in 1968. Code Contracts looks remarkably similar to Design By Contract from the Eiffel language, which I read about in the late 80s from the first edition of Bertrand Meyer’s book Object-Oriented Software Construction. There’s always a new silver bullet. Maybe structured programming, object-oriented programming, 4GLs, functional programming will save us. Functional programming, one of the newest development darlings, can trace its lineage back to the late 50s. What’s old is new again.

I Love To Hear The Story

So, back to the stories. The main way in pre-literate societies to disseminate things like knowledge, culture, and codes of behavior is through an oral tradition. I’ve learned a lot of my interesting esoterica listening to the war stories of other programmers. Everybody has a story about That Bug that took a month to track down and was fixed in a dozen lines of code. My favorite story that I tell with my “Thoughts on Debugging” talk is two programmers fixing a show-stopper bug over 24 hours, with the fix being a two-character change in the source code that resulted in a two-bit change in the compiled program. I’ll tell y’all this story next year. I’m amazed and dismayed that in the current state of software development a two-bit change in a multi-megabyte program could have major repercussions.

My favorite interview question is “Hey, what’s your favorite, or at least, your most interesting bug?” These kinds of stories are fascinating. You can often get an insight into the candidate’s personality and thought processes (and communication skills, too). If nothing else, it’s fun to see an otherwise-introverted nerd totally light up, telling tales of the latest hunt. Outside of an interview situation, these kinds of stories are ways of passing small, but powerful, units of knowledge between members of the same tribe. “Here is a specific thing that cost me some of my life, and here’s what I learned from it.”

I was sitting at a table with Mike Ash once, a long time ago at a conference or an NSCoderNight, and I asked him if he had any good bug stories. He regaled me with a tale involving a pointer assignment to BOOL slicing off the bottom byte and turning a true value into falsehood. That story started my mini-crusade to let the world know about that dark corner of Objective-C. To me, it’s wasteful to burn time on a problem like that. Visualize your most respected programmers. Now imagine what they could accomplish if they didn’t have to spend significant portions of their lives chasing down bugs like “This value is false only if this string pointer is page-aligned.” We can start by informing others, and perhaps eventually the problem will get fixed by those with the power. (Which happened in 64-bit iOS. I don’t presume to take any credit for it, but yay!)

I have a friend, Jeff Szuhay. He was a regular CocoaHead from the group’s inception in Pittsburgh until he had to move out of state for a new job. He decorated his cube with a strand of Christmas blinking lights, but he would only plug them in if he solved a really tough bug or implemented a significant feature. You knew there was an interesting story to be heard if you saw the lights on in Jeff’s cube. I learned a lot about debugging techniques and software design by hearing Jeff’s latest victories. Because most everybody eventually stopped by to hear the story, he was able to communicate “these are issues with our product that we can fix” kinds of ideas that might have otherwise been ignored in blanket email form.

This transfer of little chunklets of knowledge is why I volunteer as a debugger and make myself available whenever I visit a Big Nerd Ranch location. I’ve had the pleasure of going on some pretty wicked bug hunts. When you’re disassembling chunks of Core Data, or having to turn on slow animations in the simulator to even begin tracking down the problem, you know you’re going to learn something when it’s all over.

This is also why I‘ve been writing the occasional blog post. A couple of recent stories are debugging war stories. I’ve got a lot of stories in my head, and it feels good to get them out of there to make room for more.

I totally encourage you to tell your story, either here in the comments, on your blog, or at the table at the next conference or NSCoderNight you go to. What is your Epic Bug? What did you learn from it, and what can the rest of us learn from it too?