One of the inevitable rites of a passage in a programmer’s education is learning that “changing one small, quick thing” is all too often neither small nor quick.
Early on, those short contained code projects are deceptively reassuring, existing as they do in a magical, self-contained world of no dependencies. Often it’s a syntax error, a dropped closing bracket here or forgotten yet essential semicolon there.
A little further down the developer path, however, and suddenly you’re working with self-referencing scopes in callbacks and closures, and things get just the eensiest bit trickier. Fixing my mistakes — not just what I did wrong, but also learning why what I did try doesn’t work — has been a powerful learning tool. It’s even actually been fun sometimes, but then I’m kind of weirdly masochistic that way.
Recently, however, it seems like I have developed a miserably self-defeating problem-solving approach that involves looking for really complicated reasons why something simple that should be working, simply isn’t. So, yeah, TFW that one supposedly insignificant change brings everything crashing down.
We’ve all been there. I just visited that particular (non)amusement park, fixing a minor bug in a (nearly finished!) small app I’m working on these days. The fix was simple, once I finally saw it, and I was practically salivating at the presumed instant gratification. But of course, everything that had been working promptly broke. Badly. The reason is embarrassingly simple: I forgot all about the workaround I’d pasted in there earlier on to get things to more or less function until I had time to go in and bug stomp.
Unfortunately, it took a really, really long time to figure out this was the case — mainly because I was SO SURE I was right, that my shiny new fix was the perfect solution. And indeed it was, only that forgotten workaround code some twenty lines down was spoiling my one-woman victory party. At first, I thought — I was SO SURE — it was the API. It wasn’t. Then I started looking slant-eyed at the compiler as the culprit. Nope. Hmmm… maybe the OS?
I lost hours looking at all the things that the problem wasn’t, because my own preconceptions were solidly, if invisibly, in the way. Several maddening hours later I was raiding the fridge for caffeinated beverages when it hit me — TAKE OUT THE WORKAROUND, DUMMY. Literally, five minutes after that, everything was working again.
I felt incredibly relieved. And also incredibly stupid. I actually didn’t tell anyone about this (until you, dear reader) because the whole episode was so embarrassing. But then shortly after that, I made a new goof — less critical, different project, but same phenom of looking everywhere for the exotic explanation instead of the simple one right in front of me.
It seems I had inadvertently experienced a programmer’s rite of passage. “Forget the rock star programmer BS. Even the people that you look up to struggle day in and day out,” Tom told me. “The only thing that the majority of senior developers have over juniors is that they have done it many, many more times.”
The takeaway lesson, it seems, is to try to remember to always look for horses instead of zebras.
No, neither of us work at The Maryland Zoo. This is shorthand for the notion created 70 years ago by Dr. Theodore Woodward, professor at the University of Maryland School of Medicine, who instructed his students: “When you hear hoofbeats, think of horses, not zebras.”
Since horses are common in Maryland while zebras not so much, logically one could confidently conclude that the animal making all that racket is most probably a horse. In other words, look for the simplest, most common explanation to a problem first; only after that is ruled out should you look for rarer, more complicated explanations.
It’s not as easy to do as it sounds: research has shown that our brains are actually wired to fight against the simplest explanation. Even the ancient Greeks and Romans recognized this very human tendency, that the “striking and the novel stay longer in the mind” (Rhetoric ad Herennium, circa 85 BC).
So what this means, if you’re a coder rather than a med student or Roman philosopher, is to force your brain back to basics when a bug crawls into your code. It is so, sooo tempting to blame it on the OS. Or the compiler. Third-party tech products are extremely handy as targets for blame. And of course, it’s not impossible that a glitch or an unfortunately timed software update from the outside is to blame when your shite breaks.
Remembering this can save so many headaches and lost hours: If your code is resounding with glitchy hoofbeats, stay away from zebras.
Images courtesy of TripAdvisor.