Who Ate All the Brown M&Ms??? – InApps 2022

When first we learn to program (Whatever Programming Language), it’s about making new things — that first hello world block of code that actually runs, your first small program, baby web dev’s first “To Do” app. The thing that never gets mentioned is how, once you’re good enough at (Whatever Programming Language) to actually be hirable, you’re not going to get hired to build new stuff. Your job is almost certainly going to involve working within existing, even legacy, codebase(s) on stuff written long, long ago… Or at least before current (Whatever Language), programming standards were in place. Assuming whoever twirled up this bunch of bug-riddled spaghetti in the first place ever read a style guide.

(I’m not even talking about those mysterious cases where a single chunk, or even line, of code appears to do absolutely nothing — yet, if altered by so much as a single whitespace, has the ability to crash and burn an entire application. We’ve all seen this. Ye shall know this Mystery Code by the blast zone of comment field surrounding it, screaming, in all caps, FOR THE LOVE OF ALL THAT IS UNHOLY PLEASE DO NOT TOUCH THIS. Mystery Code is not necessarily bad code. None of us can predict the dependencies that may come to rest upon a simple, say, parse function, and the continual piling of dependencies upon those dependencies, until you find yourself in a programmer’s bizarro hall of mirrors. No idea how you got here, or which way to go, and wanting desperately to smash everything.)

So it was not a happy realization for me to finally figure out that what we should be learning — in school, or boot camp, or at our desks late at night while trying to learn on our own — is not so much how to write code, but how to read it. Which is a related, yet different, skill set.

Particularly when you’re a web developer. These days, thanks to the constant paradigm shifts that reflect the stunning evolution of the web, many low-level developer gigs tend to focus on simply keeping things up and running. This means that, as a junior dev, you are unlikely to write a single line of code in production, unless you count test and batch scripts. Frankly, this is more like software babysitting than software engineering, but it’s also reality for many of us just starting out. So finding ways to parse the work of the coders that came before you becomes an essential survival skill.

At first, learning my way, I didn’t have much to go on. Mainly praying for whomever was in this mess before me to have (a) been a decent coder and (b) also a decent enough human being to have actually documented the code with decent commenting and maybe even naming their variables something that made sense and, you know, related to the actual purpose of the function in question. Slowly, though, I began to pick up on clues that helped me predict the quality (or dire lack thereof) of the code road ahead. Consistency in the code base is a key tell — are things indented the same way throughout, for example, or is it anything goes? How is whitespace treated? Camel case or hyphenation? (Or, god forbid, ignoring case altogether — “I don’t bother because SQL is case-insensitive.”).

They are often small clues, yes, but they point the way to much larger potential problems ahead. You see that level of casual indifference to consistency and commonly accepted programming practices, you can bet that same lack of effort is going to redound in actual programming logic — producing effects that will eventually come back around and bite you in the ass. Big time.

It was hard for me to articulate this theory to other people, even other developers. But then I came across a piece of business advice from Van Halen. Yes, big-haired 1970s/80s supergroup of “Running With The Devil” and super-tight spandex pants fame. It seems that, back in the day, the group was famous for a rider in their concert contracts specifying that their backstage munchies must include a bowl of M&M candies with all of the brown ones removed. At first glance, it seems so rock star diva eccentric, but the oddball request actually served a serious purpose. If the band arrived at a venue to find there were indeed brown M&Ms co-mingling in the bowl, it was a sign that other details — actual, important ones — in their contract likely had been ignored as well. This was their sign to take a deeper look at the logistics for that particular show, and do a down-the-line check on everything from the lighting rigs to the grounding on the amplifiers.

When I heard that, I had to shake my head in admiration. David Lee Roth as ops expert. Eddie Van Halen as QA. Brown M&Ms as a way to assess quickly whether the venue operators were paying attention to detail — because if they weren’t, things could go wrong. Big things like a complete crash, going dark in the middle of the show. Or just small annoyances with sound quality or feedback.

And so it also goes, I realized, in every flavor of programming. Small details like case and consistently using hyphens vs. underscores (ONE OR THE OTHER FOR THE LOVE OF GOD PEOPLE CHOOSE ONE AND STICK TO IT) may not a problem in themselves. What they are, though, is a pretty reliable pointer to the fact that you better be reading this code pretty closely, in search of the actual and important manifestations of the inattentive, even lazy, code that came before. Now excuse me, I’ve got bugs to squash. And brown M&Ms to eat.

Feature photo by Robert Anasch on Unsplash.