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?

  • 3
    If you are a team, then his code is your code, and you are equally responsible for all parts of each system. If this is not how you behave, then you are not a team. Feb 5, 2016 at 20:00
  • 8
    As a side note, the title of your question suggests you won't ever be able to deal effectively with this person. Your title indicates you lack a basic level of respect that would be necessary for positive interaction. Feb 5, 2016 at 20:03
  • 2
    I have 4-5 years of experience and my teammate has 20+ years of experience. For obvious reasons he is my lead.: No, it's not. I've met developers with 4-5 years of experience who can code the pants off of another developer with 20+ years of experience.
    – Jim G.
    Feb 5, 2016 at 21:05
  • 4
    If your director has to approve production code, does that imply that they consider your lead's "quick and dirty code" to be acceptable according to the company's standards? Feb 5, 2016 at 21:48
  • 1
    @JimG. Please don't abuse code syntax for quotes. Cursive combined with regular quotes are the preferred method of quoting in comments.
    – Lilienthal
    Feb 8, 2016 at 12:54

6 Answers 6


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.

  • 3
    I have yet to figure out a way to get "quick and dirty" coders on board to write tests for their code. For this answer to be more useful, you may want to offer some suggestions for that. Feb 5, 2016 at 23:17
  • There's two types of "quick and dirty" coders that I run across. Those that are inexperienced and don't know better ways. That type can be trained. Then there's the experienced "quick and dirty" coders who also don't know better ways but think their way is optimal. After all, there isn't time to use that new fangled stuff called design. Thus, training is of no value because they believe they should be the teachers. Anyways, I haven't figured out how to get around these people myself. 20+ years and still trying:(
    – Dunk
    Feb 16, 2016 at 20:27

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.

  • Simple state that for this particular case, there is a useful pattern you've had success with. - The name for this is teaching. Feb 5, 2016 at 20:01
  • @JoelEtherton Thanks ... I revised the wording. Basically, my point is to not lecture or hold class as if he doesn't know something. Simply stating "Pattern A works here" works, but "Pattern A is where you do this and this. The advantages are this. It's good in this case and that, or another. You can recognize when to use...[etc]". That's the connotation of "teach" I was going for.
    – jimm101
    Feb 5, 2016 at 20:19
  • 1
    I can dig that. I just wanted to point out that code reviews are invaluable education tools, but the point is to be open minded that there might be a better idea out there. Feb 5, 2016 at 20:26
  • Code reviews are not magical. Some developers are very defensive and that won't change in a code review. Feb 6, 2016 at 1:18

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.

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.

  • 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.

To convey your message, make the fixes you need to make and, via documentation, make it clear what you changed and why. To any reviewer, it should be obvious the changes have been made by a different person and show a different style.

If, as you claim, your work is better, then the fact that you have quietly integrated those changes into older work will reflect well on you.

Also, it is easy to criticize other work, but bear in mind that work may have been written in a rush or early in the programmer's career. No need to get upset about it.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .