How can I deal with an underperforming peer that does not express interest in following team conventions?

Question

Overview

I work on a project-oriented software development team, and we have fairly standard conventions for file organization, naming, code separation, and how to write code in general. These conventions are documented publicly and everyone in the team is aware of them.

In the team, we have a specific peer who is in the same pay grade as myself and others - so, presumably, should show a roughly similar level of performance. Let's call him Bob.

Bob shows very poor quality in any non-functional regard. What he does does work, but it requires significant revisions and upkeep. He has been informed of this by his peers, but he does not act to improve.

Details

Bob does not follow any of the conventions specified, so when someone else has to work on code that he wrote, often more than just the editor's auto-formatting needs to be used: things need to be renamed, files split, and other kinds of housekeeping. Bob has been made aware of this issue by several colleagues, but the behaviour remains.

Similarly, Bob's code quality, in general, is very primitive, but he gets things done*. This means that for management, Bob is completing his assignments, and thus no intervention is necessary.

However, this low quality results in a noticeably higher failure rate for his assignments. If a non-trivial assignment is completed by Bob, eventually someone else will have to revisit the code and do a major refactor of it, either to improve readability, performance or to enable code reuse. In one case, an entire project handled by Bob had to be remade from scratch because it was simply inscrutable and with no documentation.

In almost two years of working with Bob, he fails to improve the situation, even in the relatively low-skill task of keeping the code conventions. This leads me to believe he has no interest in improving himself, which frankly would be fine if this didn't happen at the expense of the project schedules and team's reputation within the organization.

---

I'm very sorry if this sounded a bit like a rant. I have tried to keep my tone as mild as possible, but a gear only has so many teeth to grind.

Since I'm just a peer, how can I attempt to improve this situation? I'm aware that it is not entirely Bob's fault since the organization does not seem to have support for this kind of situation, as we are a bit "XGH".

What I've tried so far, in no particular order:

• Reminding Bob of the conventions when I notice something particularly egregious;

• Personally recommending courses that he could take that could help him (the company has a study budget per employee);

• Proposed the usage of automated tools for validating conventions (linters) whenever something is put in version control, but this task is buried in the deepest realms of the Backlog-Backlog;

• Made available a configuration file to be imported into our editors (everyone uses the same one) that sets up the auto-format rules (wouldn't solve all problems with Bob's work, but he has not imported this file);

• Informing management about the issue;

• Called up a few pair programming sessions between Bob and the rest of the team each, but these end up being rather unilateral as Bob does not express much interest in them, and thus the sessions devolve into someone programming and Bob watching;

• Opening issues on our Jira for everything that needs to be refactored or fixed, so I have data to quantify the rework needed. These just get buried right alongside the linter task;

• On a specific project, specifically write all code at "Bob-level", since perhaps this was just an issue of him not being comfortable with the abstractions and language features normally used. He managed to respond with even more dubious code;

• On another project, I wrote a framework such as to force every programmer to write in a specific way for code to even work at all. Also failed, because that just puts a fence around the issue and causes inconvenience without improving the situation.

Answer 1

Introduce code reviews

As you mention that you follow fairly standard procedures you should consider introducing code reviews with your team. I am going to assume you are using some kind of version control, therefore not operating on the master, but rather following the process of creating branches and merge requests, then merging those into the master upon completion. If this is not the case yet, then this should also be introduced.

Proceed as follows:

• Protect the master branch entirely from direct pushes to it. Any change that is allowed to be pushed to master must arrive via a merge request.
• Designate a maintainer with elevated privileges. This maintainer cannot be Bob. In case a hotfix is ever required, your maintainer may force push to master, however this should only be an exception.
• Follow the practice of creating merge requests per ticket closely. A developer should never be allowed to merge their own request to master, this should always be done by a reviewer. If the team notices someone merging their own request, especially when not reviewed, immediately revert the changes on master and notify the developer in question. Remind them to follow the procedure.
• Introduce and enforce code reviews. Your code should be passed in accordance with the four-eyes-principle. Have always someone else review code, than the person who wrote it.
• The latter enables you to enforce practices and procedures, such as code formatting, documentation, best practices and so on. If Bob (or anyone else for that matter) does not follow procedure, rigorously reject the merge requests upon review and mark them as TODO again, because according to your processes the ticket is not yet completed, even if the code functions in the broadest possible sense. Bob will have to follow your practices or none of their work reaches the master.
• If management asks why Bob does not complete their work and Bob responds, that they did, but their code keeps getting rejected, thus delegating the problem to you or your peers - respond that Bob did indeed not complete their work, because their code is not yet up to speed.
• If management then argues why functional code is rejected, give them numbers on how much time the team spends fixing poor code or issues that arise from it in man-hours. This should translate to cost for management, thus making the issue easier to grasp in business terms. If need be have a meeting, explain the concept of technical debt and the effects it has on time management.

It is important that you find a team consensus rather than solely you pushing this issue. If the team agrees with you and the practice of code reviews is introduced and followed, then Bob's poor code can never reach production, thus forcing them to at least adhere to some standards. How strict these standards are followed depends on the team. E.g. I will not reject a merge request for a missing space before a bracket, but, especially if I have found other things to be fixed, I may post a suggestion for that code snippet. For developers such as Bob the reviews should be more strict. As Bob is ignoring best practices and shows no interest in improving, their code should be looked at more rigorously and rejected more readily.

The major advantage of going about things this way is that you can point at your processes and practices that were established by the team as a whole, when arguments arise why Bob's code is getting rejected. It is also not on you to do the reviews, but the whole team would do so, thus eliminating one person being blamed for code rejections.

Lastly, ensure that Bob is not the maintainer of any of your projects or repositories. Have someone else be a maintainer and make sure Bob does not have a project they maintain and produce completely on their own, thus being able to bypass all checks and safeguards, such as merge requests, reviews and best practices.

---

Personal opinion

I do not think you can solve this entirely by yourself. Practices must be established and adhered to via team consensus, be it after decided upon democratically in a flat hierarchy, or by convincing the team lead or project owner of their benefit - something the team can push for.

When raising this issue with management it is important to translate the issues to time and therefore money, because management is not interested in beautiful code architecture, but they are interested in cost and these things do have a large effect on cost. Do not argue for better practices, because this is how others do things or because this produces better code, whatever better means, but argue for the effects technical debt has on time investment. This can be done e.g. by identifying tasks in the last year, where the team spent man-hours to fix problems that arose from not following best practices. It is important to communicate how much of an expense this is to management, otherwise you cannot establish a bridge between the developer world/language and the business world/language.

Answer 2

Bob is not your actual problem

I understand that it is easy to find people like Bob hate-able because you feel dragged down by them. But, even though you are bothered by Bob's deficiencies, Bob's deficiencies are not the source of your pain. You actually already know this:

I'm aware that it is not entirely Bob's fault since the organization does not seem to have support for this kind of situation, as we are a bit "XGH".

Your actual problem is that management does not care that it employs people who perform at Bob-level regularly.

But it is worth examining in detail. Consider the following thought experiment:

Let's say I give you one magic potion that completely transforms Bob into the kind of performer you want him to be, which is specifically tailored to Bob the individual and cannot be given to anyone else. Let's also say that Bob agrees to drink this potion, and then undergoes the kind of transformation that you would like to see him make, instantly.

This would only solve your problem until management hired another Bob. Management did not identify that the last Bob was Bob-like when it hired him, and did not care to adjust his performance after it was found by you and your team members to be insufficient and costly. Management did not learn anything from our hypothetical magic potion solution, because it didn't need to do anything to improve the situation, e.g. the problem it doesn't think is a problem seemed to solve itself anyway. Because management didn't learn from these mistakes, it will make them again.

Don't focus on Bob, focus on the job

Since Bob does not care to improve, and management does not care if Bob improves, your choices are really simple:

1. Accept that Bob will be Bob, that he will stay employed at your company until a time of his choosing, and that your company will hire and retain more Bobs in the future
2. Go work for a different company that tries not to hire and retain Bobs

I can't tell you which of those two choices is the correct one for you; it depends on how much you are annoyed by management's refusal to deal with Bob compared to everything else you get out of working there.

At my current job, part of my current responsibilities include cleaning up messes that are made by employees who are worse than Bob. Despite not finding that to be particularly enjoyable, I keep doing it because I generally still like working for my employer in spite of that, my boss at least understands the problem (his hands are tied in the matter), and I am recognized as a valued contributor to the company for doing a lot of this cleanup work. "Valued" as in, in ways that I care about, not in mere words.

You should examine if you feel similarly valued, and make one of the choices above accordingly.

Answer 3

You cannot force someone to do something if you do not have the power to fire them.

It sounds like Bob is content with what he does and how much he gets compensated for it by the company. He doesn't seem to see the value in your suggestions, or he doesn't want to bother.

The only person who can make a difference in this situation is Bob's manager.

If you and Bob have the same manager, bring up your issues to your boss. But whenever you do, focus on how they affect the company's bottom line. For example, say how much time you had to spend to redo Bob's work, or to fix bugs that could've been identified during code review, etc.

Try not to silently fix problems created by Bob. If you have to fix them, make sure your manager and your team knows about them before you start the work. It helps to phrase presentation of these problems in a way that is as non-accusatory as possible but still communicates the fact that Bob is responsible. For example instead of saying "Bob did X" you might say "feature Y has a bug" or "I need to adjust Z in feature Y before I can do W", provided everyone knows that Bob was the author of feature Y.

Eventually either the management will get the message that Bob is causing enough problems to talk to him and make him change his ways, or you'll learn that your company's management is dysfunctional.

If your boss and Bob's boss are different people (seems unlikely given you are on the same team), you still talk to your boss but everything takes longer and is more difficult and you need to have a stronger case.

If you are in a startup and you and Bob have the same boss who happens to be the CTO or something like that, chances are the "boss" doesn't have the time to do anything about the issue and eventually they might fire Bob once they are fed up, or you might leave the company before this happens. In this case the company does not have functional management, basically.

If the rest of the team is on board with what you want Bob to do, you could ask each team member to speak to their boss about this or you could all talk to the CTO in case of a startup with no management to speak of.

Answer 4

Clearly all the approaches taken directly by you so far have not worked out as you were expecting. Your post clearly indicates that no matter what you do, the situation is not changing in the intended direction and likely won't.

The questions that would be relevant in situation would be:

• Are you directly responsible for managing Bob in the capacity of a technical leader or a manager?

• Have you tried to bring this up with the manager, technical lead who Bob, you or both report to? (You have mentioned informing management about it. Was they a direct manager? How did they respond to it?)

• If you think management is only concerned about the output, is this style Bob's of working affecting your work or productivity directly? Or the rest of the team of developers? How have the rest of the team responded to it so far?

Without making it look like a personal thing, if you can present your proposed improvement in such a way that could clearly show a productivity gain in quantitative terms (time saved, fewer bugs) it could present a clear case about making the practise change.

I think it would be better if you can run this through a direct common manager/technical lead and justify your reasonings.

If the cause of an issue can't be changed, it could work to change things such that the problem doesn't arise in the first place. For example, if everyone else in the team is following standard coding practises in terms of formatting and naming, you with the consultation of team could consider enforcing a code review policy before any code can be checked in. A linter could also be installed to run a commit hook, so that the code gets committed only after passing through the linter, etc.

I think this approach could help improve the overall process/output without any person getting called on about certain discrepancies.