A Few Traits of a Sucky Developer — From a Tester’s point of view


A sucky developer just codes and does not think

The story goes like this:

QA reports a glorious bug with detailed steps to reproduce the issue. The craptacular dev says: “Oh, that is that other team’s problem”, and goes back to work. A great developer would solve the problem. The problem is manifested in your app even if it is not your fault.

An Alternate story

QA: Hey, I found this issue where this happens. It is working according to the spec, but I don’t think they anticipated the problems this could cause.

Crappy Dev: I built it like the spec. End transmission.

I don’t even know why anyone would ever say this…but people do.

A craptacular developer has no passion

A great engineer in any discipline should be able to say “I don’t know, but I can figure it out”. Great developers pick up new tech, use it well, and see its strengths and weaknesses. The craptacular developers never change their tune. They are either stuck on one tech because they are blind to new options, or because they are too lazy to learn. There may be other reasons but does it really matter? A friend of mine said once that when you agreed to become an engineer, you agreed to a lifetime of learning and re-learning.

A crappy dev throws code over the wall

The most craptacular thing you can do is not test your code. Every bug I have ever found (that is not in code I wrote) was there before I got there. Some are so blindingly obvious that I think to myself, “Did they even click this thing?”

Just test your code, man. I am not your mom. Clean up your own mess then I will take a look at it. Sometimes I am pretty sure some developers don’t even compile their code before they check it in. Two words: Lay. Zee.

A crappy dev has no restraint

When you find that magic combination of a person that has amazing technical knowledge, tests their code, solves all the problems and is happy about it, you usually have a great engineer. This enthusiasm can also be their downfall. As they continue learning about new tech, the nearly uncontrollable desire is there to “try it out” because it solves a problem you currently have. A great developer has the ability to say, that’s cool, and would likely solve our problem, but let’s not cram everything that is cutting edge into our product as it will likely have unforeseen side-effects.

The craptacular developer crams in every new thing, latest and greatest thing until you have a half baked, hodgepodge, mishmash of beta and alpha libraries that cause more problems than they solve. But hey, at least people can see ALL the new stuff on one site. The menu on this page may look different than the menu on that page but the user can figure it out, right?

The desire to refactor is another characteristic of both the great dev, and the craptacular dev. You can always refactor something. Always. Sometimes, however, something works, works well, and has always worked. There is no reason to refactor it other than you did not write it (any code that you did not write is probably garbage, btw). Just leave it alone, man. I don’t want to test and make sure nothing broke just because you got some wild idea to refactor something. The craptacular developers are even worse. They refactor it while fixing something unrelated and do not tell you.

Even crappier craptacular devs never refactor anything. They just start putting if statements around things and overloading methods and passing more and more params that are optional for most use cases. Brutal. That is how you end up with the image above—reproduced here because it is so amazing. It bottles the mind.



There is hope for a crappy developer. As a tester, you can find your developer’s weakness and use it to motivate them to be better. For some, it is pride. For others, demonstrating their code to the customer and watching it fail miserably will motivate them. Find what works and use it.

As stated here:

Websites that are glorified shopping carts with maybe three dynamic pages are maintained by teams of people around the clock, because the truth is everything is breaking all the time, everywhere, for everyone. Right now someone who works for Facebook is getting tens of thousands of error messages and frantically trying to find the problem before the whole charade collapses.

That is why we test it, ship it, fix it, repeat. The last thing you want to add to the mix is a crappy developer.

Things that are NOT hallmarks of a great developer

The ability to estimate how long something will take. No developer will ever be able to do this.