Modal Title
Culture / Software Development

Code n00b: Pay No Attention to the Zebra

Jun 30th, 2017 12:00pm by
Featued image for: Code n00b: Pay No Attention to the Zebra

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.

The deeper you get into JavaScript, or any programming language for that matter, the more likely you are to look for more complicated explanations to simple problems.

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.

This time, though, I happened to mention it to Tom Kraak. Tom taught the front end web development course I took at Betamore, and he works as a software engineer at Oath. Tom understands JavaScript at a level far, far beyond the grasp of most mortals, driven both by his love for the language and an insatiable need to understand not just the how but also the why of things. Fortunately for the rest of us, he’s also terrifically gifted at explaining this knowledge in a direct and accessible way. I think of him as the Qui-Gon Jinn of JavaScript teachers.

Tom is the kind of purist who, when you ask him for help with your code, starts by directing you to first rename all the functions so as to be syntactically correct. So I was really happy when, instead of digging into my faulty logic, he empathized with the experience. In short, he told me, the deeper you get into JavaScript, or any programming language for that matter, the more likely you are to look for more complicated explanations to simple problems.

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.

Chances are excellent, however, that the problem lies a bit closer to hand. As in, my nifty bit o’ problematic JavaScript is incorrectly calling into a library. The library itself? Not broken.

Remembering this can save so many headaches and lost hours: If your code is resounding with glitchy hoofbeats, stay away from zebras.

This photo of Wild Animal Safari is courtesy of TripAdvisor

Images courtesy of TripAdvisor.

Group Created with Sketch.
THE NEW STACK UPDATE A newsletter digest of the week’s most important stories & analyses.