Trust me: don’t fire that bad developer just yet* (part 1)

August 28, 2007

You know this person. For the sake of this post, let’s assume it’s a guy. And this particular guy is obviously the worst developer on your team.

He’s been at your company for a month or two. He doesn’t understand your code base. He doesn’t understand best practice paradigms (yes, I know they’re open for debate, but assume I’m talking about your best practice paradigms). He doesn’t listen when you offer feedback. His communication skills are, as a good friend of mine might say, sub-optimal. He requires more attention than developers that are twice as capable.

But please don’t fire him yet.

Ok, some of you can (and should) fire that guy out of a cannon, but don’t even think about it until you’ve given him a chance. Let me be clear: “a chance” consists of the following elements.

  1. Clear direction: He needs exactly 1 boss. Not 1.5 bosses. Not 1 direct supervisor and 1 director that sometimes hands him other assignments. 1 (ONE) boss – no more no less. If every assignment isn’t funneled directly through that 1 boss, additional lines of communication have to be established. And that doesn’t work. Ever.

    Office Space is funny because it resonates truth with anyone who’s ever been in a situation where he has multiple supervisors and none of them fully know what’s going on. Believe it.

  2. Well-defined expectations: This is tightly coupled with direction. Our hypothetical developer has to know what’s he’s supposed to be doing and what result is expected. When do you expect him to be done? And what does “done” consist of? Experienced developers tend to make the assumption that everyone knows good code from bad. So do you want his assignments “done” or “done well”? If he doesn’t know the difference, is that his fault or yours?
  3. Consistency: If you can’t offer him a consistent work environment, don’t expect him to be successful. People need schedules. People need a degree of certainty. People need to know that scheduled meetings will happen at the scheduled time for the scheduled length. They need to know that project decisions are made the same way every time. (Side note: if your organization doesn’t make decisions the same way every time, you’ve got other problems. In that case, it’s your job to insulate your developers as much as possible and create a consistency bubble around your team)
  4. One code review (at the bare minimum): If he hasn’t had at least one code review and the opportunity to respond to the review feedback, don’t fire him! I don’t care what your mentoring process is (you do have a mentoring process, don’t you?), there’s no substitute for getting constructive feedback from a group of your peers. I’ve seen poorly performing developers make a 180 after a good code review or two.

In part 2, I’ll talk about what you’re leaving on the table when you fire someone too hastily.

*No, this isn’t about me. I hope. 😉


2 Responses to “Trust me: don’t fire that bad developer just yet* (part 1)”

  1. […] By themarksavage Categories: Uncategorized So you didn’t take my advice (part 1). You went ahead and fired the guy anyway, didn’t […]

  2. sonicrafter Says:

    I feel more men and women will need to read this, extremely beneficial info.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: