10 things a horrible developer would do

Imagine, for a moment, that you’re a horrible developer. What sort of things would be on your to-do list?

A horrible developer is someone that doesn’t respect the team, has an overinflated ego, and a love of office chaos. They’re the supervillain of the development floor (on purpose).

Items on the to-do list range from poor practice, to terrible teamwork, to the downright diabolical. Here are some of the things that a horrible developer would do.


Horrible practice

A good developer strives to improve. They’re happy to learn and want their code to be the best it can be. They recognise that mistakes are a learning opportunity. A horrible developer, meanwhile, favours a host of bad practices.

•      Never reviews their previous work or clears technical debt

A horrible developer doesn’t believe that they should revisit or clean up past code. Indeed, they have no sense of teamwork or ownership for the product as a whole. As such, they never spend time clearing technical debt or refining their old code.

•      Refuses to learn new things or embrace new ideas

A programmer’s job is never done, and part of the reason why is the rate of evolution in the tech industry. But a horrible developer remains steadfast in the opinion that their way is (and always will be) the best way. That means no learning and no changing.  

•      Measures progress and worth by Lines of Code (LoC) written

(And then brags about how much code they’ve written compared to you.) A horrible developer will always put quantity over quality. If only they believed in negative code

Note: being a horrible developer is about more than inexperience/learning and adapting to new technical skills. Rather, they purposefully avoid improving or changing.


Horrible teamwork

Teamwork is a crucial skill in software development. And so good developers take care of their soft skills and are happy to help their team. The lone tech genius is a myth, after all. Unfortunately, a horrible developer doesn’t place the same value on their fellow team members.

•      Gets offended during code reviews

…Or anytime a colleague assesses their work. A horrible developer cannot take any constructive criticism or advice from their colleagues. Instead, they simply get offended and defensive.  

•      Criticises or derides a colleague and/or their work

While they can’t take helpful advice or gentle critique, they can (and will) dish out harsh criticisms to others. In fact, a horrible developer would actively mock their colleagues and their work. This creates an unpleasant and discordant dev floor atmosphere.

•      Makes excuses, passes the blame and won’t admit mistakes

A horrible developer, in their eyes, can do no wrong. If something hasn’t worked, it’s not their fault. The customer uses it wrong. Their teammate wrote that bug. (And they’re sure to point out when someone else messes up, to boot.)

•      Constantly corrects their colleagues

A horrible developer is the kind of person that prides themselves on being an insufferable know-it-all. As such, they’ll correct pointless details, and inject themselves into your conversations. They’ll tell you how to fix a problem without knowing all the details, despite you not having asked them for their input.


Chaotic evil

Then, there are the actions that turn a horrible developer into a bringer of chaos.

•      Inhibit the flow of caffeine

It could be by throwing away or breaking mugs or using the last of the coffee. Whichever way they do it, only a truly horrible developer would stop their team from getting their caffeine fix.

•      Change a random semicolon in a colleague’s code to a Greek question mark

A particularly vindictive developer could change a random, innocent semicolon ( ; ) in a colleague’s code, into a Greek question mark ( ; ). Thankfully, in most cases this shouldn’t turn into too much annoyance — most developers rewrite a line of code that’s flagged as wrong.

•      Swap equipment

Think chairs or headphones. Everyone has their own preferences for how to set their chair or what the most comfortable headphones are. Imagine, then, the chaos if you get in one morning to find your chair is too low and angled weirdly. Or your headphones don’t fit your head, and so on.  


The villain of the dev floor

Thankfully, there aren’t many people that are evil enough to qualify as a dev-floor villain.

The horrible developer is a fictitious character. More likely, a good developer might inadvertently stray into the horrible developer’s to-do list. This doesn’t make them the villain of the development floor. It makes them human.

Everyone makes mistakes. Everyone has their shortcomings, and areas to improve. Ultimately, not being a horrible developer means having a good attitude, a love of code, and not maliciously causing chaos. That’s all there is to it.


Useful links

The benefits of being a boring developer

5 tips to help new software developers find their footing

A universal tech code of conduct