What is the best way to deal with a co-worker whose programming work is of very poor quality?

joanne: What is the best way to deal with a co-worker whose programming work is of very poor quality?
I work with a developer who writes a lot of code, but it is very poorly designed and often wrong code. I am partly responsible for the success of the project. I also enjoy doing work correctly along guidelines and standards. What is the best way to either help my co-worker improve or mitigate his/her horrible code’s impact on the project?

Answers and Views:

Answer by Frecklefoot
Code reviews and unit tests. HTH

Answer by Krystina
Implement a formal code review process. The offending employee will hopefully use it as as a learning opportunity, thereby improving the quality of his/her code. Of course if the employee in question does not improve or change after code reviews are put in place then the problem should be dealt with officially during the performance review process.

Answer by intuitiv
Background: My co-worker was hired about a year and a half after I was, and I’d been working solo on the project for that long. He was not a programmer, particularly in the language we were using. He had a penchant for taking my code from yesterday and rewriting it, wrong, and then blaming me. Worst of all, he was technically my superior.

(His/her is a clumsy construction. My co-worker was male; I am arbitrarily choosing he/him/his.)

I see you’re partly responsible for the project, but responsibility does not always imply authority. If you don’t have authority over the co-worker, the best first step is to tell him that you’ve noticed he uses a different style than yours, and in the interest of consistency, could you get together and formulate some templates. Usually those templates can cover error-handling, interface format, etc. which are often points of conflict, and save a bunch of trouble right there. If he agrees, make a sincere effort to work with him. If he refuses, go to your superior and explain your proposal and that it was refused.

This didn’t solve my problem, but it did help. The actual solution, however, was painful for me to implement. I stopped fixing his code. If people had bug reports on his code, I sent them to him. And because I kept meticulous records on which of us was doing what, when our boss complained to me, I pointed out that we weren’t getting bug reports on my stuff, and I didn’t know what my co-worker was doing. Our boss was not a programmer, and didn’t want to interfere with the programmers, so this went on longer than I’d have thought. But eventually my co-worker managed to crash a production database. I worked 30 hours straight to get it back up, and after that, my co-worker started asking for my advice and coding more carefully.

If you are lucky enough to have authority over the co-worker, you can take a more direct approach. It doesn’t have to be nasty. Meet with him and explain that you’ve noticed he’s not using standard guidelines, and it’s affecting the quality of his design and code. Offer concrete suggestions to help him improve. If he takes them and begins to improve, great. If not, then either get him off the project if you can, or shift him to the least important part of it possible.

A lot depends on whether the poor work is coming from honestly being in over his head, or deliberately being lazy, or just not knowing any better. Good luck in resolving this situation.

Answer by audiovisual
The root question is whether this person is capable of higher quality work. If they are, then I recommend talking with them through the decisions that are poor — getting them to see the consequences of their decisions and what better alternatives might exist. Keeping the discussion about the code and not about them is essential, otherwise it’s very easy to have a conversation spiral downhill. Get them engaged in solving the problems — they may not even be aware there is a problem in the first place!

However, if they are resistant to improvement, deny there is a problem, or just cannot intellectually grasp the complexity of what is going on, then the best thing you can do is try and isolate off that person’s work. Assuming it is out of your scope of solutions to move them somewhere else, you can attempt to build a strong abstraction between their work and the rest of the project. Good testing and other metrics can help show where problems truly are, and solid documentation can help create this sort of structure.

Answer by throaty
Why should you have to worry about your part of the project and theirs? You shouldn’t have to. Let your boss know that you’re having trouble getting your tasks accomplished because you’re having to continually fix your coworkers issues. It sucks if the coworker is your friend but it sucks for you to be relied on for their work too. It’s not fair that they’re getting paid to complete a task that you’re eventually doing.