8 Common Mistakes That Get Developers FiredBy Andrew McDermott
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.
More from this author
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.
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.
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
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.
Mistake 5: Criticism & Contempt
Sarah Sharp, a software engineer at Intel wrote:
Seriously, guys? Is this what we need in order to get improve -stable?
Linus Torvalds is advocating for physical intimidation and violence. Ingo Molnar and Linus are advocating for verbal abuse.
Not *fucking* cool. Violence, whether it be physical intimidation, verbal threats or verbal abuse is not acceptable. Keep it professional on the mailing lists.
Developers are incredibly smart. As a developer you’re trained to think about things abstractly, from top to bottom, beginning to end. It’s an incredibly valuable skill to have and it requires a significant amount of intelligence. But that skill comes with a few downsides.
One of those is elitism.
That elitism is based on the simple fact that often you’re the smartest person in the room. Does that make mean-spirited criticism or contempt okay? Absolutely not.
These kinds of developers love to see their co-workers fail. To prove others wrong, showing they’re smarter or better than everyone else.
They often do it in ways that are brutal, cruel or humiliating. What these developers fail to realize is this.
That attitude kills morale.
It takes employers a while but they quickly remove offenders once they catch on.
Mistake 6: A Fear of Consequences
Codingo, a StackExchange user, is a new developer. In fact he’s at his first job after college. And he’s just failed his first performance review.
He’s being punished for asking too many questions.
There were a few other issues listed e.g. low code quality. But that makes no sense, given the fact that he’s specifically asking questions to get better.
This is how submissive and compliant developers are made.
How do I know? He’s already been infected with the fear. In his question he states:
“So I was just put on a Performance Improvement Plan (PIP) after six months at my first job out of college. I know this means I’m going to get fired when the time is up, but until then I would like some advice on how to improve for the future.”
It’s like his hard work doesn’t even matter.
Developers are systematically overworked. They’re expected to perform miracles with little-to-no notice upfront. And to add to that suck salad, they’re conditioned by employers to be submissive.
These developers struggle to become all-stars.
They’re so afraid of making a mistake, of getting fired that they do the minimum required to get by. They struggle to be creative, to take initiative; they tell their bosses whatever they think he wants to hear.
Which ultimately results in them losing their jobs.
Mistake 7: Name Calling, Gossiping & Slander
Gilbert Gottfried, comedian and voice of the Aflac duck, decided to make some jokes.
Some Japanese Tsunami jokes. Right after the 2011 Japanese Tsunami.
He added to the pain and suffering of an entire country. His “comedic timing” couldn’t have been worse.
Aflac fired him immediately.
This is the same sort of thing happening in the development community. We make jokes about clients, our bosses, our co-workers. We talk about how stupid other people are.
Instead of discussing the issues we make it vitriolic.
We make it personal.
If someone suggests an idea we shred their idea (using logic and reason, of course). We criticize others on social media. We completely demolish them, letting them know they were way off base.
What’s worse, the criticism usually doesn’t come with a solution.
Mistake 8: Social Justice Faux Pas
Playhaven fired their developers after they were accused of making sexual jokes. Adria Richards, then a developer liaison for SendGrid, was sitting in front of them. She felt offended, deciding to post this tweet:
— Adria Richards (@adriarichards) March 17, 2013
She wasn’t part of the conversation. They weren’t even talking about her. But she felt it was her duty to “check them” for their behavior. Even though she’s guilty of basically the same thing.
@skwashd you should put something in your pants next time…like a bunch of socks inside one…large…sock. TSA agent faint
— Adria Richards (@adriarichards) March 14, 2013
It wasn’t always like this. But our PC culture has changed a lot. These days, seemingly innocent, albeit immature, mistakes like these are enough to ruin someone professionally.
There’s a huge price to pay for social justice faux pas these days. Everyone involved in this story lost their jobs.
A faux pas like this creates bad press, scares off customers, and opens your employer up to lawsuits. Things they simply won’t tolerate.
Here’s Why These Mistakes Are So Common
The people making these mistakes are missing one of four things.
- Attitude. Unpleasant or abusive co-workers suck the life-force out of a team. You learn to avoid them. Your employers start to notice, which likely means their days are numbered.
- Ethics. The damage from immoral behavior spreads automatically. If you find out your co-worker is stealing, you’re in a tough spot. Ignore it and you’re distrusted when everyone finds out you knew and said nothing. Report it and your co-workers distrust you for reporting it.
- Judgment. Poor judgment means your good intentions are likely to get you in trouble. And because your intentions are good, you’re less likely to talk it over with someone else, magnifying the problem.
- Politics. We’re all wounded in different ways. Being humiliated tends to be more devastating for men while women struggle with betrayal. Office politics is like a minefield. You have to cross the field but those who made it probably won’t help you.
If you’re weak in any of these four areas, you’re in danger. Tread carefully. Pay close attention to situations that lean heavily on these areas.
How are you supposed to avoid making these mistakes if you’re unfamiliar with these rules?
Simple. Choose who you want to be.
People in general and developers in particular tend to approach life in four different ways.
- The Simple. These developers are naive. They don’t know what they don’t know, but they think they do. They have a full blown case of Dunning-Kruger. Inexperience or a lack of knowledge is all you need to be simple.
- The Fool. This developer knows the rules. They know what they’re supposed to do. They even understand the consequences that come with ignoring the problem. But they ignore them anyway. They only learn from consequences, punishment and pain. Spend a lot of time with them and that pain spreads to you.
- The Mocker. These developers are fools on steroids. They laugh at and humiliate those who “worry” about doing what’s right. They take a special kind of pleasure in spreading contempt and condescension wherever they go. They humiliate, make fun of and put down anyone who disagrees with them.
- The Wise. These experienced developers know how to “take the meat and leave the bones.” They’re able to digest constructive feedback, even when it’s slathered in abuse. They’re curious and helpful by nature, asking questions to learn and grow. They work to build others up because they understand — they know what it’s like to be simple.
Once you’ve decided (or accepted) who you’ll be, take the time to find trustworthy people who’ll get you there.
Then, spend your time with them. Run your thoughts and ideas past them.
If you want to be wise, find a wise mentor or senior programmer who exemplifies the person you’d like to be. Doesn’t matter if it’s a co-worker or friend; doesn’t matter if you meet in person or online.
Just as long as you can talk things over with them.
Wise developers typically have experience. They understand the social climate of the company and they’ve navigated the office politics successfully.
Run your decisions past them, learn to think like them. Just make sure you’re the one making the final decisions.
When you decide, own your decision. This makes you better prepared for any outcome — even if you lose your job.
I Know Developers Who Were Fired for Less
Losing your job is painful and humiliating. Especially if you didn’t do anything wrong.
It’s true: developers have been fired for much less.
But here’s the thing about getting fired. The reason you get is rarely the genuine cause. An employee gets fired for stealing. That could be the real reason, but it could also be…
- I can’t trust you anymore
- I knew you were dishonest
- I needed to get rid of someone, thanks for giving me a reason
Macro level concepts like relationship, trust, happiness — these matter more than your ability to code (which is still very important).
“All-stars don’t make these mistakes, though.”
Sure they do. Imagine you’re best friends with the boss. Someone accuses you of stealing. Your accuser is going to have to have some pretty solid evidence to make things stick. Even then you’re more likely to get a pass.
Being incompetent can get you fired.
No doubt about that, but the timing of that outcome, that depends almost entirely on these macro level concepts. Master these high level concepts and you gain more trust, confidence and respect — the macro level concepts that protect your position.
It’s a secret developers do their best to ignore.
Until Their Co-worker Gets Busted Looking at Porn
If he’s mastered these high level skills, he’s far more likely to get a pass. That bothers most people. It should bother you.
You’d never make those stupid mistakes.
As we’ve seen, it’s not so simple. These mistakes, while obvious to outsiders, are easy to make. They do incredible amounts of damage and the cost is high.
But you’re different now.
You’ve been exposed to a reality few developers are willing to accept. Spend time with the right people and you gain the wisdom, knowledge and insight you need to master these high level concepts. With consistent practice, you’ll avoid the same subtle and obvious mistakes everyone else makes.
No job loss required.