most professional way to tell a developer they are no good

Question

What is the most professional way to break it to a developer that they're not very good?

I haven't been a developer for as long as some of the others out there.

But I have already had to deal with some really crazy people.

What is the best way(s) to stay professional and critique a developer who really is horrible at his/her job, keeping in mind that it's a small world and you might HAVE to work with them again.

EDIT: Should have added where I am coming from :

• I am an upper level developer but have no power to hire or fire. Just venting frustration with my boss and other devs.
• Management moves slower that molasses and has been know to hire with out letting devs interview candidates.
• And yes, a few have been crazy enough for me to be worried about my well being should they decide to snap..

Answer 1

maybe you can start doing code reviews (as a whole team) and point out flaws in the code, also ask him/her why he/she did things a certain way

Answer 2

This is something that's regularly covered in the StackOverflow podcast :)

Joel doesn't have much patience for bad programmers...

Answer 3

What will you do if they think you're no good though? You can lead by example, if you can persuade them to listen. This will be hard if you are no position of authority, so tread softly and get people to like your ideas.

Answer 4

it is NOT a small world.

chances are, you probably will not have to work with them again. from personal experience, i have yet to see the same person at another gig in more than a decade.

having said that, i would go with the norm of behaving in a team, classroom - any public setting where there is bound to be regular interaction - i use a baseball bat.

Answer 5

It depends on your developer. Some want you to be honest but polite, others want you to be some kind of what SQLMenace said.

Let them realize for their own, they are not good.
Ask kind questions, if there are alternatives to their actions.

Ask yourself: How would you like to be told you're bad in your job. It's even easier to imagine how you don't like to be told.

Answer 6

Rather than telling him he's bad, I would rather say something like: I would do it this or that way, what do you think? And try to open the discussion.

Answer 7

As with any interaction with people, focus your communication in a positive direction. Keep the discussion focused on specific coding techniques you would like the developer to use to "improve" their code - and explain why it improves it.

Do those type of personal "code reviews" one-on-one, unless the advice is presented generically to your team (without singling out any particular developer).

Documented coding guidelines help here, since they are obviously for everyone and not just for picking on the particular developer.

Ron

Answer 8

You don't tell them they're no good. You explain what is wrong with their code.

Answer 9

You haven't said whether you're acting as the person's supervisor or just their peer. So I assume you mean you're peers. In that case why is it your problem, anyway? Just be aware that you're going to have to work around their problems if you depend upon their code. And if it is a real problem in the team, make sure their/your supervisor is aware of the situation (unless their supervisor has a "relationship" with the team member in question).

The only way I can see a good way to directly deal with the problem is in the case that you have a friend-relationship apart from the work scene. In that case you might be able to find a way to work something in, rather obliquely, depending upon the relationship.

And if the person happens to be "really crazy", well, don't even try that.

Answer 10

If there person is no good for programming, chances are that there is also a lack of interest. It's just a job.

In this case, find out what the person is really interested in and politely suggest that there are some great opportunities in that direction just waiting for someone passionate to take advantage.

Answer 11

I think what you need to do is first have some kind of "proof" that what is going on is wrong in the first place. Go through the error logs. Make person logs of things that this person checked into CVS that didn't work and you had to go and fix. Don't just come out and say "I think this is wrong", prove that it is wrong.

Secondly, you can't just go to this person, or management, and say "hey, you/he suck(s)." You should provide some information on best practices, or even better: code up a demonstration. If you can show better code through an example it will give you a lot more credibility.

Confronting the individual, or management, is hard when you are the young developer / new guy. It's quite possible that management loves this person and thinks they are the greatest. You need to be tactful and come across as trying to help improve efficiency as opposed to coming across as trying to get this person fired, or having a vendetta against them.

Answer 12

Developers which are bad and sure they're good can't be dealt with. I think it's not just developers, but people in general. The most professional way to deal with this? Lay them off, don't waste your time arguing, you will loose anyway. It's better to have someone imperfect, but admitting his/her problems and trying to fix them. But that is fairly scarce resource.

Answer 13

I agree that there are some people who are so spectacularly bad that correction seems beside the point, and it's hard to stifle the impulse to just leave a Starbucks application on their desk as a subtle hint. I have worked with people whose cluelessness extended to other aspect of their lives, and would not have gotten the hint).

That being said, there's not much you can do.

If they just plain don't and can't get it, or have personality flaws that prevent them from improvement (e.g. will aggressively shout you down if you try to discuss their code) there's not much you can do.

If they care about their job, the quality of their work, there are many constructive ways of encouraging them to be better. If they don't care, there's not much you can do, short of encouraging management to move them out and avoiding their code as much as possible. I've had to do that perhaps twice in 10 years, in both cases it was done reluctantly, wasn't just me, and was done only after there was an organizational consensus that these people were way beyond the "I disagree with how you wrote that" bad and were utterly, utterly horrible.

BTW, in both cases management was already aware of how bad these people were, and were avoiding taking action for other reasons.

Answer 14

Some rules to follow: Well, there really more like guidelines.

1. Be patient - Really patient the things that annoy you may not really be that bad.
2. Remember that you are really only a few pieces of knowledge away from being where they are.
3. You may never work with this person again, but others will see how you interact with them and you will work with other people again.
4. If suddenly you decide that they must go, keep in mind that this does not mean there will ever be a replacement.
5. If you criticize, make sure you give good justification, and you give it in a positive tone. If you approach things from the area of wanting to help you will have more success.
6. Don't talk bad about them around the office, don't have a public code review flogging. Once you attempt to destroy someone they are lost to changing themselves. You may be completely right, but in their mind you are just an *$%.

Keeping these things in mind I've been able to work with quite a few people that others don't integrate well with.

The class of person that I still have a problem with are the "Negative" types of people. I'd love to know how to do better there.

Answer 15

if you nave no power to hire or fire then you have no business talking to the developers - take it to your boss/management and let them deal with it. it may be slow but... if their(devs) work in some way actually affects the quality of your work too - let them(mgmt) know that you are considering quitting.

the sneaky way would be to start a rumor that management is going to fire the not-so-good developer and make sure he/she hears about it, what do you know maybe he/she'll improve.

@Nosredna - that way you kind of end up doing their job too, don't you think?

Answer 16

It sounds like the OP is fed up with dealing with idiots. I know I am.

There are people in this biz (unfortunately, a CS degree must be real easy to get these days) who should be selling cars or asking if you want to super-size your order rather than slinging code.

As an old National Lampoon had in one of it's phony ads, "A strong back is a terrible thing to waste."

Answer 17

Don't. You will achieve nothing. They will still be no good. Let them be, just don't let yourself be them.

Answer 18

When I was in school I wanted to do a Math Ph.D. It made sense to me as I liked math, I was good at math, and other students admired my ability to whiz through examinations and assignments.

So I approached my professor of diffeq2 after class about the possibility of going to grad school in the math department (I was an EE). He flat out told me that you need to have talent to do so and I didn't have that talent. It stung a little at first, but it was the best thing anyone ever told me. And looking back at it, he was right - I didn't have any talent except the ability to understand exactly what I needed to know for the test.

Moral of the story, it is always better to employ a little radical honesty and just tell the person the truth. If they aren't a good developer, let them know. Especially if they are young. Better to break it to them now then five years later.

Answer 19

The best way to tell a programmer he's no good is "Your services are no longer required."

Answer 20

Behaviors, results or both: Which are you saying isn't good? By behaviors I mean the way the developer designs, writes, and tests their code. Is the method wonky or just the final result? Be specific on what is wrong, why it is wrong and see if there is concensus on this. It may be that you don't know so-and-so has a reason for being that way which may be important. I'm not discounting that the pain of collaborating with this person, just that while you think it may be easy to make a few changes, those may be huge changes for the other person if they have any number of conditions.

The point in the above is that to some extent you may not understand the problem or the entire context. If someone has 40 requests in the course of a day, this could make someone less than stellarly productive. By request I mean someone asking, "Hey, could you get this for me?" being asking a handful of times each hour and the person working 8 hours in a day.

Answer 21

I think the best possible way to follow is:-

• There should be a code review on the last day of every week of each & every project done by each & every developer, including yourself, at least once.
• You should point out some basic standards to maintain while coding, for example, you can see the following websites (Programming Style & WordPress Coding Standards) for references.
• You can point out the advantages of maintaining this type of programming standards.
• For every bad programming done by a programmer, you can maintain an office rule of charging a fine of 50 or 25 bucks to that bad programmer. This will instantiate a fear among those bad programmers of losing their own money to office colleagues. But be sure not to take away the whole money of fines in your own pocket, otherwise that will surely provoke a misunderstanding.
• Ask those bad programmers to improve their coding standard, but in a very positive way, without affecting their morality & efficiency. If possible, you can just tell them how you yourself improved & how you coded badly (just for the sake of boosting the moral strengths).
• This way you will surely find an improvement in your team, and no negative feedback will arise.
• Last but not the least, for all these to happen, you must have some power with you, like you must be some sort of Senior personnel or a Team Leader or Project Leader, & so on.

EDIT (for @Marek's comment):-
I myself have done this in my previous company (for the last 4 months of my tenure) & it worked too. But the main point is the management & your Reporting Manager must know the pros & cons of such a team-wise coding / programming standard review, so that the projects don't get delayed. Also these standards are recommended for some international / national standardization of your company, which helps in the long run for getting major big clients for projects.

As for the question "who is to judge whether the offender (here the bad programmer) is really guilty", I mentioned earlier that this type of session will not be to depress the offender. It is solely for the purpose of both the programmer's & the company's benefit of programming in a standard & logical way. Also deciding whether any programmer has coded in a wrong & illogical way can surely be done by a voting system, because not all will go against / for the programmer, which I think SO (this community) also follows.

Hope it helps.