10 ways to kill your star programmer

1. Make them project managers.
2. Make them managers.
3. Enroll them in all kinds of full-length time-consuming leadership classes.
4. Ask them to attend numerous stupid meetings and conference calls on behalf of the team.
5. Ask them to spend a lot of time sorting out various best practices and coding guidelines that will never be read or used by anyone else.
6. Bug them with licensing concerns with every code library they want to use.
7. Ask them to submit purchase request for software they want to use once a year. If they miss the time, they have to wait another year.
8. Lock them in the project important for your promotion and reject their requests to leave the project because they think it’s boring.
9. Reject their requests to travel to tech conferences they are dying to attend so that you can balance your quarterly cost.
10. Tell them you love them so that you can keep their pay low without feeling guilty.

  • http://rant.blackapache.net/ OJ

    11) Make them Test Leads.
    12) Force them to work on build environments.
    13) Make them System Administrators.
    14) Force them to use a language/environment for a project despite it being the worst possible choice.
    15) Blame them for anything that goes wrong.
    16) Make them use BizTalk for every integration project.
    17) Force them to get MCSD/MCSE/etc qualifications.
    18) Take away his/her Internet access at work.
    19) Force them to do crunch time.
    20) Use a mix of agile/waterfall approaches on their project.

  • http://climbing-the-hill.blogspot.com/ RyanMcDougall

    21) Force them to use tools they dislike, or refuse to allow them to use the tools they like.
    22) Use them as a tool for your project or career advancement, instead of as a human being who has to face the consequences of your decisions
    23) De-motivate them by turning any consultation over project or technical issues into a egotistical pissing match
    24) De-motivate them by repeatedly answering legitimate requests for comments on technical or project matters with “I don’t care”. And if they complain you have a built-in reply: “I thought you didn’t like micro-management!”
    25) De-motivate them by dismissing any work that isn’t directly related to core project requirements as a deliberate waste of time. Things like debugging facilities, unit tests, defensive programming against corner cases or malformed input, security, readability, learning external libraries as opposed to writing everything from scratch, or researching and learning other methods of software development.

    I see a recurring pattern that includes the words “force” and “demotivate”.

  • http://blog.danielfmartins.com/ Daniel F. Martins

    All this stuff is a pain in the ass even for those programmers that are not “star programmers”! 😀

  • Jun Li


  • http://climbing-the-hill.blogspot.com/ RyanMcDougall

    I think the point is that losing a star programmer is a powerful blow to the company because they drive most of your core product line, and are very hard to replace. Thus doing the above, while justifiable for commodity programmers who are a dime-a-dozen, its a bad idea for “star” ones — and thus the equivalent to departmental (or even corporate) suicide.

    (Not that I would call myself a star by any means)

  • Richard Murnane

    I’m surprised that nobody has mentioned setting arbitrary deadlines…

  • anonymous

    This is also a strategy used by management to get rid of annoying gits :)

    (just thought I’d look at it from a different angle)

  • http://nothinghappens.net chuck

    I think the other angle on this post is supposed to be that, these are things that companies are more *likely* to do to “star programmers” (make them managers, have them develop coding standards that get ignored, etc)

  • JP

    Stop complaining and get back to work – slackers!

  • http://jroller.com/page/rc Hou Yong Rong

    You guys are cool. I think I’ve come up with more but I’ll just save them for now. Welcome to the real world:))

  • mj1531

    26) Have them work with blub programmers.
    27) Have them share office space with noisy project managers and an erratic heating/cooling system.

  • linuxkid

    28) Have them generate “Reports” for sales
    29) Have them write documentations that no one wants
    30) Have them listen “web 2.0” meetings from manager

  • http://www.datallegro.com Robert

    31) Insist that they be teamed with the new tech support new hire so he can learn the product from the ground up.

  • pain

    32) Ask them to answer the phone after 16:00. (At 16:00 the company secretary goes home).
    33) Ignore any of their requests for a CPU or memory upgrade. 512mb should be enough.
    34) Ignore any of their requests for new tech books in the company. Programmers (and especially “star” ones) should buy their own books, study them on their free time, and bring/apply knowledge back to work.

  • Jackson

    35) Cheat on your wife with the company secretary and give her authority to tell the programmers how to do their job!

  • Rakhitha Karunarathne

    Hire a marketing team that does not know the limitations of the technology that the company is using.

  • Charson

    36)make him use the floopy drive for back ups

  • http://rant.blackapache.net/ OJ

    Can you please remove my email address from this page? If I’d known that the email was going to be public I’d never have punched it in the first time.

  • http://jroller.com/page/rc Hou Yong Rong

    Oops…forgot to have the email scrambler on. Sorry. It’s on now. But looks like existing emails can’t be scrambled?

  • Jason

    Accept all credit for the project when all you have done for it is ask the star programmer, “How’s it coming?” once every two months.