How to help senior developer who is beyond helping

Question

I got recently promoted as a manager in a small company (less than 20 people), I have only been in the workforce ~2.5 years, and I'm a lead developer in our project. Senior developer has been working longer than I have been alive, and been part of the project over a year now. Senior developer has C/C++/C# background, not python.

Problems with senior developer are:

• Forgets half of the requirements, or if he doesn't understand them he totally ignores them
• Doesn't test his code, and often commits broken code
• Doesn't think validating values matters and doesn't even care if some exceptions are not catched
• Doesn't follow common style guidelines (PEP8)
• Forgets how to code in Python, and implements crazy solutions even for simplest problems
• Adds random files to project and sometimes deletes real files. Sometimes reverts others changes. (git svn rebase ftw)
• Often I find him refactoring working code to not so working code. (His favorite activity)
• Avoids communication with me

Things that I have tried with him:

• We started doing design documents and reviewing those -> Doesn't follow them, or doesn't do them because "there are open questions", so starting the implementation is only reasonable solution for him.
• Tried to talk to him that his performance/quality of code is not acceptable
• I have always teached him Python tricks and how to use them correctly, when I see him using some python stuff incorrectly
• I have to review everything he commits and fix his bugs, now I think he expects me to fix everything for him. And more than other I have to implement rest of the requirements.

Problem is that I don't have power to fire him, customer pays the company no matter how little we are doing, so no pressure from them. Since customer is paying based on the used hours, the big boss doesn't want to fire him either.

Currently I find it easier and faster not to give him any tasks, deadlines are getting closer and it is faster to do them myself. I'm actually considering for changing the job because of him. He is nice guy other wise. Currently project has 1 other developers, and he is fine.

Time to time The big Boss tells me get his performance in decent shape, he knows how bad things are, we had to cancel one project because senior developer was lead developer in that project, so now he is my problem.

Are there still steps to help him to become better developer, or is all hope lost?

Answer 1

My first idea was to add a tests, verified by a continuous integration system, so that it would limit the amount of harm he can make to your project, which is also the point of li x answer.

Then, there is the issue that this guy is actually making money for the company, in a perverse way. By having the customer pay on the hours spent, it turns to be a monetary advantage to have someone that is undoing other people's work. It would be like being contracted to build a wall and having both a bricklayer making a wall and another employee tearing it down.

However, in the long term the customer may change his mind (perhaps to never again use your company services) if he finds out that you are doing that (either inadvertently or on purpose), and it might be considered negligence from your part, too.

Your boss is probably not having those machiavelic reasons for not firing him, though. At this point, you have a person whose work is not useful at all to the company. I would suggest changing him to a different position. You state it is a lost cause to make him code properly python. But perhaps he can use make a good User manual. Or test the program on its different iterations to verify that the features work as expected. Technically, he would no longer work as a developer. However, it is something that often enough lies on the developer team itself and, being a small company, I guess you don't have a dedicated team for that.

In any case, a bad tester that that only occasionally finds a bug will be more useful than the anti-developer he seems to have been when doing work so far. Thus, any task that keeps him busy is probably beneficial, even with a low return. And developer skills, allowing him to read and understand the code, are useful for directing the test cases, even if he is unable to write proper code (while it's not that bad if he can't).

A potential problem with this approach would be that he managed to test the program too fast (maybe because he is skipping half of the requirements?). The next step would be that he coded automated tests for checking the project requirements, so he doesn't need to spend time continuously performing the same boring tasks, and they are performed consistently every time. (Obviously, many iterations will be needed until being able to have a complete coverage of the requisites)

Answer 2

You've got a nice long list of things he's bad at.

What is he good at?

Find out, and set him to that work instead.

Answer 3

As his manager, it is your job to hold him accountable for his lack of following procedure. I would start a paper trail in this case as this employee seems unwilling to alter his bad habits.

If the paper trail does not work, then put them on a formal performance improvement plan [PIP], working with HR, with clearly defined goals, measurements, and a time frame to achieve the goals.

If the developer fails to meet the objectives, you should be free and clear to let them go, and your mind should be free of guilt. He may leave on his own as well, which will solve your problem too. Hopefully this serves as a wake up call and they get their act together.

Answer 4

"I got recently promoted as a manager" - then start learning to be a manager. Like it or not, from what you have described they are doing the job they are being paid for, but you are not.

You have a employee that you appear to have given up on - that is not good management. You are doing their work for them - that is not good management. You are allowing them to disrupt the project - that is not good management.

This employee is clearly (and possibly justifiably) disgruntled but instead of dealing with the causes of their complaint, you are aggravating them. It doesn't matter whether you are a better coder or if you know the subtleties of python better then he does, because your current role is a manager not a coder and the job of a manager is to get other people, including him, to want to do what you want them to do. You want him to produce code that meets your companies norms. Find out why he doesn't want to and change something so that he does want to. In the extreme case, you can force him to choose between doing it the companies way or working for a different company, but you should consider that a failure on your part no matter how it turns out.

Answer 5

Suggestion

As much as this may pain me to suggest have you considered implementing something like TDD or BDD testing into your pipeline? From my exspierence a well developed test suite even if not implemented in a strict manner can do wonders for under performers. This won't speed up his development but what it will do is make the goal posts more transparent when it comes to what he needs to do to get his patches up to speed. Better yet things like code coverage can be a great tool to push motivation as he'll have a visible metric associated to his work alongside the obvious benefits.

It also means if he doesn't get the tests to pass he can't move on to more destruction.

My Opinion

Sometimes in teams there is someone who just doesn't fit the mold and it really shouldn't be on your shoulders, but it is so you'll have to deal with that internally. Ultimately as lead you need to make the right decisions for the team and if it means limiting what he can work and do then it has to be that way. I'd personally make every opportunity to make it evident if he doesn't improve there is only so much hand holding you can do. Work with upper management and if he's still not working out, there is a point at which you need to call it quits and inform management bluntly that it's not working out and your position is he needs to leave or move on to a different part of the business. Some of the things you've mentioned if done serially would put you out of a job in a lot of companies I know.

My Unpopular Opinion

Your a manager and you've got direct contact with upper management, it might be time to line up a replacement if his behaviour continues.

Answer 6

A senior developer isn’t supposed to be senior just by getting old and being there for a long time, but by being a good developer. This person doesn’t sound like a senior developer.

I suggest a one- to-one where you explain the situation, and that his work isn’t satisfactory, that he isn’t actually worth his salary (is he?), and what he thinks he and you can do to change this.

Answer 7

I honestly think you answer lies in your title "how to help someone who is beyond helping". You think he is beyond helping. I think it sounds like he is beyond helping. He might actually just be beyond helping.

If this was a junior developer you would, at maximum, accept this kind of performance for the first couple of months - after that, they need to deliver. That's maximum, I think hiring anyone who can't produce code on day one is a risky hire.

This guy carries the title senior, he is supposed to be the one mentoring junior developers or at least performing well.

Answer 8

You have tried to persuade him to change, and that did not work. The change must be compelled, which requires disciplinary action or termination--thus, management intervention.

Currently I find it easier and faster not to give him any tasks, deadlines are getting closer and it is faster to do them myself. I'm actually considering for changing the job because of him.

This is what your boss needs to know. Depending on your relationship, you'll have to decide whether to focus on the looming deadlines or your desire to change jobs.

Since your boss is concerned about losing billable hours, you can point out that replacing $SeniorDev with an effective developer will result in the same number of billable hours while improving morale and the ability to meet deadlines. This works out better for both of you.

Answer 9

My experience in software is that if a developer doesn't understand the importance of testing and verifying code before checking in, then there isn't a point in trying to work with him or her on it. It's best to move on and to focus your efforts on convincing others of the necessity of doing so.

Answer 10

It seems his job is to produce billable hours, not software, and he is good at his job. Your customer is stupid, your boss is unscrupulous. The employee is beyond help.

You have two choices: Stop caring, or find another job.

Answer 11

First of all you have not explained what are the requirements and skills of the senior position in your company. A senior role meaning skills,capabilities and expectations differ dramatically per company. He is a senior there so first of all you need to check if he fulfills the criteria defined by your company.
Concerning the situation and the issues you point out. I think you are trying to address too many things at once.
Start with the most important which is the fact that the code is not functionally what the customer needs since the requirements are missing.
After you address that you can move on to how the code could be better moving eventually to how to code properly in Python.
If you start with such discussions it is easy to get side tracked because developers have usually varying and quite strong opinions on such points.
Maybe the guy is overwhelmed or doesn’t like Python and it affects his performance.

Answer 12

From the way you described this, I would probably bucket this developer in the "not very good" department and question whether I want them as part of my small team, where each developer has a huge impact on everything else. Poor developers can hide in large shops and work on partitioned areas of code that have little to no impact on the rest, but small shops typically have everyone able to touch, and therefor break, other parts of the code. Pulling such a developer out of the system is often a case of addition by subtraction. You should explain this to the big boss, that you'd rather have him not coding at all in order for the other developer and yourself to get more done.

If the issue is all about billable hours, then you can also discuss with the big boss about how replacing this person with a more junior, cheaper person, can be a double win. You get higher margins on the billable hours and the replacement, while not being able to maybe tackle the harder problems, can at least be productive to move forward the easier parts of the solution while not damaging others' work.

So you make this a business case and present it to the big boss as a way that the business is better by replacing the problem area. As a manager, you will learn that your role expands from just focusing on the tech to also thinking as a business owner, and understanding what the bigger picture impacts are.

As for how to actually coach this person, what I usually set up early in a shop that I'm running is a solid, well defined and socialized Definition of Done. This is the line in the sand that says no work can be considered completed (depending on your setup that can be merged to master, pushed to prod, etc) until it's met all the things in your DoD. Then you enforce that with ALL of the work done by the team uniformly. So if said developer doesn't complete their tests, the work is stopped in its tracks with an explicit statement of "missing adequate tests" and the developer has to finish that before they can move to the next task.

Yes, this does mean you have to now use some of your time to audit the work of your shop, but that's part of management. You can also use this, or other types of peer review, to walk through the proposed check-ins and catch some of those harmful refactors that you mentioned before they affect the rest of the code base. Through your DoD you set gates around quality (ie -- passes a PR) that prevent damaging behaviors.

If you apply these gates and truly stop any developer from pushing partially or poorly done solutions, then it will become quite obvious who gets how much done how fast. You can then use this sort of tracking to quantify the value of each dev, helping you make the case to the big boss that I spoke of above on actual productivity and bang for the buck of each developer on the team.