
Coding Horror: How to Motivate Programmers - Anon84
http://www.codinghorror.com/blog/archives/001260.html
======
aditya
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".

~~~
edw519
"...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.

------
radu_floricica
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.

~~~
aditya
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.

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

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

------
ellyagg
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.

~~~
frossie
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.

~~~
mannicken
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.

------
bawr
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?

~~~
kscaldef
> 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.

~~~
bawr
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. :)

~~~
kscaldef
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.

------
dood
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.

------
edw519
"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.

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

~~~
edw519
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.

~~~
pm
Indeed, all salient points.

------
amstrash
(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

------
systems
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!!!

------
warwick
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.

------
fizz
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.

------
overman
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..

~~~
sokoloff
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.)

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

------
villageidiot
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.

