Let me explain this a little.

In a previous job, I had a coworker that has a good reputation with the management. He always finished on time. And the bosses were happy with his progress so het got certain privileges.

The problem was that the other programmers knew his secret. He has optimized the 80/20 rule, so he worked his 20 percent time to finish 80 percent of the code. The other (hard) 20% was left to the maintenance programmers. Who (not surprisingly) got penalized because of their lack of progress. But because this programmer had a good reputation with the management, it was almost imposible to shift the blame to him. (Fortunately he left the company).

My question is, what to do as programming team if you have such a programmer within your team. Do you try to warn management with risk of ruining your own chances? Do you accept the fact? Or are there other options.

  • 6
    I'm not sure that "egocentric" is the correct term. I would try something like "deceptive".
    – Wizard
    Sep 18, 2010 at 15:09
  • possible duplicate of Dealing with the "programming blowhard"
    – user8
    Sep 18, 2010 at 17:46
  • 2
    True story: This is how UNIX was developed, and it spawned an entire generation of like-minded programmers. See Worse is better.
    – imgx64
    Sep 19, 2010 at 16:02
  • If you can vote and think this is a useful question or it have useful answers below, please vote up. StackExchange sites need votes to build a good community. You can give 30 votes per day, don't waste them. Specially users with high reputation and low counting votes given please read this: meta.programmers.stackexchange.com/questions/393/…
    – Maniero
    Oct 5, 2010 at 19:25
  • The units are inconsistent with 20% time and 80% code. Just leave it at, "He worked on the 80% that was easy, and left the 20% that was hard to the rest of the team." Oct 17, 2010 at 11:07

6 Answers 6


Try to implement a code review team. It sounds like this programmer was working solo on a project with no team interaction. I'd try to encourage a more team-based workflow so that he can't just stomp over everything and then leave it on your door.

  • 1
    Implement real metrics of what a standard working unit range is, take into account real factors of programming, not what management thinks (ie, more LOC = better programmer).
    – Incognito
    Sep 22, 2010 at 15:03

People should have to support what they develop, otherwise they never learn to develop supportable things.

Realistically you cannot always do this 100% of the time, but even a little is enough to straighten out a lot of this sort of issue much of the time.


It sounds like it's a fundamental problem with the way you track work or manage your projects.

An engineer or group of engineers should be responsible for delivering complete features and functionality. It isn't done until it's shipped or running in production without problems.

If you let someone only work on select pieces of the project, you will always be victim to political gaming of the system.

It sounds like this person was very effective at cherry picking work without delivering value.


Is the management dividing the requirements into tasks? If not then there lies your problem.

The programmer can't finish 80% of everything if he were locked to only the tasks he should be on, then instead of spending time on other tasks he could spend time on making his own tasks more perfect. Testing, Documentation, Refactoring, a next Task that is on his schedule...

  • It was on a previous job several years ago. The management was not very good and all I know, is that the company doesn't exist anymore. Sep 19, 2010 at 18:07

The whole team has to kick his ass ! Believe me, his behavior will change forever.


I'm amazed as I sit in a meeting and a manager bases whether or not to add a feature so they don't have to confront a particular person who always gets mad when given tasks. I point out that maybe I should get mad when asked to do things. My boss quickly mentions that this is a bad idea as she should.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.