Uhh. No.

One of my best CS professors used to say: "Competition is for horses"

The _right_ way to motivate your hackers is to give them interesting stuff to do so that you can watch as they fall in love with the stuff they're doing and achieve inhuman-seeming goals fueled by caffeine and pure joy for their work.

Not some stupid motivational analogy from "a quality control manager in a hospital".

"...achieve inhuman-seeming goals fueled by caffeine and pure joy for their work..."

Exactly!

There's almost nothing that can motivate me when I'm "done for the day". Not deadlines, budgets, help, dinner, not even money.

OTOH, there's almost nothing that can get me to knock off for the day when I'm "in the zone". Just yesterday, someone spent 5 minutes showing me something that turned out to be the missing link in 3 different places in my app. Six hours later, I looked up and realized that everyone was gone and the lights were out. Six of the most fun hours in a long time. You can't engineer that into your workplace.

Nailed it.

"Nothing motivates like having another programmer tell you they're rewriting your code because it sucks."

Wrong. This doesn't motivate. It just pisses me off.

What if there is an error or bottleneck which really counts? To say "it sucks" is rude and a very wrong way to tell but sometimes a fresh eye founds real things in code and it's a bad policy not to tell. Most of the people take it as piss off for sure but still...

Presumably, they should tell you you should rewrite your code because it sucks?

No.

Presumably:

1. My code doesn't suck (with rare exceptions). I know that. Why don't they?

2. What is the definition of "sucks"? Doesn't meet some other requirement that no one has agreed upon. Doesn't meet some other requirement that hasn't been identified? Has bugs? Runs slow? Is indented 2 spaces instead of 3?

3. Even if the code did suck, that doesn't automatically mean it should be rewritten.

4. Even if it should be rewritten, that doesn't mean he should do it.

5. They should learn better people skills. If they were looking for trouble, they found it.

Indeed, all salient points.

I don't understand why the general opinion here is so negative. Having this kind of competition means people _reading_ each other's code, and this alone is worth gold. Some friendly rewriting can't possibly hurt. After all, this is what open source is about, and it definitely works.

Of course, engineering competition has a lot of chances to backfire, but everything can be taken too far.

I think, because, someone Pointy Haired Manager is going to read this post and introduce a practice of Competition Driven Development, and a kitten will die every time that happens.

In this forum, if you have a pointy haired manager, you have already lost.

Not here, but I bet a ton of them read Jeff's blog

It's funny that the comments here are so negative, and yet, in the real world, this effect proves true over and over again. For example, I've noticed that sometimes you'll have a team of developers just collecting a paycheck, and when a new guy comes on who's hypermotivated, the motivation of the entire team increases.

It's just a fact of life that a very large number of people, including developers, often operate at submaximal performance. They aren't leaving poor code simply because they don't have enough time to do everything that need's doing. They're leaving poor code because they're browsing the web, chatting, or thinking about other things.

Also, there's a lot of really boring code that needs writing. Not everyone can work on interesting projects. Boring code can still benefit from being written with care and motivation.

A good programmer is one who writes good code because their personality requires them to write good code.

If you need to resort to competition games, you don't have the right people.

I have been in a situation of yelling at my technical lead to write less good code ("That won't work for the general case" "I don't care about the general case! Special case it so we can get it out the door!" "No! That's just wrong!" "I don't care!" etc etc). I'd much rather deal with that than having to play mindgames to get people to do the right thing.

YAGNI isn't a piece of cake either. I remember when I first got a job as a junior I used to spend endless nights trying to template stuff in C++. I feared it might not work for the general case. As it turned out several months later in practice:

1. I didn't knew what the general case was so it wasn't supporting that.

2. Code was so fucking complicated trying to suit the general case. I had to throw it out. I had to write new code that actually solved new cases.

3. I wasted about a week on what could probably be done in 30 minutes at that time.

4. There were third-party libraries (Boost) that were written by people who actually dealt with the general case but I wasn't allowed to use them since they "bloated code". Those libraries would've saved me time when I wrote the original damn thing, when I had to introduce new cases (probably), and when I had to debug that crappy code of mine.

Number three has also caused me to learn what kind of stuff can bring someone's productivity up by orders of magnitude.

I also learned that I should have freedom on what libraries I have to use because micromanagement is dumb.

Conclusion: micromanagement sucks; YAGNI rocks.

Just because we don't like it and it really gets under our skin, doesn't mean that it does not work.

However, I do not suggest using it as a management technique. There is regular performance and adrenaline-based performance. The latter is not likely to happen full-time.

''There is regular performance and adrenaline-based performance. The latter is not likely to happen full-time.''

Bingo. Salient point of the year.

Well, it all depends. I would agree with the main premise - that a little friendly competition is motivational, but the operative words are - wait, that didn't come out right - "a little", and "friendly competition".

I trust my code to be optimal, or I know where it isn't and leave it at that, since I don't feel like / have time to tune it. If somebody fixes it I'm always interested to know how he did it in the former case, and I'm simply grateful in the latter case. And if I rewrite someone else's code for the better, I do feel good - not because I "beat" him, but because the code is better now. And isn't such a stepwise refinement a worthy goal?

> I trust my code to be optimal, or I know where it isn't and leave it at that

That's a pretty remarkable claim, unless you religiously profile all of your code.

Well, it's optimal, not optimized. So let me re-phrase that in a way that's more realistic - I trust my algorithm choice to be optimal, and my code expresses those algorithms in a simple way, which get a good speed to cleanness ratio. :)

I still say that's a remarkable claim. Modern computers are complicated (not to mention language runtimes and frameworks), and few applications admit straightforward algorithmic analysis.

Somewhat related on the subject of motivation; the phenomenon in forums or mailing lists where a request for information leads to few, succinct answers, yet an inaccurate or inflammatory post on the same subject results in long, detailed, and often very useful refutations.

(reposted on coding horror)

I strongly recommend that you read The Psychology of Computer Programming by Weinberg and please, please, please do not espouse this kind of stuff. As a hiring manager I would never want to hire a programmer who is so proud of their code that somebody rewriting their code motivates them. There is a very big difference in "taking pride" in your work and "being proud" of your work. I will take the former any day and shun the latter any day. Most projects are about team work and rewrites are a fact of life. I would go so far as to say the if you are not rewriting/refactoring your code, you are missing something big that will come back to bite you.

If you want to motivate a programmer, understand that if the programmer cannot find something in the project that appeals to them, you _will_ not get 100% from the person. Programmers IMO need to be challenged, but with tough, new or complex (not the same as tough) problems not by appealing to their egos and touching off an internecine war. Part of their work needs to be in an area that they are interested in. They need to have the flexibility to work when they want where they want (within limits of course). Provide them the resources required to get the job done and learn at the same time. Some form of free food also helps. If they still need extra motivation maybe its time for an honest conversation with them as to what they want to do and why its not working.

Just my $.02 AM

I would be very motivated if ... I make $$ 1,000,000 a month ... Work in a wonderful office, in a wonderful building ... No working hours, I only go to office when/if I want ... Work with very smart but also very nice and fun to be around people ... If I have all the time I need to do what I want, go to gym, travel around, swim regularly, spend all the time I need with my family etc ...

A point to be made here, we are motivated when stuff that makes us happy is around

We shouldn't confuse being motivated with being incited or urged to take action, you can be incited by witnessing bad events like seeing a person in need

When we speak about being motivated in work, I don't think we have bad things in mind, like have a bad boss or a slow computer ...

So finally, the problem of motivated I believe can be one at two end: 1) You don't have enough money to bring in the good stuff. 2) You ... spoiled your workers!!!

This strategy might work with ego driven programmers, but I don't really want any of those guys on my team in the first place. I want perfectionists who know how to ship.

The threat of someone rewriting your code might be a good way spawn a good engineering discussion. If the discussion is constructive you might even improve the team and the code. But if micro management and lack of delegation results in frequent rewrite discussions, that will kill motivation for sure.

I wish someone would review my code and say "this and that sucks".

But I think most of my cow-orkers would take offense if I did this to them..

Why not try it? (Perhaps choose different phrasing than "sucks")

I think a lot of people spend time agonizing over "Well, sure I'd like for exactly this to happen, but I'm a special case and other normal people people wouldn't like that!"

Statistically speaking, you are far more likely to be in the general case than a special case outlier. (Reading HN notwithstanding.)

but what about when the 'interesting' stuff dries up and the new priority is building tedious features that your users want?

A former boss of mine thought it would be a good motivational strategy to try to create a little "friendly competition", as Dave Thomas puts it, by putting me and my coworker at odds with each other with various petty, fabricated psychodramas in the hopes that we would both try to compete for Daddy's favor. It didn't take long before both of us quit. This might work with sheep and race horses but simplistic algorithms like these have a tendency to not be very reliable when dealing with human beings. There are too many variables, such as, in the case of me and my coworker, going for a drink after work and realizing the design behind the conflicting narratives our boss was telling each of us in the absence of the other. It's probably quite a common strategy for managers but the dishonesty and apparent disrespect of it didn't sit too well with us at the time.