How to deal with incompetent lead?

Question

Alright, so we are a two people team directly reporting to our director. I have 4-5 years of experience and my teammate has 20+ years of experience. For obvious reasons he is my lead. We both are Programmers and we interact with our customers directly.

Now, I do not appreciate his coding style at all. In my opinion his code is 'Quick and Dirty'. Now, this can be purely my opinion and may have nothing to do with the facts. However, I try to stay away from the projects that he works on so that I don't have to defend something I dont agree with.

So far it has been working out for me. However, last week his project blew up and for some reason he pretended to be busy and I had to fix the code.

Now, since my director has to approve any immediate code changes in production. He had a chance to look at it and he was pretty dissatisfied with the fact that there are problems in the production and also that quality of the code was really not so good.

Now, again I do not want to start pointing fingers BUT at the same time, I do not want to defend something I do not agree with. I had no idea what to say when the code and system were criticized badly.

• I do not want to be a bad team player and play a blame game
• Also, I do not want my boss to think I had any part in writing such a low quality code.

How do I convey that message?

Answer 1

Stop working in silos.

The more you have a culture of "stay on your half of the codebase", the more likely it is that:

• code will go wrong because nobody asks questions
• it will take you a long time to find and understand code when things do go wrong
• you cannot explain why design decisions have been made
• you end up breaking something else when you 'fix' the code you've never seen before
• you end up looking like you don't understand it.

As you've just found this leaves you playing the blame game whether you want to or not: ultimately, your answer is going to boil down to "I don't know, that's not my code".

Right now, you can try to be slightly more diplomatic:

I'm afraid I'm not familiar with this part of the code base.

That's not really my style, but perhaps (Team Lead) had a reason for coding it that way.

You're right not to jump in and criticise. If you have different styles it's entirely possible there are advantages to the way the code is written that you just don't see. Even if not, your director has presumably approved this code before and perhaps hired your lead. Instead offer different ways of doing things: "I would have combined these into one method", etc. There's no 'good' answer in this situation, but focus on the practicalities of getting the bug fixed and the release tested and deployed.

... but that won't work next time.

You've still got a bunch of 'problem code' that you've ignored up till now, but can't afford to keep ignoring. Your team lead might not be fussed about code quality but when his code next falls over, you'll be asked why you weren't addressing the problem.

• Do code reviews.
• Try to document each other's code, explaining edge cases, etc.
• Make sure all your code is tested. Run code coverage for your tests.
• Divide tasks so that one of you writes tests and the other produces code which meets the tests. Swap roles.
• When new development comes up, ask to be assigned to tasks which force you to work with code you've not used before.

Even if you don't end up exposing yourself to all the darkest reaches of your colleagues codebase, you'll at least begin to notice enough patterns in the things your colleague does which might help you diagnose bugs faster next time.

Answer 2

Honest, direct communication is fine. Bring solutions, not problems. You can raise the following points with your boss:

1. You noticed the problem with the production code was preventable.
2. Your fix patched the problem over--but doesn't create stable, maintainable code.
3. Recommend code reviews to avoid future problems.

Code reviews are magical places where junior developers can introduce new techniques and best practices into production, without ruffling feathers. The focus is on the code, not the person. Don't condescend, over-instruct, or generalize beyond the current example. Simply state that for this particular case, there is a useful pattern you've had success with. Be specific about a single issue that can arise for each change. "If we change this to that, it will leak memory. If we change this to that, it will fail gracefully for poor inputs, such as this, which has occurred before." In contentious situations like this, you "rotate the code"--everyone reviews the code, but the person to your left in the meeting makes the changes (or next tallest, or next birthday, etc.). Everyone benefits, and no one loses face at the time--although people who require the most changes become obvious over time.

Answer 3

Fix the problem

You can either continue the same "style" of coding and get the immediate problems fixed or take the time to fix the over-all problems plaguing this code set. Your boss will have to decide. That's why he gets the big bucks.

Hopefully, there will be some sort of postmortem on this problem and your team needs to decide if you're going to allow the other developer continue with the quick and dirty programming.

Again, your boss is going to have to decide how to move forward. I don't know why your boss doesn't enforce what appears to be a higher standard for coding on the sr programmer. The technical debt ultimately had to be paid by everyone.

All you can do is make suggestions and do your best given the constraints of your boss's decisions.

Answer 4

If you work as a team you are Both responsable for the quality of the code (even if you did not write it). All code should be code reviewed and a consensus reached.

If you have trouble reaching consensus then install automated tools to do the validation only allow commits that pass the automated validation.

As how to handle your current situation.

1. Say this code was not your project.
2. You only fixed the specific bug (not the whole project/file) to prevent instability.
3. Suggest how the processes can be improved overall.

Answer 5

• Meet with your director and explain your constructive disagreement with your team lead's coding style. Use tact.
• Come prepared with about 3 coding, architecture, or process examples that support your point of view.
• Depending upon the nature of the situation, and the personality of the team lead, you may want to include the team lead in this meeting.
• Explain your point of view, but do not argue with your director. Listen to his/her opinion. Be prepared to conclude the meeting in less than an hour.
• Leave the meeting. Finish your day. Go home. Have dinner. Go to sleep.
• During your commute to work on the next business day, evaluate your meeting with your director. Was he/she fair?
  • If 'Yes' (even if he/she did not agree with your point of view), then be prepared to adjust your way of doing things (other people have responded with some great advice).
  • If 'No', or if you feel that you cannot coexist with this team lead, then you have two options: 1. Ask your director if you can transfer to another department. 2. Start looking for a new job.

---

More on the 'Start looking for a new job' advice:

• Pursue this option only as a last resort.
• In the workplace (and in life in general), try your best to see the other person's point of view.
• But ultimately, if you're unable to make things work, you should start looking for a new job. Life is just too short and coding jobs are plentiful.