I usually encounter two classes of bugs on a regular basis. The first is of the form “I think I know where this is” which won’t take long to find. The steps are pretty easy: Figure out how to reproduce it. Set a couple of breakpoints. Add some caveman debugging. Find the problem and fix it. These are my favorite kind of bugs because they’re over and done with quickly, I can get a quick hit of that “you done did good” glow from making a software system better, and then move on to some more interesting problem.

You can find Part 1 of this series here This has happened to everyone. A colleague walks into your space, erases your white board and starts scribbling on it. They say, “Hey, I’ve got this problem, and I wanted to know if you could help me with it,” followed by five minutes of boxes and circles and arrows. And then comes, “Oh yeah, I see the problem! Thanks!” They walk out, and you haven’t even said a word.

You can find Part 2 of this series here Im told Im a pretty good debugger. Friends come to me to help solve software problems. And occasionally it works. But what is a good debugger? What is debugging? Making software run better? Reducing the entropy of the universe? We all know what “Debugging” is because we all do it, but it’s still an interesting question. You could think of debugging in the same way as adding new features to software – you’re just taking this program from one state to another, like it’s a great big state machine.

Last week I walked through finding and fixing My Favorite Bug. Observant readers may have noticed a multi-step process outlined by some <H3> tags. Get the Attitude, Do Corrective Maintenance, and so on. What was that? It’s called the Universal Troubleshooting Process. The UTP was invented and copyrighted by Steve Litt in the 90’s. Prior to doing software, Steve used to fix stereo equipment, like when people would bring in tube amps that didn’t work any more.

At the end of last year’s storytelling session, I mentioned that my favorite story 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.” Here it is. The Problem It’s a Wednesday afternoon in 2006. I was just about to call it day when I get a call from the mothership.

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 (virtual) 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.

I’ve talked about stochastic profiling in the past, such as the fairly recent Rock Heads. It’s something I mention when I talk about debugging or performance tuning at various conferences. Interestingly enough, I had a need for it last night because I had stumbled into an often-reported, difficult-to-reproduce problem and wasn’t in a situation to hook up Instruments. What is stochastic profiling? It’s fancy made-up name (but aren’t all names made up?

(Author: Tasha Schroeder) We recently held our second annual Clash of the Coders, a 72-hour app-building marathon where we test our technical prowess and compete for glory. “The winners are dangerously capable,” as Chief Learning Officer Aaron Hillegass says. It was a very tough call, but Raisin’ Elevens was the top team, with a project they named Krëndler. Team members Mark Dalrymple, Gregg Rothmeier and Steve Sparks took home the trophy and some pretty sweet prizes.

I was hanging out on the #macdev IRC channel on Freenode the other day when someone asked a question: “static has different meanings based on the context it is placed in, right?”. Indeed, it has different meaning. And yet it’s the same. Static is a C Koan. An Ice Cream Koan static controls scope, which is the visibility of an entity. It tells the compiler “Here is this thing that I’m using, but don’t let anyone else know about it.

You can find all sorts of interesting and useful stuff in Apple’s header files. Don’t be afraid to explore them. I usually troll through the headers when a new major SDK version comes out (like IOS 7 probably will be this year) to see what’s new. I also use them for API exploration. As always, when in doubt be sure to read the official documentation. Apple’s documentation is good. It’s also voluminous.

One of the realities in programming these days is job mobility. You end up working at different companies on different projects with different people. And they all have different ways of working, individually and with each other. You can focus on the negative (oh my, yet another style guide and work logging procedure) or look for the bright side. I try to focus on the positive, and try to pick up good habits when I’m on a job.

(2024 update: I’m SO happy that source code control, especially git via github, is ubiquitous, and pretty much table-stakes these days. Saving this blogpost to give a bit of historical perspective) If you’re already using source code control, you totally rock. You can skip this posting if you wish, but check out Off-Site Backups before you go. I’ve been a professional software developer (meaning I’ve fooled folks in the paying me money to let me program for them) for the last two three decades or so, and I have always used a source code control system.

Readers of this blog might notice a pattern in my postings. They’re occasionally accompanied by a small program to demonstrate some interesting point. Much of the sample code in Advanced Mac OS X Programming : The Big Nerd Ranch Guide are in a similar form: a small stand-alone program that demonstrates some isolated bit of functionality. I love small little programs. They’re not just a pedagogical tool (even though they’re great for that).

When I’m developing new code, my usual habit is to do a lot of small iterations. That gives me a little bit of success fairly often. I’m not as happy if I have to work for a long time until I can see something appearing on the screen. (plus I enjoy the little dopamine hits every time I get something tiny working) When I’m writing a new NS- or UI-view, I often write a pretty generic -drawRect: so that I ca see that I’m actually drawing something on the screen:

I like warnings. I really do. It reminds me that the compiler loves me and is looking out for me. (OK, the compiler at least tolerates me.) What is a warning? It’s when the compiler notices that you’re doing something that might not be what you really intend. The compiler’s job, ultimately, is to do exactly what you tell it to do. But we’re talking slabs of meat instead of computational machines, we make mistakes.

Update October 2013 – On 64-bit iOS (device and simulator) BOOL is now actually bool, so the sharp corners have thankfully gone away for that platform. For everything else, though… Objective-C is actually a pretty old language, dating back from from the mid eighties. As such, it’s got some sharp corners here and there due to limitations of early C. Today’s sharp corner is BOOL. BOOL seems innocuous enough. It holds a boolean value.

Mike Ash’s recent Friday Q&A about signals mentioned SIGWINCH, the hearing of which always sends me down memory lane. My first professional bug was centered around SIGWINCH. By “professional bug”, I mean a bug that someone paid me actual money to fix during a period of employment. Straight out of college in the early 90’s I went to work for a company called Visix Software, which at the time sold a product called Looking Glass, a file browser much like the Macintosh Finder but for Unix.

(Originally published at Mac Edition) (2024 update: this is mainly here to describe some of the most fun I’ve had with computers, digging into more hardware-level stuff and exercising my C skillZ. Also probably the first long-form blog posts I’ve written. I’ve done little editing outside of what Porruka has already done) Early in the summer of 2003, I was contacted for a small contracting gig involving pulling data off of SCSI DAT tapes that were made from some other unix systems.