One of my co-workers spends big part of his time in analyzing the others work. He looks for glitches like forgotten outdated comments in the code, design decisions that could be more optimal while existing solutions work, some things that just look "inconsistent" for him and the like. Also, no software design document he ever seen looks for him complete enough to be acceptable. The problems he finds are real, but the importance of them is questionable. He basically raises the importance of every problem he spots to the most critical possible.

While I initially assumed management will tell him to stop and watch own work, this seems not happening much. Probably the management assumes that heavy criticism will make others to work better. From the other side, I do not feel happy at all when I also need to do his actual work, fix the bugs he also makes time to time, while he is preparing the ordinary portion criticism to pour over my head.

Maybe one of the approaches would be to start watching HIM on the possible mistakes, the problem is co-worker seems less and less active on the actual job tasks, there amount of code he still writes is very small so can be easily made perfect. However somebody still needs to complete the remaining parts.

Is there any way to control this situation? I have nothing against discussing criticism constructively but this seems already going well beyond of that could be normal in a well working team.

  • 13
    What has your manager told him to do? Is it possible that this is his job and he is supposed to be finding this sort of thing?
    – bizzehdee
    Jun 13, 2016 at 10:09
  • 4
    What is your bug reporting process? I would tell him to add those glitch reports to the bug tracker so that the team doesn't forget them. They can be addressed when the work queue allows it (customer bug reports come first, for example).
    – Brandin
    Jun 13, 2016 at 11:37
  • 2
    "Is there any way to control this situation?" What outcome are you trying to achieve? What have you done so far? Have you even mentioned any of this to your manager? What's your experience level and how far have the involved parties been with the company? For writing such a long question you have given us very little information.
    – Lilienthal
    Jun 13, 2016 at 13:07
  • 4
    This developer is just wasting everybody's time. He should be fixing those issues himself. If a comment is outdated, he should delete it. He should be using the version control system for this kind of work, not email. And if he wants to make a major change, he should work on his own branch. If he's not skilled enough to fix a major issue, then he should write it down in the bug tracker. If there is no bug tracker, then you guys need one. Jun 13, 2016 at 17:22
  • 3
    This is not possible. Every human being makes errors, and the coworker himself is not any exclusion.
    – eee
    Jun 14, 2016 at 5:49

2 Answers 2


Stop doing "his" work and stop fixing "his" bugs. Now, if they're not actually his and your boss expects work to be completed at the team level, your team needs to address this.

Give him a choice: either he can get his work done, or as a team, you're forced to report this to management, so they can get someone to pull their weight. If the team does not want to do this, then I would tell the team I'm not doing his work and let them see how it feels.

This is the draw-back of just letting everyone do what they want. Some things either don't get done, or someone else gets all the dirty work.


Talk to him about this behaviour first, then your boss. Anyway, are the "bugs" he spots actually bugs? Could he somehow be saving the code from a not considered edge case?

Sure, he might skip his work (tell him first if he has been partially assigned or if his tasks have changed, and if not, tell your boss about it), but peer reviewing others is an important part of development as well. One already knows how his code works and might skip critical edge cases (not on purpose).

My colleagues tend to ask for help when something's not working and they spent hours on it. It tends to be just a stupid misplaced line, a check they didn't do, or not using the proper variable. Issues that seem trivial, but since you coded it, maybe you're assuming they're ok.

Another pair of eyes sees these kind of issues. My boss in fact encouraged us to pair review and pair code in extreme cases, just to make sure the habits of one didn't affect the result.

Also, outdated documentation is one of the top problems of many libraries or frameworks out there (take a look at the Android documentation, for instance), so it can also be in closed projects where many devs are involved.

One last thing: did his incursions reduce the bugs or crash reports? If so, maybe it's just a matter of good manners and institutionalisation when mentioning these issues.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .