8 Common Mistakes That Get Developers Fired

He’s at work and he’s looking at porn.

A tech employee, who I’ll call Alan, was watching anime porn at work. Not satisfied with simply watching it, he decided it was time to start printing his porn — on a color laser printer, no less.

He printed it on transparencies which, as it turns out, weren’t compatible with the laser printer.

They melted inside the printer.

Alan has just ruined a very expensive new printer. Then to make matters worse, he takes the printer apart in a misguided attempt to try and fix things himself. He’s voided the warranty.

After he was told specifically not to.

Naturally, He Was Fired for His Mistake

But it wasn’t for any of the mistakes I just mentioned. He definitely made a mess of things; he creeped out his co-workers, destroyed company property and cost his employers a lot of money.

He was fired because he lied about it.

Don’t get me wrong: you can absolutely be fired for making these mistakes. Most don’t question it when it happens. You can’t expect to do what our friend “Alan” did here and expect to keep your job.

But that’s the thing. Alan did.

If you’re fired for making these mistakes, it’s typically a smoke screen for something else. That something else is the problem which leads us to the first mistake.

Mistake 1: Using Poor Judgment

Dustin Curtis wrote a blog post, about the American Airlines website, complaining about the poor user interface design.

The last thing Dustin expected was a response.

But that’s what he got. He received an email from a designer at American Airlines. The front-end designer admitted there were some issues to work out.

He explained why creating good design at large companies was a tricky ordeal.

Amazing, right?

Wrong. Another case of bad judgment. As it turns out, American Airlines didn’t want their designer to be open with customers.

They fired their designer.

The designer’s intentions were noble, honorable and admirable. Let’s say American Airlines is at fault. Is he in a position to authorize or provide compensation? Can he actually determine fault?

He needed to ask more questions: was this due to user error? Browser error? Is there a software conflict here?

• Did this open American Airlines up to a lawsuit?
• Would this affect any ongoing legal disputes?
• What causes these problems?
• Was this an admission of guilt?

This designer made an assessment before he had all of the facts.

Using “poor judgment” isn’t about simply making bad decisions. It’s a failure to think about the company you work for as your company. And your co-workers as your people.

When developers approach work this way, it changes their decisions. It’s not just a bad decision. It’s a decision that affects their co-worker’s ability to feed and take care of his family.

Poor judgment comes in many forms.

• Spilling company secrets to the wrong person
• Misusing company property
• Humiliating your co-workers or boss
• Overstepping your bounds

This designer could have asked Dustin more questions about his experience. He could have empathized with Dustin. Instead, he overstepped his bounds.

Mistake 2: Using Dishonesty & Scheming

You’ve probably heard the story. A Nissan app developer was busted copying code from Stack Overflow. The verbatim Stack Overflow showed up in a recent update.

Yikes.

Most developers are honest, hardworking individuals. We work incredibly hard to produce great code. But our industry has a dirty secret.

We copy and paste code from the internet.

We’ve all done it.

We have a deadline to meet and we’re really stressed out. We need a quick and easy way to get things done. So after trolling Stack Overflow or CodePen for a few hours, we find what we’re looking for. A quick copy and paste and we’re on our way.

No-one’s the wiser, right?

Actually, no. As a web professional you know privacy is dead. Our industry is ultra-competitive. Journalists, bloggers, even your co-workers are looking for a story, a way to get ahead.

That angle could be a mistake you’ve made, a momentary lapse in judgment. An innocent, but dishonest mistake could be…

• Copying and pasting or stealing code (plagiarism)
• White lies about people, work or agreements
• Accessing or sharing material you don’t have permission to.
• Using company resources for your own purposes in a misleading way.

Or something else entirely. The mistake doesn’t have to be big either. A tiny mistake is enough to derail your career. When that happens and developers are confronted they make another mistake…

Mistake 3: Using Defensiveness to Relieve Pressure

Three developers at an ad agency had an important deadline to meet. They needed to launch their client’s website in time for a major marketing push.

They failed to meet that deadline.

The scope of the project continued to grow, adding more and more features to their already-tight deadline. Which wasn’t their fault at all.

What was their fault was the fact that they accepted these changes without saying anything, leading to the missed deadline.

As human beings, we’ve all been there. We’re blamed when something goes wrong. We feel attacked so we stand up for ourselves.

Only that’s not what happens.

What actually happens is we see a problem developing. We do nothing. The problem gets worse. We do nothing. Only when we’re hit with a ton of emotional pressure do we decide to act. Which usually means we use blame and excuses to take some of that pressure off, using phrases like:

• “Yes, but…"
• “What about when you…"
• “At least I’m not…"
• “You’re one to talk!"

Going on the offensive and attacking is a clear indication of defensiveness. Once that happens we’ve crossed the line. We’ve made it harder for others to hold us accountable, to have healthy conflict.

At first most people put up with it. They tolerate or ignore it. A pattern of defensiveness creates distance in the relationship, with the developer losing their job when all patience is gone.

Mistake 4: Stonewalling & Blockades

Picture this.

Your company has just won a new client. Your boss asks you to take the lead on this project. The client wants something specific, such as developing a site using Bootstrap. Your co-workers ignore him. They say nothing.

Then, without talking to your boss or the client, they go ahead and use Foundation instead.

Your boss, the client — they’ve just been stonewalled. I’m oversimplifying here but you get the point.

Webster defines stonewalling as:

to refuse or fail to answer questions, to do what has been requested, etc. especially in order to delay or prevent something.

And it’s a practice that’s incredibly common in our industry.

There’s a small segment of the web development community that handles work this way. Boss asks for A, developer gives him B. Ask for advice, get a blank stare in reply.

It’s a passive-aggressive way to bully someone. It can be as simple as ignoring your co-workers or your boss and as subtle as leaving you out of meetings and events.

Let’s say a co-worker did that to you. What would that look like?

• They make eye contact with everyone, except you
• Shaking hands with everyone else except you
• Excluding you from events, get-togethers and meet-ups
• Leaving you out of the communication loop

It’s easy, almost natural to exclude non-engineers. But a pattern of stonewalling slowly erodes relationships. If you’re outed as the cause, you’re the first to go.

Continue reading %8 Common Mistakes That Get Developers Fired%

by Andrew McDermott via SitePoint