10 characteristics of a bad developer

We meet them all the time, but we hope that we won't have to deal with them on our next project. Sadly there are many developers that fall under this category. Are you one?

I think it is important to distinguish between a bad programmer and a bad developer. Being a programmer, delivering code is one part of our job. But being a developer, making the project happen, is much more than just delivering code; it is working in a team, sharing knowledge, and most important, helping the customer get the product they need.

I have met great programmers, which are poor developers, and vice versa. However, the two are often related, and then you basically just have a bad resource.

In my opinion, being a bad developer is a lot more expensive for a project than being a bad developer.

Here is my list of top 10 characteristics of a bad developer:

1. Has a big ego and is more interested in his/her own success than the success of the team/the project.
   
2. Does not want to share knowledge of technology or domain.
   
3. Protects his/her own code at all costs, that is, does not let others criticize the code.
   
4. "Never does anything wrong".
   
5. The best defense is an offence. Attacks others before they can attack them.
   
6. Writes code in their own style, they are above any standards set by the project.
   
7. Only accountable when it suits them.
   
8. Often leaves others to solve their problem.
   
9. Talk about other team members behind their backs.
   
10. Usually delivers poor quality work, but not because they cannot do better, they just don't care to.

10 characteristics of a great developer

There are plenty of blogs on this issue, but here is my interpretation of the characteristics of a great developer. I have worked with a few, and I strive to become one myself.

1. Expert in communication. Can communicate successfully with any person on any level of any organisation.
   
2. Always looking for improvement. Even when things are great, they can always be improved.
   
3. Never (or rarely) present a problem without possible solution(s). It is easy to find problems, it may be hard to find good solutions.
   
4. Never (or rarely) say no to inquiries. Always takes time to help both the team, and the people around.
   
5. Is constantly critical about code. Always seek to improve his/her own code as well as others.
   
6. Thinks of every line of code as equally important. Never writes any code without purpose. Always rationalise every line.
   
7. Knows something about everything. May be an expert in one field, but has enough knowledge to have constructive discussions on the matter.
   
8. Constantly seeking new knowledge.
   
9. Constantly helping others become more knowledgeable.
   
10. Is always accountable for own actions.

The FIVE DYSFUNCTIONS of a TEAM

Do you work in a team and feel that team efforts are wasted, that meetings are boring, and that your team members doesn't really help you at all. Well, you are probably a part of a dysfunctional team.

Patrick Lencioni's leadership fable is not just amusing to read, it also gives great insight into how to deal with team dysfunctions. The fable introduces us to seven team members, most of which you can relate to some of your current team members. But the problem at hand does not really relate to one or more individuals, but how these individuals interact as a team.

The book is easy to read, you easily finish it in a day, and it makes only a few (5 actually), strong points on how to improve you teams productivity.

I read this book, because if was recommended by the Scrum book "The Enterprise and Scrum" by Ken Schwaber, a fine book on Scrum.