logo
logo
Sign in

Who do you blame when good coders do bad things?

avatar
Albert Alley

I remember it like it was yesterday: Me, shaking a laser printer toner cartridge, as jet-black dust spewed from it all over my boss’s office.

It was a disaster. My boss looked slowly from me, to the cartridge, and back. He told me to throw out the cartridge and clean up the mess.
He didn't fire me. Maybe he spared me because I was just trying to help (I thought that I could get a few more prints out the depleted cartridge by shaking it) or maybe he did it because it was my first few months of my very first job out of college, and he knew I needed guidance, not a pink slip.

Cscareerthrowaway567 wasn’t so lucky. The young programmer claimed last week on Reddit that he accidentally blew away his company’s production database. It was his first day on the job, and the documentation he was handed to help him set up his own development environment included credentials for the production database. The developer, who hasn't shared his real name or the name of his company (and hasn't responded to a request for comment) used those credentials, instead of ones generated for him by the system—and then accidentally overwrote the database.

His boss didn’t tell him to clean up the mess. Instead, Cscareerthrowaway567 claims, the CTO canned him on the spot. There was also the threat of legal action.

Virtually everyone who responded in the Reddit thread acknowledged Cscareerthrowaway567’s dumb error, but also, put the blame for the whole fiasco squarely on the shoulders of the company—and that CTO, for putting those credentials in the documentation and for not having adequate backups.

On the one hand, obviously. The CTO's covering his or her own ass for an incredibly stupid mistake.

When I look at this in the context of my own miscalculation, I realize how lucky I was to have such an understanding boss. And why shouldn’t he have been understanding? A toner storm isn't the same as a code error that results in lost thousands of dollars of lost business.

In fact, the difference between a simple mistake made decades ago and one made today in virtually any business is business’s increasing reliance on programming and code, and the razor-thin difference between a solvable error and catastrophe.

More and more people will do as cscareerthrowaway567 did, and go directly from the classroom to the product and development environment. According to the Bureau of Labor Statistics, the growth of computer-related occupations from 2012-to-2014 was outpacing all other occupations by 12%.

Now, marry all that fresh blood with companies that may not be employing the best business practices when it comes to code.

A 2015 survey of 1,300 businesses found that 78% of the surveyed companies run open source code. That’s not surprising. I suspect an even greater percentage rely on some in-house programming. There was, though, a more worrisome finding: More than half the respondents admitted their companies lack formal policies for open source consumption, and only 27% of them “have a formal policy for employee contributions to OSS projects.”

We see evidence of this semi-causal approach to code, development, and system management everywhere. Far from being an apocryphal tale, cscareerthrowaway567’s story is becoming almost commonplace.

Last year, someone recounted deleting his “entire company” with a line of bad code. And earlier this year, a chunk of Amazon’s AWS services went down, taking huge swaths of the Web with it. The culprit? An employee doing a little debugging.

Even though that employee may have cost companies and Amazon millions of dollars, Amazon didn’t indicate that it planned to fire anyone. Instead, AWS implemented new safeguards, and made plans to learn from the event to “improve our availability.”

Is that the right response in an age where a single line of bad code can render Web sites and digital services serving millions of people useless? In the 21st Century, don’t we need management maxims beyond “The buck stops here”?

After all, cscareerthrowaway567 admits in his post that he’s made mistakes before. Even if they weren’t at this job, perhaps cscareerthrowaway567 is prone to them. Obviously, the company should have scrubbed its own documentation of any data information and credentials that could potentially be used to harm the business and backing up is obvious (though often ignored). But shouldn’t this programmer be double-checking his work?

Young programmers, though, are often looking to make a strong first impression. When Mark Zuckerberg founded Facebook, he encouraged developers to move fast and break things. On the blog Firehose, one developer recounted how he was desperate to make a good impression:

I was young and hungry, eager to make a difference at the company I was working for, and prove myself as a contributing team member.

And his company encouraged reckless coding with what sounds like a lack of adequate Quality Assurance testing. Eventually he uploaded bad code, broke a portion of the system and, by his calculation, cost the company $10,000.

Lucky for him, his boss decided it was a teachable moment and the developer kept his job.

He did learn to take a less laissez-faire attitude toward his job, but he also added an odd coda:

But in most cases, we’re not impacting heart surgeries, rocket trajectories, or life-or-death scenarios. A certain level of risk is generally acceptable.

Is it, really?

For More Details:Animated Overview Video

collect
0
avatar
Albert Alley
guide
Zupyak is the world’s largest content marketing community, with over 400 000 members and 3 million articles. Explore and get your content discovered.
Read more