Ask HN: What should I do about a lazy and unproductive programmer?

[myceothrowaway]

At my startup there is a three person programming team. There is one team member who has been working here for about a year - I'll call him Rob - who is very competent, but has had issues that I think stem from laziness.

The most experienced programmer on Rob's team has complained to me that Rob will take 3-5x longer to finish a task because he lacks the work ethic to get it done sooner, and he has also complained numerous times (including once on the public team Slack channel) that Rob often pushes buggy or sloppy code to production with the hopes that someone else will clean it up for him.

I was skeptical of this claim at first (a lot of the stuff Rob's worked on was experimental in nature and hard to efficiently track) but after paying closer attention, I now agree completely with this team member's complaints.

The only discussion I have had with Rob so far about this came during his performance review at the beginning of the year. At the time I didn't quite appreciate the extent of the issue and told him very generally that he excelled with the big picture but needed to needed to be more detail oriented. So although Rob's team member has called him publicly I don't think Rob even remotely realizes how poorly he stands. This startup is small (8 people) and very close knit, so I'm worried that if I simply let him go it would come out of left field and hurt the morale of the rest of the company (with the obvious exception of Rob's disgruntled team member).

If the issue was simply him pushing buggy code live I would sit down and discuss the issue with Rob and make clear that this is not appropriate and needs to be changed. However the issue seems far deeper than that, and he has already lost the confidence of the best programmer on the team.

The only time I've had to deal with a poor performer was a much more cut and dry situation, so I feel a lot of uncertainty right now for such an important decision. So Hacker News, what do you think I should do?

[pcvarmint]

Make sure Rob tests his code and gets it reviewed before check-in. Don't single Rob out, though -- make the process universal.

If the lead programmer complains about the new process, make it as minimum a burden as possible, and make code quality the focus of the process. The lead programmer and the third programmer can review each others' changes, and Rob will need one of them to review his changes, which might improve communication between them, and make Rob look better.

Rob may be stuck not knowing what to do, or unmotivated because he does not see a future in his work. If this is possible, then give Rob work which directly impacts customers (internal or external), even future customers not yet realized.

If Rob is working on something which doesn't impact customers in the form of a product or service, this may be demotivating, and he may not know what to do next. Even if he's told what to do, if he doesn't see it having any real impact on the customer product or service, then he may be demotivated and may not be able to prioritize his work correctly.

Rob needs feedback, whether in the form of code reviews, direct communication, or in the form of comparing his work against customer requirements. If the requirements are unclear to him, or he cannot mentally connect his work to customer requirements, he may be stuck or unmotivated, even if he's very bright and has been assigned specific tasks.

[new_hackers]

Here is something to weigh against:

Is the "most experienced programmer" also the hardest working hero in the group?

Is the "most experienced programmer" working at a sustainable pace for your company, including themselves and others (including Rob)?

Have you truly identified 1) is Rob really pushing buggy or sloppy code, and 2) is his intention really so someone else can "clean it up"? Perhaps Rob is spitballing and trying stuff and trying to contribute to the greater collective of the "correct" code. Does your process support this kind of exploration?

Has Rob worked with any other team members? Do they have the same feeling?

Could it be that your "most experienced programmer" is also an *hole control freak, and you are seeing the "most experienced programmer" with rose tinted glasses? What happens to the team if you remove the "most experienced programmer", do the rest of the team thrive or at least sustain?

[myceothrowaway]

I would say that the "most experienced programmer" and the third team member (who I haven't mentioned at all) work equally as hard. They are both very competent, but the third team member definitely looks to the "most experienced programmer" for guidance.

I do not think Rob is purposefully pushing buggy code, I just think he has no desire or motivation to properly test it.

The third team member has no negative complaints about Rob besides saying that he prefers to pair program with the "most experienced programmer".

From my own perspective if we removed the "most experienced programmer" the team would sustain in the short term, but it would really struggle in the long term.

The "most experienced programmer" speaks highly of the third team member. That doesn't mean he isn't a jerk or a control freak, but from our daily stand up meetings it feels like him and the person he speaks highly of are efficiently delivering high quality code while Rob is having trouble delivering things at a similar pace and has complaints about pushing buggy code.

These complaints have been going on from the "most experienced programmer" for 6-8 months now and I think part of the reason it has festered this long was because I was not sure at the beginning whether there was any credence to what he was saying, but now I feel like his complaints are very valid.

[new_hackers]

It sounds like you have considered all the angles. I've just seen situations where management was blinded by the "hero programmer". However, with the perspective of the third member, it sounds like Rob is the weakest link (BTW, someone has to be the weakest). If he really is messing up your team's mojo, then either work towards the goal of "Making Rob Better", or make a business decision and let Rob go.

[elmojenkins]

Sounds partially that management wasn't doing their job. I think more intervention early on would have been best. Bluntly describing the issue, describe why it is a problem, and provide examples of expectations (or what Good/acceptable looks like in your opinion). You really can't fault someone for not hitting your expectation if you never clearly told them your expectation. Nt good to allow things to fester.

You wouldn't let a wound on your body fester until your only option is amputation, right? You'd go see the doctor and intervene early on, to stave off the amputation.

[myceothrowaway]

>Sounds partially that management wasn't doing their job. I think more intervention early on would have been best.

Since it is an 8 person company I am the entirety of management, and I would agree. In retrospect I think I did a very poor job.

Since I can't go back and change that, do you think I should do those things I probably should have done months ago, or should I skip ahead of that?

[elmojenkins]

Tough to say. Only you truly know how 'hopeless' the individual may be. Ask yourself if you see ANY room for change - can the ship 'course correct' and still reach it's destination? OR - is the boat just too far off course.

[zer00eyz]

If you don't have HR, find an HR professional for this.

Performance improvement plan is what your going to put him on.

Your going to want to document what is going on, and your going to want to be out about why your doing it. The HR professional is there to make sure you hit all the marks before you let him go. The last thing you want is to "fire someone" and end up in court.

Some people shape up, some people quit, some people you have to let go.

If you here there are issues "at home" then you may be more sympathetic, but stick to the plan and be a compassionate ear if you can.