Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

You're doing nobody any favors by being passive-aggressive. The employee needs to know, management needs to know.

Talk to his manager behind closed doors. Be reasonable. Provide data. Metrics can be misleading, but if you have them, now is the time. (I recall one coworker at a job, when we looked, had done 12 CVS checkins during a given period where the average was close to 100 and the next lowest was in the 30s, or something like that. Illustrative!)

I have seen people improve if someone lights a fire under them! That's his manager's job. More often this doesn't happen, but it's not uncommon for the chastised person to start job-hunting and solve the issue fairly quickly anyway.

I wouldn't confront him directly unless you are his manager. If you are, talk to him ASAP. Set up a plan with measurable deliverables, and make it clear that he'll either make the goals or be asked to leave.

Little is as bad for morale as the crappy employee that drags everyone down and isn't fired. Good managers understand this.

If the company doesn't care, it's just a matter of time before more bad employees sneak in, and like a cancer the good employees start slacking off more (because why not? The idiots are never fired!) and you don't have a fulfilling job anymore. So, that's when you dust off the resume yourself.

Good luck!



I agree. Trying to alienate one person can poison the whole group dynmamics. Others could get PO'd at you. People who don't have the 10000 ft view often are good at details or at administration. Best to find something that he is good at that helps the group. As others have said this is more properly the manager's or lead's job. If he ignores it, your hands may be tied.


I strongly agree with the above 2 comments.

You are describing what a manager is supposed to do. And you don't give enough details to diagnose the situation. I've seen coworkers who seriously had ADD (and were on enough prescription meds that their pill jar looked like a bowl of skittles), and I've seen coworkers who've had problems at home.

The guy with ADD couldn't see the 10000 ft view if you hit him on the head with it because ... ooh, look, shiny! He had to be micromanaged because his own steering mechanism was faulty.

May I recommend that you read Dynamics of Software Development? Because it sounds a lot like you want to flip the bozo bit over there. http://www.amazon.com/Dynamics-Software-Development-Jim-McCa...


I'll grant no one will read this but you (maybe?), since it's so far off the front page and everyone else's radar. Overall, your thoughts are excellent, but I have a bit of a bone to pick here:

(I recall one coworker at a job, when we looked, had done 12 CVS checkins during a given period where the average was close to 100 and the next lowest was in the 30s, or something like that. Illustrative!)

Not a good example. Number of commits is an n-th level approximation to measuring productivity. As an example from my own life recently, I just finished doing a massive refactor on a rather integral part of my current employer's website.

Due to the bad shape this module was in, any change I made to it would result in a broken program until I had done a considerable amount more refactoring both within the module, and all the other places it was tightly coupled within the code. The philosophy of "if it works, don't fuck with it" didn't apply here, because it didn't work when it was thrown my way, and it was almost indecipherable as well. So I set to work refactoring, more to decipher the code than to fix the problem; it was impossible to keep enough of a logical model of it in my head to reason through the misbehavor. Every time I changed something, 3 other things would break, making building the mental model I needed even harder.

For a number of weeks, I had something non-functioning, and something that would be completely worthless if committed into repository (I was backing it up elsewhere at the time). The best these commits would've been is the SCM version of status reports of a system without cohesion, which would have been a complete waste of everyone's time.

To be clear, I am absolutely against monolithic refactorings about 99% of the time, and I did a tremendous amount of soul-searching through all of this. I worried that I was making this far more difficult than I needed to make it, that there were smaller changes than I was making that would allow everything to work out. But every time I'd try to find a easier way out, I'd hit a point where I found such tight coupling that changing one thing would necessitate 20 changes elsewhere, and things would cascade from there.

When I got to a point where it started functioning again, I committed all the changes in at that point. One commit, but a lot of lines of code, and even more deep thinking went into this work. At this point, I am now committing more frequently, as the remaining issues are worked out of the rewrite.

I guess the moral of the story here is: don't just focus on the number of commits, focus on what went into them. If these 12 commits were on par effort-wise with the 30 commits on average of everyone else, something is wrong; otherwise, the guy hitting 12 commits might just have deeper, more difficult work to do.


True. In this case, they were not major changes, the guy just wasn't doing anything.

It can be useful to drive home what you already know, but not really to discover information.

At a functional software house, it's largely obvious to _everyone_ exactly how much work everyone else does. Think about your coworkers - do you know which ones are good and which are dead weight? I bet you do!




Consider applying for YC's Winter 2026 batch! Applications are open till Nov 10

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: