8 Common Mistakes That Get Developers Fired

Share this article

A fire
A fire

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.

Nissan steals from Stack Overflow

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.

Mistake 5: Criticism & Contempt

Linus Torvalds, creator of Linux, wants to give you the finger. If you disagree with him he advocates physical intimidation and verbal abuse. And he defends that right.

Linus says eff you

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.

Developers have a reputation for being abrasive, rude or condescending. We laugh at our client’s stupidity, talk down to other developers, treating people badly in general.

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.

Gottfried fail

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:

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.

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.

  1. 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.
  2. 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.
  3. 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.
  4. 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.

  1. 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.
  2. 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.
  3. 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.
  4. 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…

  1. I can’t trust you anymore
  2. I knew you were dishonest
  3. 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.

Frequently Asked Questions (FAQs) about Common Mistakes that Get Developers Fired

What are some common mistakes that can lead to a developer getting fired?

Developers can get fired for a variety of reasons, but some of the most common mistakes include not meeting deadlines, producing poor quality code, not testing their code thoroughly, not communicating effectively with their team, not being able to adapt to new technologies, not following company policies, and not respecting the intellectual property rights of others. These mistakes can lead to project delays, cost overruns, and legal issues, which can all result in a developer losing their job.

How can developers avoid getting fired?

Developers can avoid getting fired by always striving to improve their skills, staying up-to-date with the latest technologies, communicating effectively with their team, meeting their deadlines, producing high-quality code, thoroughly testing their code, following company policies, and respecting the intellectual property rights of others. It’s also important for developers to have a positive attitude, to be proactive, and to be willing to take on new challenges.

What should a developer do if they get fired?

If a developer gets fired, it’s important for them to stay calm and professional. They should take the time to reflect on why they were fired and what they can do to improve. They should also update their resume and start looking for a new job as soon as possible. It’s also a good idea for them to reach out to their network for job leads and to practice their interview skills.

How can developers improve their communication skills?

Developers can improve their communication skills by practicing active listening, being clear and concise in their communication, using appropriate body language, giving and receiving feedback effectively, and being respectful and empathetic towards others. They can also take communication skills courses or workshops, read books on the subject, or hire a communication coach.

How can developers stay up-to-date with the latest technologies?

Developers can stay up-to-date with the latest technologies by reading tech blogs, attending tech conferences, taking online courses, participating in coding challenges, and joining tech communities. They should also be open to learning new programming languages and tools, and they should be willing to experiment with new technologies on their own time.

How can developers produce high-quality code?

Developers can produce high-quality code by following best coding practices, using a good IDE, writing clean and readable code, using version control systems, writing unit tests, and doing code reviews. They should also strive to understand the problem they’re solving thoroughly and to design their code in a way that’s easy to maintain and extend.

How can developers test their code thoroughly?

Developers can test their code thoroughly by writing unit tests, doing integration tests, doing system tests, and doing acceptance tests. They should also use automated testing tools and continuous integration systems, and they should strive to achieve a high level of code coverage with their tests.

How can developers follow company policies?

Developers can follow company policies by reading and understanding the company’s handbook, attending company training sessions, asking questions if they’re unsure about something, and always behaving in a professional and ethical manner. They should also be aware of the company’s code of conduct and they should respect the company’s values and culture.

How can developers respect the intellectual property rights of others?

Developers can respect the intellectual property rights of others by not using copyrighted materials without permission, not plagiarizing other people’s work, not infringing on other people’s patents, and not disclosing confidential information. They should also be aware of the laws and regulations related to intellectual property rights in their country.

How can developers have a positive attitude?

Developers can have a positive attitude by focusing on the positive aspects of their job, by being grateful for the opportunities they have, by being optimistic about the future, by being resilient in the face of challenges, and by being kind and respectful towards others. They should also take care of their physical and mental health, and they should strive to maintain a good work-life balance.

Andrew McDermottAndrew McDermott
View Author

Andrew McDermott is the co-founder of HooktoWin and the co-author of Hook: Why Websites Fail to Make Money. He shows developers and designers how to attract and win new customers.

career-advancementdevelopmentjoelfmistakesprofessional development
Share this article
Read Next
Get the freshest news and resources for developers, designers and digital creators in your inbox each week