16

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?

  • 5
    Give him the "window seat", seems like a win-win for everybody. – RandomUs1r May 15 '18 at 21:43
  • 3
    Make daily local backups of your git repository. It is perfectly possible to destroy history for an experienced user. – Thorbjørn Ravn Andersen May 16 '18 at 9:24
  • 3
    the very first thing you should do is remove his rights to the git repository and only allow him to work on other branches and pull request. If he's making a mess with others' code he should be prevented to do so. – BgrWorker May 16 '18 at 15:28
  • 8
    Step 1, never and truly mean never, fix someone else's code. Critique and send it back for them to fix. – HLGEM May 16 '18 at 17:04
  • 1
    By his attitude and behavior, he is not acting like a Senior Developer. He is acting like a rogue intermediate (Developer II) who "knows better" than the project lead. Some people should never be promoted into a senior position even if they have seniority. Regardless of language, it doesn't sound like he should have been a senior developer for C/C++/C#. – Phil M May 22 '18 at 17:55

12 Answers 12

23

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)

  • 3
    You get an upvote alone for the use of 'machiavelic', good job on the answer. – li x May 15 '18 at 22:24
  • 3
    A CI engine is great for catching build breaking commits very fast. Do this first. – Thorbjørn Ravn Andersen May 16 '18 at 9:26
  • The issue with the concept of adding tests to run through the CI system is that the dev in question doesn't write enough tests to start with. In addition, as someone that "forgets half the requirements" he will not only miss the implementation, but will also miss the test cases as well, masking the problem. Unless your suggestion is to have an additional person write all of the tests first, I don't see how this helps. – Zymurge Jun 1 '18 at 15:56
11

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.

  • 2
    Actions should have consequences. A PIP is a great idea. – jcmack May 15 '18 at 21:09
  • This seems to me to be the right answer. If the OP is not in a position to instate a PIP then they should talk to their manager to clarify exactly how they are expected to be responsible for someone's work without any of the tools to actually improve the work. Perhaps the answer might be improved by including something along those lines? – Cronax May 16 '18 at 8:39
  • I agree with this answer as well. Also, the longer you wait to correct, the worse it will get. People always think that personal issues like this will get better... they don't... you only get better at ignoring them. And as his manager, you will be the one to blame when the crap hits the fan. You cannot fire him, but you can write him up and document issues that can be used to fire him if he does not work on improving. – Phil M May 22 '18 at 17:50
  • 1
    +1 for the PIP. OP may not have the power to fire him, but as this employee's line manager he is responsible for assessing performance. The main thing is following the handbook to the letter. Ensure all statements about performance are backed up by evidence. Give him the option of retraining or moving positions, and ensure the PIP includes milestones for him showing improvement or failing to improve. And of course his next pay increment should be zero, or be a pay cut if the PIP resolution is that he's demoted. – Graham Mar 4 at 18:17
9

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.

4

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.

  • I like the TDD idea, since company is also going now crazy with the ISO27001 and ISO9001, so it might be good fit to our processes – Miro K. May 15 '18 at 20:53
  • 1
    Ahh we've had those down for quite a while, testing when implemented correctly can do wonders for productivity and security which is great for commercial products. Though I must say this approach with some people just shows there true colours when they start attempting to cheat the tests rather than actually complete them.. – li x May 15 '18 at 20:55
  • Trying whether your code actually works would be a good start. – gnasher729 May 16 '18 at 7:06
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.

3

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.

  • Somebody can be senior developer in one language and be a junior one or even anti-developer in another language. – jo1storm Jun 1 '18 at 14:29
  • 1
    I don't know, @jo1storm. Yes, a large part of being a Senior Dev depends on the language, and I will definitely look a lot more silly in some than in others. I would still commit working code though, do PRs, and improve with time, as I am sure most other Senior devs I've met would – bytepusher Feb 4 at 19:46
2

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.

1

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.

  • Firing the people might be bit of a legal problem here in EU, doable, but takes time, and finding new people is hard now since everyone is working. Definitely a good arguments to present to him. – Miro K. May 16 '18 at 17:23
  • Reassignment to a project compatible with his coding preferences is ideal, but the size of your company might not allow for it. Still, your manager may have other work that he could do. – DoubleD May 17 '18 at 19:16
0

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.

-1

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.

-1

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.

-1

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.