While some bad developers are easily picked from a crowd, many others are able to fly under the radar, ever-undetected. Why? Because most not-developers don’t know what to look for. Whether you're a coder or not, here's how you can differentiate the bad developers from the good ones.

Bad developers are the worst...

But the truth is, assessing a software developer at first glance is pretty hard to do.

There are different types of bad developers. From super-obnoxiously-obviously bad to deceptively destructive, there’s a whole spectrum of bad developer behaviors. But, unless you’re up to your own eyeballs in someone else’s code, it can be hard for many of us to differentiate poor developers from great ones.

Fortunately, though, while it may afford you an upper-hand to have some background in programming, you don’t have to know how to code in order to catch a bad coder. There are some telltale signs that will pin a rose on any lazy, arrogant, or otherwise bad developer.

Here’s what to look for when you’re assessing software developers…

What’s your type?

Just like any other thing that comes in multiple shapes and sizes, there are many different types of  bad developers. Of course, there are exceptions to every rule (which means, there will be decent developers who fall into these categories), but, on the whole, these types are indicative of poor development practices.

If you see these traits in your own team, it behooves you to nip them in the bud (which means, you need to communicate with (or even redesign) your dev team.

Here are the major types of bad developer (please note, these titles are not official; they’re just appropriate and dramatically effective)…

The Hare

We’re all familiar with the old fable, The Tortoise and The Hare. In recap, it goes like this:

the Tortoise, a slow and methodical creature, is racing the Hare, a super-fast rabbit-looking creature that’s built for speed. In a race against time, the Hare has a considerable advantage but…

Spoiler Alter! The Tortoise wins.

Based on his approach, strategy, planning, and commitment to the goal, Tortoise takes the cake.

The Hare, then, is a developer that produces code too fast and the result is a flimsy product that is not sustainable nor maintainable. Even if he reaches the finish line first, the Hare gets there with an inferior product.

Because it was approached with zero regard for planning, the Hare's code is difficult to understand and almost impossible to maintain. To the Hare, the quick win is more important than the long game and, accordingly the product suffers.

The Hare often tangles all the functionality of his code together. This means that any future changes to even one line of code can break the entire piece of software. This is known as tech debt, and that is bad for everyone.

This isn’t to say that all fast coders are bad coders, but it is to say that those who proceed without any plan for maintainability produce sloppy code. It’s also to say that they typically rush their work, don’t test their code, and that, invariably, it will need to be rewritten.

Wasted time never moved anyone forward.

The Lone Wolf

Some people are introverted, and that is not inherently a bad thing. But developers who will only work alone often do so to their own detriment.

A developer’s insistence to work solo is usually a sign of intense arrogance (which is usually a sign that that person knows he knows everything, which is yet another sign that that person also believes they don’t have to learn anything new).

The Lone Wolf is a developer that can’t tolerate criticism or competition. They will accept unrealistic challenges, and they’ll always resist help. Sadly, these traits prevent them growing into truly exceptional coders because, the truth is, the best developers work in pairs.

Among other strong development practices, working in pairs is one of the tenants that separates DevSquad from other dev shops.

The Lone Wolf believes his code is perfect and, without a partner present new perspectives or to keep the Lone Wolf's cavalier coding style in check, the Lone Wolf may be inclined to disregard documentation or best practices. That hubris will ultimately shoot him in the foot.

Yes; resourcefulness is a critical part of growth, but disregard for process will keep even great talents behind the curve. If a coder won't hold a mirror to his work (by way of accepting feedback, adapting to criticism, or respecting best practices), he'll never write better code.

The Apath (or apathetic developer)

The Apath can be satisfactorily defined in one simple word, “meh.”

So indifferent and unexceptional. So unenthusiastic and, honestly, kind of smug.

But we’ve all known someone like this-- someone with an attitude and work ethic that’s just so meh. Maybe these people aren’t bad people, but you can be dang sure they’re bad developers.

Apathetic developers usually lack the drive to master skills, they don’t crave to learn new ones, and they’re generally passionless for programming. (yikes)

The Apath is content doing “okay” work for an “okay” job, and you won’t find him trying to further himself or his abilities.

An apathetic developer is slow; he takes his time writing code but, not surprisingly, that code reflects the meh-ness of its creator’s indifferent hand. He’s not methodical like our winning Tortoise, but, instead, the Apath often writes code that is no better than barely adequate.

To me, this is the saddest and probably the most destructive type of developer. The Apath is content at the bottom of the barrel, he has no drive to exceed expectations, and his software is just so meh.

The Freeloader

We’ve all known one of these people, too…

The Freeloading developer is a close sibling to the Apath; he lacks motivation, he’s happy letting other programmers do his work, and he’s super stoked about copy-and-pasting.

The Freeloader has a lazy software development style, and because he relies on the talent and productivity of others, the Freeloader typically doesn’t improve.

While there is still hope for Freeloaders to grow-up and do better, many of them are content coasting through projects. This creates a sense of carelessness when writing code which, naturally, leads to animosity within teams (and to poor software).

These developers are like barnacles, and that’s just wrong.

The Bull

Lastly, the Bull developer is both a rock and a hard place. He can be a lethal combination of all of these types of bad developer, but he's got one one extra-special ingredient: unrelenting stubbornness.

Being steadfast can be beneficial in a work environment, but it can also become a barrier to progress. Sadly, the Bull developer, however skilled he may be, is also unflinchingly stubborn, and his need for control can become a brick wall.

If a software developer can’t listen (to product owners, product users, fellow developers, mentors, or etc), the result is stagnant code and a developer that’s just plumb stuck.

In part, stubbornness is defined by an unwillingness to listen to the reason of others. Bull developers are often smart coders, but their reluctance to see other perspectives keeps their code in a box. Anything that lives in a box ultimately becomes irrelevant.

These coders know that they are always right, but they are also unwilling to share their solutions with other developers. This makes growth a slow process for Bull developers.

Hardheadedness is a fine trait in many arenas, but in software, great coders have to be flexible, adaptable, and generous.

Wrap Up

At the end of the day, what separates the bad developers from the good ones is a sense of accountability.

Bad developers don’t take ownership of their code; they don’t actively seek to grow their abilities, they’re not curious about new horizons, and they’re unwilling to recognize and learn from their mistakes. Look for those traits in your team members, and it will lead you to your weakest software developers.

Remember, though, not all developers that fit these types are unequivocally bad. Most people that pursue a life in software development are fundamentally problem solvers. They write code because they want to create solutions.

So don't write-off your dev team at a glance; challenge them, stimulate them, mentor them, and maybe you can cure or harness these bad development traits!

Do you have your own story about bad developers? Maybe you're a reformed bad developer? Maybe you worked with bad coders? Tell us your thoughts in the comments below!