The lies of an IT pro

We all tell lies at work. Whether it’s a deadline you know you’re never going to hit, or a promise to yourself that you’ll only have the one cup of coffee, these small untruths can make the working day more bearable, or protect ourselves from something we don’t want to have to face. This is no different for IT pros, whose liberal use of the truth remains as (un)reliable today as it ever was. 

Now, we’re not talking about the kind of lies that could kill an IT pro’s career. Committing fraud, for example, is a no-no. Instead we’re discussing lies that may slip out of your mouth without even realising—some trite platitude that you certainly don’t believe, but will spill anyway. 

Nonsense sayings like, “work smarter, not harder,” or “perception is a reality” are regularly used as a means to help us avoid the truth of a situation: that you may not have a solution to a problem or, even worse, that finding one would mean a great deal of work.  

Now, at the risk of facing strict punishment from the secret society of IT pros, I’m going to shed a light on the types of lies that IT pros tell, why we tell them, and why we might be making manageable problems worse, all on our own.  

You can’t kid a coder 

Of the many fibs IT pros tell, those regarding code and programming are perhaps the most plentiful, and in some cases, embarrassing. 

For one, we may slightly exaggerate our own productivity when it comes to coding. When asked for a time frame, an IT pro’s standard response is “I can code that in a day… two max.” Sadly, this is seldom the case. Shortly after giving this forecast, we typically realise that it may have been ambitious, and that the work we were able to do in that “day… two max” was a dry run—just a temporary fix until we have more time to go back and really nail it.

For some reason, we also seem to tell lies that hinder our own progress. Indeed, the amount of times I’ve found an excuse so that I can skip documenting or developing training is startling—usually, we claim that the code is self-documenting, which gets us off the hook. Failing that, there’s the deeply unlikely assertion that the code is essentially foolproof. Shooting ourselves in the foot is a sensation well known to IT pros partial to the odd white lie. 

Yet, despite these being problems of our own making, we’re then usually surprised and a little irked that end-users complain about being unable to find certain functionality. Thankfully, another white lie is all it takes to console ourselves that this problem will soon be rectified and that an easy solution is just around the corner—usually something along the lines of “the documentation will be written after we release the production version.” Yeah, sure it will. 

As for testing, outright lying doesn’t usually cut it. If an IT pro tells you that during a test, the code ran free of bugs, it’s a mixture of unrealistic optimism and blissful ignorance. 

Sure, it may have run smoothly in the test environment, and that's good enough, right? You tell yourself, and others, that the code is good to go, knowing in your heart of hearts that this is a pretty severe case of misdirection. After all, a test environment is very different than testing under production load, where the pressure is higher and issues will undoubtedly arise, regardless of your flawless test. Still, we can dream, right?  

Backup temptation

Now, as mentioned above, it’s not always a case of IT pros outright lying. A degree of presumption, assumption, and fantasy also plays its part in how we do our jobs, and how we try to make them easier for ourselves. 

Take when we roll out a patch, for example—sometimes, it’s tempting to assume that backups are in place, or that there’s nothing valuable on the system. 

However, this is one of many areas in which lying will quickly come back to bite you. Backups, test restores, disaster recovery, and high availability are so important that a company cannot afford to make assumptions, and IT pros have to be vigilant and disciplined in asking about the state of system backups before any changes are made. If you don’t, you risk data loss. 

Let me take you on a trip down memory lane, in which I personally experienced the dark side of back-up overconfidence. Thirty years ago—at the start of my career—I was upgrading my first customer's ludicrously expensive Toshiba® laptop, when their hard drive died right in front of me. 

Now, back then, restoring the OS and software was an irritating inconvenience, but not technically challenging. Unfortunately, my offer to work to restore this from the customer's backups was met with a searing tirade in which I was deemed an “idiot” (frankly, he could have called me much worse).

He was right—I was an idiot. I hadn't made backups before starting work, and so I couldn't recover what was already lost in the ether. The moral of this little story is that assumptions are a fool’s game, especially in IT. If you ever find yourself lazily thinking that “hey, of course there are backups,” give yourself a shake and consider whether you'd like to be called an idiot, and for it to be correct.

It’s the way of the world that lying is often easier than telling the truth. Sometimes these can be minor fibs that only put more pressure on yourself, or idiotic clichés that have outlived their usefulness. Regardless, it’s useful for IT pros to take a step back and think—is this worth the lie, or should I just tackle the task that I so desperately want to avoid? Often, you’ll find the second option is the one that sings. 

Leon Adato, Head Geek, SolarWinds
Image source: Shutterstock/violetkaipa