How to deal with an inept and self-centered programmer?

Question

This is a sensitive question, hence I post this anonymously.

Over the last year, I have been working as the senior programmer for a group of existing and new scripters. This group is lead by a separate lead. I am the programmer of the code's script interface the script programmers work with. One of the new guys has caused me countless headaches…

Things he does:

• Complains about why something doesn't work anymore NOW (it worked yesterday and he didn't change anything, of course).
• Insists to keep going down a troublesome road instead of making the decision to reduce the feature set (he almost has all the bugs fixed anyway is what he's telling us).
• He is quick to ask for a new feature that he insists is needed for his code to work properly (in most cases he does not need it, it's just easier for him to ask someone else for the solution).
• He can't debug… He often neglects to use the available debugging features in our engine to nail down his problems (any other scripter has no problems finding and fixing their bugs)
• he makes assumptions about code changes by other programmers causing him problems (it's usually his own fault).
• He keeps making suggestions for improvements that are either ridiculous in scope and complexity (he says it's something "for the next project") or they will primarily help him… In any case it often shows he still has no understanding of our engine.
• He can't formulate a specific, concrete question I can help him with… Usually you have to pose a series of counter-question to get the specifics (e.g. "Which ID is it?" "What command are you using?" "Is it just one or all of them?" "When does it happen?" "Are you able to reproduce it?" "What brings you to this conclusion?")
• He is vague in describing his problems and answering questions (often his descriptions include: "maybe" "possibly" "could be" "I believe" "sometimes"… I think he's hiding something, I'm just not sure what or why.)
• He keeps reporting B and C bugs as A bugs, justifying it by saying it keeps him from finishing his tasks (I keep telling him what an A bug isn't.)
• His default question, when he's having a problem, is: "did you change anything at xyz?" (Of course I did not.)

Overall, this guy has completed noticeable less tasks than others while requiring a lot more "babysitting". Others come to me with questions and tasks and we come to a conclusion within seconds, for larger problems within minutes. With that guy, it takes minutes just to get to the point what wants to tell me, and hours to understand his problem altogether.

Now my problem is this:

He is supposed to be in charge for the scripting interface to our engine (design & feature set), e.g. he's becoming the "Product Owner" (because that's what he wants to be, as he keeps telling me).

I was shocked to hear that because honestly, I was expecting him to be let go. So I am going to talk to his lead.

My questions to the community are these:

Did you have to work with someone like that before?

How would you deal with this person if he were your "product owner"?

How would you talk to his boss to convince him that making him the "product owner" is a terrible idea?

How do you build an argument against someone who is technically inept but convinced to be a capable programmer? The argument needs to be understandable by a non-programming lead.

[EDIT] Thanks for all the responses so far. Great ones overall as well.

I will take these next steps:

• Talk to my peers, innocently inquiring them about his work and what opinion they have of him (some of my peers I can ask straight, so I'll try them first.)
• Talk to his boss, find out why he is product owner and what his role will be.
• Eventually let his boss know that I don't see him taking over this role, arguing with lack of technical comprehension, inability to communicate effectively, lack of scope assessment and continuous issues of mismatched necessity/priority/applicability of his tasks/bugs.

Answer 1

The one time I worked with someone like this, we were completely unable to improve the situation ourselves. Fortunately, the person in question left the company of his own accord shortly thereafter.

It sounds like our situation was similar to yours: somebody was hired to do a job he could not do, and unfortunately, that inability is not obvious to all the people who need to know. Sometimes, nothing you do can change that.

But maybe there is a way to reach this person. Maybe he is simply insecure because he knows he lacks the knowledge he's supposed to have, and maybe one of the other junior programmers would be able to help him with that ... maybe under the guise of asking for advice, he could walk the problem programmer through steps that everyone in that group should know.

I wish I could tell you from experience ...

Answer 2

Document everything. That's step one. Every time you feel you have to deal with issues with this programmer that is above and beyond what you would consider normal - document it.

If you can, start giving him concrete deadlines. "If you can't fix bug #xxxx by date and time yyyy - we'll have to hand it off to someone else." Document this.

I wouldn't approach his boss until I had documentation to show. Otherwise, you run the risk of (possibly) causing people [to think that] you're out to get this guy.

Every time he asks for new features - point out that the current features are not solid enough, so adding new features is out of the question.

etc. etc.

Basically, become a hard ass with him - document it - and once you feel you have enough information, then go to your boss with it. Let him/her decide what the best plan of action is.

Answer 3

• he can't formulate a specific, concrete question i can help him with ... usually you have to pose a series of counter-question to get the specifics (eg "Which ID is it?" "What command are you using?" "Is it just one or all of them?" "When does it happen?" "Are you able to reproduce it?" "What brings you to this conclusion?")
• he is vague in describing his problems and answering questions (often his descriptions include: "maybe" "possibly" "could be" "i believe" "sometimes" ... i think he's hiding something, i'm just not sure what or why)

I think these two points are just something you'll have to assume when dealing with most people. I can understand that if you're already frustrated with him that these exacerbate the problem and yet they seem like common communication hurdles.

Have you tried having a meeting about these communication problems with him and his direct manager? If you could make your case in a minimally non-confrontational way I think that may help.

Overall it sounds like this employee needs to grow and mature as a professional. You would be helping yourself and others if you could work to create an environment where this employee is more or less forced to grow. I guess the alternative is that he or she leaves.

Answer 4

Here's what I would do:

1. Try and figure out why that person is being made the product owner. Maybe that person has some gift you're not realizing.

2. If you're boss is making the desicion and you can't figure out why, then maybe it's time for you to find employment elsewhere. Something like this can be the sign of a company that is going into rough times.

3. If you don't want to find a new job, then you'll most likely have to ride the storm out. Generally people have to come to their own conclusion about something like this (both the person and the manager). I hate to say it, but you'll have to let the product owner fail on his own accord. You should continue to do your job as best you can and try and help the him out. If he won't take your advice, that's his fault, but him failing because of your attitude (not saying your wrong) won't win you any friends and it will make you look petty.

If you're going to talk to your boss about it, I would say something like "While I don't agree with your desicion, I will do my best to keep the product to the level of quality we are accustomed to." Telling the boss he/she's wrong doesn't put you in the best light in most cases.

Answer 5

The better question is, now that this person is a peer / colleague of yours, how will you interact with him and management to create a productive environment? What demonstrates, in objective and expressive language, where the productivity faults and strengths are?

"Let all the poison's that lurk in the mud rise up!"; that is, creative objective measures to demonstrate your team's strength, and how your team and his will work together, and when he fails it will be obvious. If you have stepped forward and have said "Given the restructure, we want to map out for you in management, how my team and the new leader(aka problem guy) will succeed", and when the when problem screws up because of incompetence, it will be clear. You need to take a positive step and put things in positive terms, but you to need to express clearly the areas that are the problem guy's responsibility.

If you take the tactic "Don't put problem guy in charge because he isn't ready" you may appear to be motivated by other factors than the pursuit of quality. It may mark you as the impossible one. Rather, you need to establish the working conditions for the teams and when he fails, it will be known.

Answer 6

What you haven't said is what measurable negative effect he is having on the project or team as a whole. It's possible to infer a lot from your obvious frustration, but you need some concrete measurement of the adverse effect he is having. So unfortunately you are going to have to start committing some of what you are encountering to a written form so you start to build a record of the problem. (Some other answers have excellent suggestions on that).

Personally, in your position as a colleague rather than his boss I would go straight to that person's boss and just have a quiet word. You don't need to be nasty or angry or frustrated, just give them a heads up that you see a problem brewing and want to keep them in the loop. Do it informally over a coffee or something so you are not making a federal case out of it yet. If your management are any good they will appreciate the early warning and should care about it. You should probably also tell your boss what's going on too.

Whether you can fix the situation is unfortunately unlikely. The most probable outcome is that you'll have to put up with this person until a firm reason emerges for them to no longer be around. My experience suggests that this personality type is not easy to bring into the fold. If he has really talented management then they will find a niche and get the value out of him that he probably possesses. It is quite common for there to be a gap between people's impression of themselves and the reality of their abilities.

Answer 7

Talk, talk and talk... if you are afraid about showing all the cards on the table, just send an e-mail with a link to this article to the project leader... hopefully he will know how to deal fast and efficiently with this problem.

Answer 8

This is a tough situation and I would recommend an iterative approach. What I mean is start small and work your way up to costing this fellow his job.

First, try and help him. When he makes it difficult for whatever reason, explain to him why the way he is going about things is making it difficult and offer suggestions to smooth the process. You may proceed even slower and organize some off site lunch with this fellow and some others so you can get to know his frustrations and he can get to know yours in an informal setting. Depending on the guys personality this approach would fall flat or work wonders.

If that fails, start documenting your issues. Do not use hyperbole, stick to the facts. This is your ammunition to confront this individual with problems (and ultimately, if all else fails, to his boss). It will be tempting to jump all over this guy at every opportunity. This will destroy your credibility, stay perfectly professional at all times. With each problem that you document, sketch a solution of your own and try to see things from his perspective as much as possible.

If you have the power to do it, put the bug in the higher up's ears for SCRUM like stand up meetings where everyone's daily goals and frustrations are aired in the most public way possible. On top of that, code reviews are a wonderful way of weeding out the chaff and/or getting crappier developers up to speed. (This can be touch to get management to agree to in my experience, but can be a real game changer, culture wise, for the better).

Ultimately, if you have tried your best to help this guy out and it doesn't work out and you have to talk to his boss first -- get your boss behind you. Second -- come at his with the phrase 'value to the business' in mind. How is this guy hurting business value or value to your clients? Be concrete, don't exaggerate, be professional, offer solutions. Remember that if you take it to this level, you have to have a solid case because you are calling his boss an idiot too for keeping him on and elevating his responsibilities. Tread carefully and good luck.

Answer 9

If he's not part of your 'department' and you're not his lead, why are you wasting your time babysitting him?

Be "too busy" to help for a while, and see if he figures things out on his own or starts bothering someone else.

Defer his questions to his lead, or if that is not feasible set up a meeting with his lead to discuss as a group his questions/suggestions. It sounds like this guy is really bugging you because you're "safe", i.e. you don't have the authority to fire him for incompetence and you have the knowledge to help him appear to be competent.

"Documenting" isn't enough, you would still appear to be out to 'get' him.

Instead, stop enabling this behavior; stop helping him in isolation. If you must help him, have witnesses.

Good luck!

Answer 10

As already said here, the best way to deal with this problem is to document everything.

If there is a bug to solve, ask him to write down his assumptions before fixing and final solution description. Once a while sit with him and pass over the records.

If he asked for a new feature/interface/whatever - ask him to write a "change request" document with current state assesment and improvements/changes proposed (including time estimation).

Answer 11

I work for a large company and many developers show the individual characteristics you mention, but never all of them in one person. Congratulations!

Our code base has a centralized architecture and I am on the security team. Whenever someone experiences a crash or issue somewhat related to security (logging in, authorization, or just saw a security warning in the logs) they immediately assume we caused it and send us an email asking why their application isn't working.

The only thing you can do in this case is tell them to do the rudimentary debugging, such as getting a call stack, core dump or something that tells me what in MY stuff is going wrong. This is what I suggest you do with this guy for some of his tricks.

If he is asking for a feature, make him write something up detailing why he needs it and nothing out there now is supplying this functionality. When you have it in writing, it's easier to disprove and/or forward to managers for support.

I also know a guy who can't formulate questions. I just keep asking him "what do you need to know?" I think he just is working through the problem in his head and I don't hold it against him.

Either way, get him to write things down and tell him to provide you with all the information or you can't help him. It works pretty well for me!

Answer 12

Did you have to work with someone like that before?

• Yes.

How would you deal with this person if he were your "product owner"?

• After realizing that he is inept. I would tell his supervisor what I thought, and ask for a replacement, or someone to train him how to do his job.

How would you talk to his boss to convince him that making him the "product owner" is a terrible idea?

• I would present him with facts. I would also attempt to keep a business slant on everything. For Example, "employee costs X hours a doing this task where all others cost less than Y hours a day.

How do you build an argument against someone who is technically inept but convinced to be a capable programmer?

• I had to work with someone like this. I tried to convince, but failed. I found that my employer valued my opinion a lot more after he let this "guru" go. Some people are great talkers. Some people take a first look and never change their opinion of you. Put those two together and you are screwed.

The argument needs to be understandable by a non-programming lead.

Give your lead the same list you gave us. Also cite specific instances that the supervisor can see. Explain common sense says the trouble make should be let go, but at the least don't give him more responsibility until he shapes up.

Answer 13

Well, you're essentially asking the question "How do I deal with a difficult person?" -- a subject that's covered in many, many business books and articles, and something we all face many times in our career. Looks like this guy is more of a pain than most, though!

First of all, consider taking a personal inventory -- make sure that you're not the one being the jerk, and reacting poorly because you perceive him as a challenge. It's not very likely, but make sure your own house is clean first.

The development community seems to grow its own species of jerks -- determining which breed he is is important to how you deal with the problem.

Some are really, really good technicians, with no people skills. They can be valuable to a project -- incredibly valuable, sometimes -- but can also be poisonous. If his code is good -- especially if it's amazing -- then that might be the jerk you're looking at. They're a cost/benefit analysis waiting to happen -- if they're really good, then you might have to suck it up and keep them around.

Some are really bad programmers, and hide their incompetence behind their veneer of jerkiness. Get rid of them quickly, as don't produce and still manage to damage the team.

The last group is the most likely -- a moderate programmer who happens to be a jerk. It's hard to know what to do about them without feeling out your co-workers. I mean think about it -- if he's a real jerk to you, who works with him from time to time, imagine how much of a pain he is to his closer co-workers. They must be fed up with him already, right?

Finally, it boils down to politics, about which I can give little advice. If you have an open environment, and you know his co-workers are tiring of his crap, then talk to his boss. If he's his boss's toady, then you can't do much more than get your boss to help a bit.

After so many words, I find I've written little of value. Post here and let us know how it works out as time goes by.

Answer 14

I am going to talk to his lead.

I think you should talk to him first and tell him what you think he is doing wrong. Show him those various bugs/issues/whinig/ and the 8 points you posted. If he doesn't change, you can at least say that you tried everything before talking to his boss.

Answer 15

There are a couple of things you could do : a) Pair him with another person in the team, so that he could ask them first before bringing it up to you. You could do that with different people (1 person for a week or something like that) If every other person in your team has the same opinion as you have about this guy then you can have a conversation with his manager. b) As someone else suggested earlier you could try to have some one-on-one chat with him and help him become productive.

As for him being the product owner - would that mean he wouldn't be coding much ?? Or does he get to have the final say on completeness ?? Am sure there is some reason for him being made the product-owner, some thing that you might not be noticing yet.

Answer 16

Your development process should already be taking care of this for you. Don't treat this as an isolated incident- work to put in place an effective development cycle.

Answer 17

Are you sure its him? Seriously, there's a Despair calendar that says "the common factor in all of your failed relationships is you", there's the usual nugget of truth in that.

---

complain about why something doesn't work anymore NOW (it worked yesterday and he didn't change anything, of course)

Did he change anything or is it that he has an outdated version, are you guys making changes too quickly for the product/internal customers to keep up with. Are you communicating changes effectively?

insists to keep going down a troublesome road instead of making the decision to reduce the feature set (he almost has all the bugs fixed anyway is what he's telling us)

Most companies require more features, not less. This is quite normal behaviour for a product lead.

he is quick to ask for a new feature that he insists is needed for his code to work properly (in most cases he does not need it, it's just easier for him to ask someone else for the solution)

That's your job - working on the engine so others do not need to write the features themselves, if everyone did that, you'd be out of a job!

he can't debug… he often neglects to use the available debugging features in our engine to nail down his problems (any other scripter has no problems finding and fixing their bugs)

Does he know how to do it, do the other coders in your group know how because they've sat together and shown each other, whilst he's been left out?

he makes assumptions about code changes by other programmers causing him problems (it's usually his own fault)

Assumptions make an as.. you've heard it, k. But perhaps the changes are not well documented to explain it fully to someone else outside your immediate group who are well-versed in the engine.

he can't formulate a specific, concrete question I can help him with… usually you have to pose a series of counter-question to get the specifics (eg "Which ID is it?" "What command are you using?" "Is it just one or all of them?" "When does it happen?" "Are you able to reproduce it?" "What brings you to this conclusion?")

Some people are poor at describing the problem in a way that makes sense to you. You should meet some of my customers! Lord, please meet them and take them away. Still, I have to make the effort to understand them, not the other way round.

---

OK, so I've played Devil's advocate here, but lots of coders make assumptions about others that are unnecessary - they do not follow or understand your viewpoint, they do not have your knowledge or skills or understanding of the product.

I think the best attitude all round is to organise the group so that he is the 'product owner' - ie more of a customer to you guys than a fellow coder. He can then control the featureset and business requirements while you get on with the internals. That kind of approach usually makes everyone happy with their roles if they can be good at them.

Answer 18

A similar question was discussed here. I believe the prevailing wisdom was to be as diplomatic and objective as possible. Drama in the workplace sucks.

Just a little extra on this topic: one situation that doesn't seem to get a lot of attention is that sometimes the "useless" guy is just being scapegoated and/or neglected by his team. I've been in that position before--wanting to work, but being honestly unable to find a way to make myself useful due to mismanagement. This does not sound like what is happening in this particular case, but be aware in general that you may need to take a closer look at the situation before you hang somebody out to dry.

Answer 19

It's rare that a technical solution might help what is fundamentally a "people" problem, but I think it might in this case.

It sounds like some (not all) of the concerns you have about him could be clarified if you have a stricter testing regime, including unit testing and regression testing. If you can isolate his code changes, and show that before they were made, the code passed unit testing, and that after, the code failed some unit tests, that's a pretty clear indication that the problem is of his making, and he can't reasonably accuse others of making the changes that broke the code.

Of course, if the hard evidence of the unit tests don't convince him (his response might be to say the unit tests are wrong), then you'll clearly have to treat it as a "person" issue and look at the suggestions in the other answers.

Answer 20

I think you have done a lot from your side. Documenting and trying to show your bosses the guy is an "autist" is imho a complete waste of time. Stupid people remain stupid. You seem to be in a spirit where the team goes on. He seems to be in the spirit of "Me and the rest of the company". These kind of guys are terribly annoying and my advice is to find another job or better start your own job so you can have the freedom of doing what you want.

I remember Joel Spolsky in an article saying something like "Don't hire an antisocial guy".

Answer 21

Almost by definition, all programmers are self-centered and have a God complex. In fact, I'd say all nerds and geeks are this way. The best solution? Pretend you are learning yourself, as you steer him towards being a little easier to deal with. This way you look less demanding and more like you're on his level. I've used this tactic to help people become better coders without them knowing I wasn't actually learning anything new myself.