There’s an old joke that goes something like this: back in the days of vaudeville, comedy acts were all the rage. This young guy wants to get into the business, but he’s not sure his act is good enough. He knows all the great comedians of the time would put on a gorilla suit, and the audience ate it up. So the first time he goes up in front of an audience, he throws on the suit and prepares to walk out on stage. But right before he gets out there, one of the veteran comedians grabs him, gets in his face, and says, “WHAT DO YOU THINK YOU’RE DOING?!?! You can’t just put on the gorilla suit! You have to EARN it!!”
Scratch the surface of the joke, and you find a surprisingly insightful commentary about professional pride, industry standards, and protecting valuable assets from mis- or overuse.
Here’s what I mean: if you put on a gorilla suit and go on stage, you can do just about anything, and the audience will eat it up. You don’t need much skill or biting wit or superb comic timing. The suit does all the work. So why, you might wonder, WOULDN’T you want newer comics to use it to have a few early, easy successes?
The veteran comedian in the joke understood the downside: sure, it’s a quick win for the newbie, but if every new comic on the scene can just put on the suit, pretty soon it loses its punch. And then the folks who’ve been working the circuit and perfecting their craft no longer have a surefire trick up their sleeve when they need it.
What’s this got to do with IT? I think we have our own “gorilla suits,” and sometimes we fail to recognize how our overreliance on them hurts us in the long run far more than the short-term benefit is worth. When we opt for the IT equivalent of a gorilla suit, we fix the symptom but leave the root cause in place. We also miss out on a valuable opportunity to expand our skills and deepen our understanding of systemic technical issues.
I’ll be the first to admit it—nobody exactly “enjoys” working a problem where the solution isn’t clear or the issue isn’t well understood. But I’ll also be the first to point out those are exactly the situations where I’m most likely to learn something new (or at least new to me), to be forced to create a novel approach, or to connect with someone from the team, company, or even the IT industry at large who I wouldn’t have had a reason or a chance to get to know. These are the moments of growth as an IT practitioner, and a gorilla suit solution stunts these moments.
Here are a few examples of IT “gorilla suit” solutions:
Reboots, Restarts, and Respawns
The famous/infamous “have you tried turning it off and back on again?” applies to anything from rebooting a machine or restarting a service to deleting and rebuilding containers. We do it because it’s quick and, in an unbelievably high percentage of cases, it works. It also destroys all evidence of what was actually wrong, and once the reboot is done, we as the folks responsible for the overall stability of our infrastructure have no better answer as to why it happened or if it’ll happen again. Used sparingly, it’s an effective response. To be blunt, I’ve not met many IT professionals who use this technique sparingly.
vMotion-ing to Greener Pastur... I Mean Hosts
The ability to move a VM (whether manually or auto-magically) from one host to another—and to do so in a way where even users connected to the VM don’t realize it—is nothing short of miraculous (at least to us old fogies who remember the bare-metal-in-a-NOC days). At the same time, overly simplistic vMotion rules do nothing to identify when, where, or why performance issues are occurring. I emphasize the “overly simplistic” part of the last sentence. A robust rule identifying a problem with a “noisy neighbor” or the underlying hardware is the perfect moment to relocate some (or all) of the guests. But once again, I must be blunt and say these robust rules aren’t what I see out in the field most of the time.
Google, Stack Exchange, and the Rest of the Copy-Paste Crew
Of all the gorilla suits I mention here, this is the least egregious. At the very least, having a default response of immediately searching online puts you in contact with a lot of information. SOME of it is relevant, but A LOT of it is likely not, and as tech pros, we have to spend time identifying which solutions fit our particular situation. My issue with people who have a hair trigger when it comes to Google searching is they often haven’t taken the time to fully investigate the issue. “I find a forum post and do whatever it says there” isn’t a troubleshooting technique, nor does this response help develop the problem-solving muscle.
“That Person”
“That person” is often the grizzled IT veteran who seems to have seen it all, done it all, and committed most of it to memory. Going to them seems like the most natural, logical thing in the world. Why spend hours trawling the internet and thrashing around in the NOC if they already know, right? Here’s why: they aren’t your personal frakking Google. The knowledge they possess was likely hard-won through those selfsame hours of thrashing around the NOC and trawling—if not through Google, then through reference manuals, help files, and manual pages. I’m not saying don’t go to them—I’m saying don’t go to them FIRST. Take a minute. Explore. If you do have to hit them up with a question, at least be able to say, “I tried these things; I looked at these references.”
In fact, doing just this—taking the time to talk and think through the issue—is at the heart of what’s come to be known as “
rubber duck debugging". It’s a technique even non-programmers can use. And your duck
can even be a person.
In the past, when I’ve been “that person,” I’ve asked whoever came to me to spend a certain amount of time on the problem first. I did this partly to protect my time and partly to protect the other person’s—surprisingly, in the opposite direction. After one coworker spent two solid weeks trying to noodle through an issue I solved in five minutes (NOT because I’m a genius but because “been there, done that” can show you the scars), I realized they needed help getting past their resistance to asking for help. In this case, I insisted they work on a problem for NO MORE THAN 45 minutes before asking me. During the two weeks my coworker had been single-mindedly focused on solving the problem themselves, I had to cover the work they didn’t get to.
The Mostly Unnecessary Summary
I want to be clear: my suggestion to avoid putting on the gorilla suit too soon (if at all) isn’t meant to be an act of gatekeeping. I’m not trying to control who “gets” to use quick, easy, convenient answers. But the junior comics who put on the gorilla suit early in their career were robbed (they robbed themselves, really) of the chance to learn how to read an audience, develop a solid routine, improve their sense of comic timing, and discover what worked and what didn’t.
In the same spirit, these easy choices keep us from doing the work: investigation, troubleshooting, testing, and learning. This is what allows us to grow as individuals, to develop our skill at determining the root cause of the issue, and to truly fix a problem rather than just end the symptom for a moment.
What are some of the “gorilla suits” in your toolbox? Share them in the comments below—not only to caution folks about using them too soon but to share the quick fixes and amazing tricks you’ve collected over your IT career.
