Let’s face the facts: not all developers are good. In fact, it is probably safe to assume that most developers are not good. Most of us are dealing or have dealt, at some point or another, with someone who was almost destructive to a project. The code they contributed was full of bugs, problems or over-engineering.

Besides the obvious (code quality) there are several problems associated with these types of developers. The biggest one is they are usually oblivious to the fact they are a bad developer, followed closely by the fact that they are really hard to manage.

Managing a bad developer

The problem with these bad developers is not that they are bad people. Far from it. They usually have the best intentions. I think the most common fix, and almost certainly, the least effective one, is limiting the amount of code they contribute to the project. This can be achieved easily, either by giving them really small, undefined tasks, or by simply not giving them any work. From my experience though, I believe this leads them down a spiral — they can’t really improve, can they? As a manager, you need to enable the “bad” developers to become good.

An interesting “excuse”, often heard, is sloppiness. I recently read a really good post on the topic of dealing with sloppiness. Some good advice there. And often times, sloppy does go hand-in-hand with bad developers. But it is only one small reason.

One big correlation I have noticed (no data to support this, though), is the multi-tasking part. Humans are notoriously bad at multi-tasking. This is especially true in the case of complex problem solving — which development absolutely is. You need to be able to focus on a problem, to solve it. If you are constantly switching between Twitter (my big problem), your phone, e-mail, a chat client, and your IDE, chances are you will make an incredible amount of mistakes. Unless you know how to avoid that. For example, I generally map out my solution on paper well before I start coding. I also usually start with the end product. That means, I write the code that I expect to have at the end (Test Driven Development, anybody?), then write the code that compiles and works as intended. This means that even if I do get distracted, I can always resume my thought process, either by looking at my paper notes, or restarting from the finish line.

Managers therefore, should make their absolute best effort to not give multiple parallel tasks to people. Not just the “bad” ones. The entire team will suffer if there are parallel tasks to be completed.

Also, another issue I have been seeing a lot of, is the fact that these bad developers are simply never given the opportunity to improve. It is a vicious circle. The team is always catching deadlines, so it is usually impossible to take time for code reviews, or even pair programming. Even though it would help enormously, and would probably improve the team’s timing in the end, after the initial investment.

In my career as a developer, every time I was able to sit down with someone, I learned something new. We also did some stupid/fun things, but … That is the best part. This also has a couple added benefits, like, not allowing many distractions (phones, Twitter, e-mail), but also of slowing down, because we usually want to explain the thing we are doing to the other person for real-time sanity checking. So, as managers, we need to allow time for the team, to fix these problems themselves, by performing code reviews, pair programming, etc.

Am I a bad developer?

There are a couple signs that might tell you, you should start taking steps to becoming a better developer.

  • I contribute less production code
    You may not be getting any tasks that touch production anymore. Your manager (and your team) do not trust you enough, or believe the code you write introduces more problems than it solves. Working on non-essential tasks is also a big indicator. If you start getting tasks that are related to the project, but not to the production code, ask yourself why that is. How much of the code you wrote recently has made it to production? How much of it was code reviewed? How much of that code was “rewritten” or flawed?
  • The number of bugs introduced by my changes is high
    Every production project needs a way to track bugs. Most will be able to then track the problems down to a specific area, and the most advanced teams will be able to figure out if a bug is specific to a changeset. For example, in our team, we have a way of doing that. I will write about it in a blog post coming up soon. Take a look at the numbers for your changesets and areas you own. If the number of bugs is high, you may have a problem. Granted, this is not always the only indicator. If an area is sufficiently complex, there can still be more bugs than usual. So take the numbers with a grain of salt, but if you notice a pattern, check it!
  • People told me
    Well, there you go… I am sure if someone took the time from their schedule and work to sit down with you, and tell you you should be doing better, they did not do it for a bad reason.

If the above signs hold true — what now? The first thing to do, is listen. As Stephen R. Covery said in the book 7 Habits of Highly Effective People:

“Most people do not listen with the intent to understand; they listen with the intent to reply.”

It is hard to explain how frustrating it is, trying to explain to someone, why something they did is wrong, only to be interrupted several times. For example, a team member I know, has never (to the extent of my knowledge) been able to sit down and listen to comments without expressing something completely irrelevant to that discussion. That includes the reasoning behind bad code. You have to understand that, as someone who is reviewing your code, I do not care what compelled you to write it so badly that I felt the need to sit down with you, and point it out to you. What I do care about though, is what you will do to fix it.
So, the next time you are sitting at a code review, and your code is getting hammered, be quiet. Listen. Understand.

Shut up. Listen. Understand. Stay quiet. Write down tasks, not comments. Write down what you will do to fix the problems outlined. Then, at the end, thank the reviewers, tell them that you believe doing tasks X, Y and Z (etc.) will help, then again listen to their suggestions.

The next step is to identify problematic areas. For some, that might be design patterns, for others, communication skills. When you identify that, you need to invest time to fix that! Rent or buy books, and study them. View online courses. But again, take time to understand them. Do not tweet at the same time. Do not read your email while doing that. Shut off everything but that one thing. Focus. And understand.

Finally. Talk. Talk with your peers. Ask them (relevant) questions, and listen to them. But again, listen, understand. Do not make it a full blown discussion. Understand that when you grow as a developer, people will start asking you questions too. Then, there will be time for having those conversations. Until then, listen.

There are no bad developers

But really… There are no bad developers. Because if you look at yourself, and have a desire to improve, you will do everything you can to achieve that. That usually also means that you will break the habit that makes you a “bad” developer. But as a person, the most important thing, in my opinion, is listen and learn.