Fog Creek Software
Discussion Board

Hiring Mistakes

A couple of guys joined my group 6 months back from some other group in my organization. We didn't get an opportunity to interview them before they joined us since they were already a part of our organization.

All these 2 guys do day long is to screw up the code written by other team members, write totally illogical and buggy code. Worse enough, they checkin uncompilable code. We are in a project which involves heavy C/C++ coding and strict deadlines. I've ended up burning my nights and weekends cleaning up and fixing the code.

One of the idiots went so far to change the TCHARs in our code to char! When I asked her why she did that, her reply was: "TCHARs look funny and I cannot comprehend their presence". Great!!! Our product is to be used in 20 different countries and not all of the users know English.

These 2 aren't rookies. They have "2+ years experience in C/C++". I am appalled. I've already complained to my manager but his reply is: "you gotta mentor them." Well, I am being tormented by them.

This code snippet drove me crazy:

std::string s;
char *p;

p = SomeFnReturningCharPtr();
s = p;

The last line would crash the app if p is NULL, since the overloaded assignment operator and copy constructor of std::string do a strlen(p) without checking p for NULL. When I pointed this out to the other moron, his reply was that the STL was buggy, and there was nothing he can do in this code.
Buddy, how about writing

if (p)
  s = p;
  s = "";

I am sure some of you guys out here would have had such encounters. Any tips as how to handle these guys?

Thursday, August 5, 2004

Are you working in an XP or other Agile methodology shop? If so,  eaither pair with them and show them how to do it right or refactor the code and keep track of exactly how much time you waste cleaning up their messes.  So next time the boss asks you for a status report, you can say, "I spent x amount of time cleaning up their messes," or something more diplomatic, if you like. If they report directly to you, lay down the law - your way or the highway.

If you're not in a XP/Agile shop and there is no group ownership of the code, you hae my sympathies - still document how much time you spend cleaning up and include it in your status reports.

Michael Ealem
Thursday, August 5, 2004

And the changing TCHAR to char?!  She obviously broke the build doing that - did nobody higher up the food chain come down on her?

BTW, why are you guys mixing STL strings and naked char* anyway? Looks like *that* is just begging to be refactored. Or is it a legacy API call returning the char*?

Michael E.
Thursday, August 5, 2004

Two simultaneous events.

You take away checkin rights and all their code has to be signed off before being checked in. 

Whether you use XP, Agile or Waterfall in a Closet, you pair them with someone individually and gently let them understand the rules and the reasons for the rules.

Then after these two have been in operation for a while, say a month you review with them how they're doing and what their targets should be.

The mistake was in letting people loose without going through this in the first place it was unfair to the existing team and unfair to the joiners.

Simon Lucy
Thursday, August 5, 2004

Oh, the only other comment would be why do their screw ups cause you work?  If there are problems with what they do and they check them in, then you revert the checkins, you don't fix them, you back them out.

It sounds like you need a sherrif on the build, these newcomers might not only be causing problems but exposing weaknesses in your current procedures.

Simon Lucy
Thursday, August 5, 2004

You have my sympathies, it's a classic case of these guys being "unconsciously incompetent", they don't know what they don't know - in fact, they think they're pretty good!

How big a training budget do you have?  Would you be able to send these guys on a course to "further their professional development" - something to give them a new perspective on the impact they're having?  If nothing else, you'd have a week to get some proper work done!

If you can't get them out of the office for a week, how about some recommended reading?  Give them a week in the office to study Effective C++ (Scott Meyers), throw in your own favourite development tome as well.

Finally, how about a new process - peer code reviews pre-checkin would be a favourite.  That way, you can keep refining their code until it's passable, and it gives you a mandate for the mentoring as well.

Steve Power
Thursday, August 5, 2004

Gee, I have this manager guy who is so inert. We gave him extra people and he can't get over the fact that they come from outside his part of the organisation. He's not making any attempt to mentor them, help them or explain their mistakes. Here is a guy who is resistant to change and is costing us money and quality. Worse, instead of trying to build a team which includes these people, he's dissing them on the internet.

What do I do ? Do I just fire him ? Does he deserve a second chance ?

Thursday, August 5, 2004

as joel said, neutralize the bozos, give him task they can play with - eg. internal documentation :)

Thursday, August 5, 2004

Talk them up constantly, say their talents are underutilised on your project and give glowing reviews. Hopefully some other group will snap them up.

Mr Jack
Thursday, August 5, 2004

Hi Michael,

First: thanks for your comments.

>BTW, why are you guys mixing STL strings and naked char* >anyway? Looks like *that* is just begging to be refactored. >Or is it a legacy API call returning the char*?

Yes, we a have a legacy API set, some of which return char*. However, our classes take std::string. Hence, the mix.

I'll certainly get to implement most of the inputs I got so far from JOS readers. Thanks  a lot guys!

Thursday, August 5, 2004


Our team just brought on two people too.  The first one dropped the *production* database yesterday and didn't bother telling anyone about it.

It wouldn't be a huge issue, but it's the THIRD time it's happened in the past month.  I want to revoke her database permissions, but alas, we have *ZERO* security.

The other guy admits that he's never used vb, asp, java, or sql.  *98% OF WHAT WE DO IS ASP/SQL PROGRAMMING*  He's trying to convince us to use hierarchical databases.  Right...  just shut up and do your work.


Thursday, August 5, 2004

Do you know who I would love to hear? An hiring mistake.
Someone admitting he went way over his head and was sinking. The way he described the tactics used by his colleages to make him feel bad, the attrition caused by his mistakes and the anger he provocked on his boss. And, for the grand finale, the frustration that kept on sapping any and all ability he would have to do the job the right way.

But, our huge egos prevent us from recognizing we're hiring mistakes. Most of us life in the belief the world is wrong, we're always right.

Thursday, August 5, 2004

I have dealt with this in past.  One instance It does take some time to convince management.  One place the management refused to acknowledge the problem since they would have had to admit a mistake to hire this person in the first place.  Just document every issue that you have and make your case.  Nothing personal (like avoid using a phrase like "idiot" even if true!), just the facts.

If no one listens, leave.  Chances are if they can't recognize incompetenance then they won't recognize greatness either.

Bill Rushmore
Thursday, August 5, 2004

The amazing thing to me is that mediocrities and worse can still thrive in this tighter market.  There are better people out there who have trouble getting an interview.

When looking for a job last year, my intuition was that the average quality of employed developers would be way up, post-bubble -- but I don't see that at all.  Instead I see many *survivors*:  mediocre programmers who were in the right place when things went to hell, and have kept chugging along in their careers without a hitch.

profound insights galore
Thursday, August 5, 2004

While I agree that shunting 'mistakes' to the side will make things easier for you in the short run, the long run calls for education or the boot.

If you decide to educate, it will eat your time but it shouldn't cost that much more than trying to uncover the minefield of mistakes that will occur if they are left to roam free.  The other benefit to attempting education is that it gives you a better chance to evaluate what sort of 'mistake' you have.  Are they capable but out of their depth?  Are they just inexperienced?  Are they slack-jawed yokels from the shallow end of the gene pool?  Based on this, you will have a better idea of how they could fit into your team or what size of boot you should use.

If the boot is the best option, start the paper trail now.  Document the issues, provide unmistakable feedback, and repeat until no-one can really argue against termination for cause.  Depending on your company, this process can take a bit of time which is why it is important to start the trail as early as possible.

Thursday, August 5, 2004


There are 2 paths you can take, depending on what you want to accomplish.

A) These people are trainable given enough time.

Pair them up with senior developers, get the boss to allocate enough time for the projects; have peer reviews prior to checkins. Don't accept anything that doesn't conform to the coding guidelines, make sure they come to you any time they don't understand something, or any time they feel like refactoring old code.

B) These people are hopeless. They don't know how bad they are, and don't want to learn. You need to separate their work from yours to make sure you don't go down for their mistakes.

DON'T FIX THEIR MISTAKES. Submit a bug for every thing they mess up; copy your boss. Get them to work on another project from yourself, ideally bugfixes and maintenance. Don't be on the same version control branch with them.

Thursday, August 5, 2004

1) Document their mistakes (HR will need some justification beyond "they're idiots")

2) Split them up, and assign some people to mentor them

3) Don't shuffle them to another department.  That will just piss off the people over there.

4) If the decision gets made that one or both of them are hopeless, get the firing done as quickly as possible.  Don't drag it out.

Alternative approach: Fire one of them, and let the other one know why.

Thursday, August 5, 2004

Coding standards, my friend!  The whole purpose of a code standard is to keep the quality of the code high, and make it easier to go in and work on other's code in a uniform manner.

If you already have a coding standard, then it may need to be updated (we explicitly had the TCHAR thing in our standard!)  If not, have a meeting with *all* the developers, including the 2 problem ones.  Get everybody's input and form one that way, so that they all feel that they own the standard and that it really is a group decision, not something imposed upon them.  That shold encourage the whole group to follow the standard.

If that isn't enough, you can tie pay or performance reviews to standards adherence.  If somebody goes months, years, without getting a pay raise, then perhaps they'll put two and two together. ;)

A Programmer
Thursday, August 5, 2004

Bob, very depressing story. The two people are like viruses that will rapidly destroy the product. Get them out before they do any more damage. If management will not listen, then all is lost unless you can 'contain' them, that is, remove their code-writing privileges, or give them a module that will not be integrated in the product so they don't do any further damage. If you don't do that, then it is a hopeless situation and brace yourself for trouble.

Thursday, August 5, 2004

You said:

"These 2 aren't rookies."


"They have "2+ years experience in C/C++". "


"2+ years" is rookieville.

Thursday, August 5, 2004

>  Instead I see many *survivors*:  mediocre programmers who were in the right place when things went to hell, and have kept chugging along in their careers without a hitch.

That is so true. All the little syntax nazis sit there "filtering" people based on some arcane crap they learnt in week 3 of third year. No hire. No hire. Are we good or what. No hire.... Hey, how come the company's in trouble? No hire.

Big mistake
Friday, August 6, 2004

Rookyville? Isn't "not changing the type of a variable I don't understand" common sense? Shouldn't you know that at 0+ years of experience?

Jack V.
Saturday, August 7, 2004

> ... Worse enough, they checkin uncompilable code. ... Any tips as how to handle these guys?

I used to do code inspections of everything written by all news hires who worked on 'my' projects. Depending on how good their code was, I'd tell them that I wanted to inspect it either before or after they checked in. The rare person who didn't voluntarily comply with my inspections would lose their checkin priviledges. I'd stop doing code inspections of a person's work a few months after my inspections stopped finding bugs in what they wrote.

Christopher Wells
Sunday, August 8, 2004

Big Mistake is actually very very right.........

Ogami Itto
Monday, August 9, 2004

Give them relevent books (Code Complete, Refactoring, or the WINAPI help, whatever you think is relevent based on what they're working on and on what mistakes you see them making when you read their source) and make it clear that their job includes using the knowledge and practices therein.

Tell them that, while they're working for you, you want them to work full-time ... but that, at least to begin with, doing it correctly is more important than doing it quickly.

Tell them that you're always available to answer their questions: that you'd always prefer them to know than to guess.

And don't think of them morons.

Christopher Wells
Tuesday, August 10, 2004

Buddy, how about writing

if (p)
  s = p;
  s = "";

For someone who complains about bad code.  Shouldn't the code above actually be:

s = p;

The else block is redundant !

Wednesday, August 11, 2004

*  Recent Topics

*  Fog Creek Home