*
programming and human factors
by Jeff Atwood
*
There's an inherent paradox in motivating programmers. I think this Geek Hero Comic illustrates it perfectly:
It's a phenomenon I've noticed even in myself. Nothing motivates like having another programmer tell you they're rewriting your code because it sucks. Dave Thomas has talked about this for years in his classic Developing Expertise presentation, supported by the following quote:
Interestingly enough, a friend of mine (who is a quality control manager in a hospital) often makes identical statements in reference to doctors: Polite requests, coercion, etc. are useless at best and often detrimental. Peer pressure and competition are the key.Don't try to race sheep,
Don't try to herd race horses
Yes, the use of the term sheep is mildly derogatory, but the general principle is sound: use motivational techniques that are appropriate to the level of developers you're working with. If you have neophyte developers, herd them with maxims, guidelines and static rules. If you have experienced developers, rules are less useful. Instead, encourage them to race: engage in a little friendly competition and show off how good they are to their peers.
test
tt on May 23, 2009 2:15 AMGiddy up! Thanks for the tips, will try them this week.
Franchise Whale on May 23, 2009 2:16 AMSomeone funnier than me that I used to work with described our Operations Director as taking a carrot and stick approach to motivation - except that the carrot was really big, and he'd hit you with it.
Dave on May 23, 2009 2:42 AMI 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 on May 23, 2009 2:46 AMAM hit the nail on the head here. I'd also add that these sorts of competitions can be demoralizing - in the end, someone is "wrong". If all developers can come at an effort with humility, they'll understand that no code is perfect, and there are often many ways to solve one problem.
Umbrae on May 23, 2009 3:09 AMAM FTW.
If somebody comes to me and tells me that they've found a problem with my code, I'm grateful, and ask them to show me the fix so that I can understand where I went wrong and not repeat the mistake.
In any of the teams I've worked in, the programmer in the comic above would be the first against the wall when the revolution came.
Joe on May 23, 2009 3:16 AMI've run competitions in our office several times to create the "best" and most optimized code for a task and I won every time (note: there was no particular experience bias in the competitions)
Is the conclusion I should sack everyone else and write it myself?
Your right that some competition encourages better code - but I think that a better approach is a few good coders who will "get there in the end". Because the finished product is inherently better and more complete.
errant on May 23, 2009 3:31 AMBullshit. Rules are also good for exp. programmers. Yust because a programmer think hes good, he should not leave the path of rules. It is yust a lousy excuse for people who are to lousy at coding to follow rules, do comments rigth and so on.
gadthrawn on May 23, 2009 3:59 AMA some more bullshit for programmer who cannot follow rules or do comments the right way. There is nothing like an experienced programmer who should not follow rules. That are the bastard which code cannot be read a while later (even by themselves) and therefore not mantained.
AND THIS FUCKING VERIFICATION THING BEYOND SAYS FOR 1 COMMENT tHAT THERE ARE TO MANY COMMENTS. LOUSY BULLSHIT.
gadthrawn on May 23, 2009 4:03 AMAh...after a while the comment is shown even if the message is to many comments. sick. what are ropolitan bonitoes? #somtehing to eat?
gadthrawn on May 23, 2009 4:04 AMAs some have already indicated, that depends on what "flavor" the competition in your group/office is. It is strongly tied to what flavor (if any) of "teamwork" and "management culture" you have. When you have a culture of collaboration, the competition will be focused on contributing and helping others or "the team"; when your culture emphasizes "leadership" (and especially when that is attributed based on "visibility", posture, and verbal claims), this will foster domination by the most competitive and backstabbing jerks, and people who are not of that description will tend to drop out of the competition, or even withhold their "normal" level of contribution.
The use of peer pressure as a deliberate "performance management" tactic (as opposed to leaving it at the (healthy?) level to which it grows "organically") almost always correlates with the latter - bullying, poseurship, mediocrity, and politics.
Association fillip
.. hm.. lets see if it can make some sense:
Association to fillip: Shakespeare:
What is this?
Your knees to me? to your corrected son?
Then let the pebbles on the hungry beach
Fillip the stars; then let the mutinous winds
Strike the proud cedars 'gainst the fiery sun;
Murdering impossibility, to make
What cannot be, slight work.
That verification game below is funny.
Remaining removal - take out the waste
I never obeyed rules, I always left office before everyone else :-D
Itay Moav on May 23, 2009 4:24 AMI also agree with AM -
You want your team members to be motivated to help each other, and competition sort of kills this off.
All you need for a motivated programmer is a positive work environment, a manager that doesn't micromanage, and an interesting task :)
Mike on May 23, 2009 4:47 AMApologies @AM, but that sounds like load of pointy-haired hogwash and bollocks.
"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."
You propose hiring people who dont care that whatever job they just did is so inadequate that it must be scrapped & redone?
"There is a very big difference in 'taking pride' in your work and 'being proud' of your work. "
How can you take pride if you arent proud of your work? The semantic difference you're slicing hairs over isnt nearly as obvious to me as it seems to appears for you; what exactly is the difference, please explain.
". . . 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."
I'm more receptive to this, but rewrite has very different meaning than refactor. Sometimes yes even rewrites are necessary, but there'd typically better be an epic story about changing requirements or extreme hardships encountered (or egregiously crappy code; code that qualifies as _dangerous_ to a project). I expect an awfully long retrospective when the word rewrite is raised.
Refactors should be continual, but refactors are usually related to bringing different bodies of code better in to alignment, rarely about fundamentally changing the way code is working: lessons learned + code improved type situations, and algorithmic changes only when trying to adapt to different patterns.
rektide on May 23, 2009 5:13 AMAwwwww,... did you change your beloved and mind intriguing orange captcha because of peer pressure?
I kinda miss that orange captcha.
Dhany on May 23, 2009 5:15 AM“Nothing motivates like having another programmer tell you they're rewriting your code because it sucks.”
Maybe I’m not a typical programmer, but I find someone telling me my code sucks is the opposite of motivational. In fact, wasn’t there some research suggesting that “bad apples” like this could reduce team performance?
http://www.codinghorror.com/blog/archives/001227.html
AIIIIIIIIEEEEEEEEEEEEEEEEEE!!!!!!!!!!!!!!!!!!!!
I typed "orange" and my post got rejected!
Michael on May 23, 2009 6:20 AM..or you could try treating them like human beings..sheesh.
capar on May 23, 2009 6:52 AMRules are to be followed until you know _why_ they're rules and when it's appropriate to bend, twist, or outright break them.
James on May 23, 2009 7:35 AMholy crap the orange captcha is gone!!!
and btw reCAPTCHA isn't that great i'd recommend http://www.phpcaptcha.org/
There is no such thing as friendly competition. Judging each other and ourselves is useless. Stop promoting it Jeff
mempko on May 23, 2009 10:01 AMI wouldn't know. Nobody has ever rewritten my code while I was still there. (Except me. And I hate that.) :-)
PRMan on May 23, 2009 10:59 AMWhoa... When did you get rid of the "Orange" captcha? I kinda miss it.
Interesting post. I wonder which I am?
Asmor on May 23, 2009 10:59 AMRules are fine, so long as you understand and agree with the reasoning behind them. Few things are as useless and discouraging as are rules seen as arbitrary - "use the new coversheet for your TPS reports"...
Friendly competition is fine, so long as it stays friendly; let it get out of hand, and watch cooperation disappear, as each team or each team member begins to view sharing information as a liability.
Orange is no longer the CAPTCHA, eh? Well i for one welcome our youngest dormice...
Shog9 on May 23, 2009 11:06 AMIt cuts into your sovereignty as a programmer.
Joey Robert on May 23, 2009 11:08 AMHow is this a paradox?
Programmer1995 on May 23, 2009 11:28 AMBest post here in a long while. I was beginning to despair.
Anyway... looks like "orange" is no longer good enough.
Joel Coehoorn on May 23, 2009 11:31 AMI agree, and I would say more, if it wasn't for the more pressing matter - are you going to write another version of the orange article now?
Now you've pointed this out no self-respecting programmer is going to obey rules because that would make them a sheep.
I'm definitely a racehorse. :)
Paul on May 23, 2009 12:19 PMShouldn't you try to motivate them before they write the code, not after?
Dom on May 23, 2009 12:33 PMCompetition does motivate me, but telling me my code sucks is simply stating a fact I already know. At the end of a software project I'll know far more about the problem domain than I did at the beginning, so any solution I programmed in the past sucks compared what I could do in the present.
Jester on May 23, 2009 12:44 PMSorry, but what a load of rubbish.
If your programmers need those kinds of shallow tactics to produce code, your methods are wrong; your management sucks; and you most definitely have the wrong programmers. They should be proud of every line they collaboratively produce, not constantly looking behind their backs.
Chris on May 23, 2009 12:49 PMIt works on me, that's for sure. I don't really get offended by it though (although, depending on WHO is going to change it, sometimes I worry that they will just BREAK it).
Taylor Marshall on May 23, 2009 12:52 PMHaha... I'm still in college, but I'm in the second (competitive) group - it always throws my friends off when I let that side show...
Izkata on May 23, 2009 1:12 PM"Best post here in a long while." Agreed. I laughed, I felt enlightened. Awesome.
ian on May 23, 2009 1:18 PMI recently gave in with a co-worker producing ridiculously amateur code, and have given up the "lets see what we can do to improve your coding" game and switched to the "rewriting from scratch the last week of code in 2 hours" plan. While there may be merit to threatening to rewrite someones code, actually having to do it is horrible and I would not recommend it unless their code jeopardizes your project. Its akin to having people on the team slapping each other in the face, and its not a pleasure for either party.
My verification CATPTCHA is "waste of": thats somehow fitting.
rektide on May 23, 2009 1:37 PMthis post reminds me of the games we used to play at school. those of you who remember turbo C know that it was/is extremely unforgiving. instead of competing against each other we would see who could sit down and type a program form start to finish, compile it and have it run with out a single bug.
of course some malicious moron (Mr malice) on the team would type a letter, symbol or the number zero into your program just to break it which also taught us to "idiotproof" our programs.
then that lecturer at university with his day one motivational talk. "hello all, I'll be taking you in C. not all of you will be here at the end of the year. it is not your fault. they call me Mr malice, but that is okay..." most people hated him, some quit his class and a select few of us remember him with fondness now because they can write code. working code. the motivation, cajoling and competitions shaped me.
"they call me mr mallice, but it's okay..."
jake on May 23, 2009 1:46 PMRules are always needed at some level. Race can be harmful at some level even if it was meant to be friendly.
Silvercode on May 24, 2009 2:14 AM>> you have UML Specification of your project
If you have that, you have bigger problems than just motivation of programmers. You probably program in Java, you (mis)use Agile and TDD, and your software is overengineered to hell. Your developers regret they were ever born, but come to the office for the paycheck, and pretend they're working by coming up with more UML, unit tests (that don't test any failure cases), and Spring configuration XML files. It's kinda hard to motivate people in this environment.
DMB on May 24, 2009 2:28 AMThis is definately true.
At a pevious job I was the sole developer on a project. It was good but I was managing everything so sometimes I would be more motivated to check mail and only do the bare minimum work in a day.
Until one day I was off sick and another developer had decided to change large, random parts of my code!
I was quite annoyed and just had to jump up and fix everything.
Dean Nolan on May 24, 2009 3:07 AMNice post! I think it's very true. Your post inspired me a dream up a Code Fight competition (http://tejasjoshi.wordpress.com/2009/05/24/code-fight-competition/) in my dream organization.
Tejas on May 24, 2009 3:08 AM"You'll turn into Jeff Atwood if you don't do your work!" That's how I would motivate my programmers.
Richard Kyanka on May 24, 2009 5:12 AMHelp - I can't read this Captcha!!!
Seriously though, the most motivating thing I have seen is having developers' code peer reviewed at scheduled meetings. This allows "star" developers to educate others, and seems the best way to facilitate knowledge sharing. Just don't leave the meeting until the code is completed, then you just come up with a lot of frustrating "you should have done XYZ".
I've never found competition successful in IT, people in IT tend to be the most un-competitive people I've met, and the fact another developer is editing their code just leaves them smirking with a wry smile as if to say "gool luck sucker".
Great blog, think everyone has experienced the motivation of code being discredited as bad.
Qua on May 24, 2009 5:42 AMWhat de-motivates me are managers going on about hard work, bonus schemes and teamwork while their 'plans' are a series of guesses that are presented as 'deadlines'.
Sam on May 24, 2009 6:21 AM@gadthrawn: chill and desist
@AM: ++1
@jeff:
Erm... my condolances for getting even more agitated responses for ditching orange then before... I'm pretty sure I was I was solid in the fron rows of that peer-pressure faction hehe
Anyways, as ever, you can expect the fuss to die down with time (as the surprise gets forgotten) and there is reason to assume there will be less residual croaking on the topic of captcha, since, well, erm... it is simply less *broken*.
To be fair, I miss the oranges as well. May I suggest
Behold the correct word:
Or perhaps make it disabled to prevent it getting the focus (or you'll still get flames :)).
Disclaimer: my HTML stems from the Gopher era. Plus it hasn't been exercised *since* the Gopher era.
seth@mailinator.com on May 24, 2009 6:26 AMApperently "no HTML" does not imply "plaintext" as I assumed:
label for="orange" Behold the correct word: /labelinput name="orange" id="orange" value="orange"/
Also: s/fron/front/, s/then/than/
Having "orange" as the captcha was never going to work for long. reCaptcha's a good step up.
Merus on May 24, 2009 6:51 AMThe most memorable quote from my programming days in college
after I complained how hard it would be to create bounding boxes in my ray-tracer.... my friend said to me:
"Oh, well, I think I could do it in about an hour"
The race was on!
-Orange
Anonymous on May 24, 2009 7:49 AMDitto to AM's comments. Plus, why wasn't the problem caught during the code review before it was baselined? Did testing or operational use determine that the system wasn't meeting its response time specifications? If so, was an analysis of the system done to pinpoint Randall's code as the code that should be changed to fix the problem? Or, is this a case of premature optimization?
David A. Lessnau on May 24, 2009 7:57 AMI'm an engineer on the reCAPTCHA team -- it's great to see reCAPTCHA on codinghorror.
@rektide -- We believe that CAPTCHA's shouldn't be a "waste of" time, which is why one of the words is from an old book or newspaper which we're helping to digitize.
@Andrew -- The phpcaptcha.org captchas are all fairly trivial to break, they use color in such a way to make breaking the CAPTCHA much, much easier. None of them present any challenge in segmentation, and some are probably harder for color blind users. Sadly, there are a lot of CAPTCHA implementations out there which have not undergone proper usability and security testing.
PS: just noticed this -- you might want to set the tabindex property using javascript so that people can tab from the comment box over to the CAPTCHA field
The logical extension of this is that no developer works on any part of the code for any significant period of time without handing it off to another team member. Period. No exceptions. If you're using pairs, then substitute "pair" for "developer".
To start, I suggest a time period not greater than 1 week. That should be more than enough to get the code working, or improve it, or fix any bugs assigned to you. And if it takes longer than that, the next developer in rotation will take it up.
The benefits should be clear. Developers will be forced to either document their code or communicate with one another. The bad apples who can't communicate or can't write maintainable code will become painfully obvious to everyone, rather than being able to hide in the shadows or bury incompetent work. All the code will eventually rotate through every developer, so familiarity will be widespread. All the code will also be reviewed by every developer, and if bugs can't be immediately fixed by one, they will be annotated in the source. Furthermore, because no one person controls any part, the overall team morale will organically support the team as a whole and the product as a whole, rather than being divided into petty fiefdoms and isolated areas of alleged expertise.
Sounds great, doesn't it?
So ask yourself why reality doesn't work that way.
Ed on May 24, 2009 11:48 AMI'm OK with someone telling me my code sucks. If he can tell me WHY.
PaulG. on May 24, 2009 12:01 PMI agree with Jeff. Not so long ago a senior developer I deeply respect, was looking at my code and mumbled something to the effect of "how can people write something like this?"
The result was that I refactored my code, and made is smaller, faster, more modular. A hurt pride does wonders.
And people, stop acting like prima donnas - chances are you aren't the best, and constructive criticism and competition are here to help you. Shut down your egoes for a second, use your brains.
Max on May 24, 2009 12:16 PMThe other side of the coin that I've seen is when other developers try to rewrite someone's code cause 'it sucks' when in reality, that code is great, but the person rewriting it is not smart enough to understand it or even work with it.
Heck, I've even been guilty of this, only to find out later after many trials my code is approaching the code that I am trying to rewrite.
Steve-O on May 24, 2009 1:14 PMI don't get it. What's the paradox? hm ... ok, cool, whatever.
Charles on May 24, 2009 1:46 PM@James: I think that is crap. Many programmers think they know why and when to break rules. But they don't. If you work in big project breaking style or programming rules is counterproductive and making other programmers extra work in "fixing" the bullshit to standard format when maintaining the code.
My experience says (or better: screams out loud) that the experienced programmer you mentioned are the ones which does not follow coding guidelines, does not comment code, does not know what there codes does a year later (and also have no longer the domain knowledge) and much much worse: Do not follow specification documents and not give back feedback where they "twist" it. Then you have UML Specification of your project, and in some parts quite fast lacks where a stupid coder thinks he knows better. Normally this types of programmers change projects so fast that they never now how much money they burn.
DawnOfWar on May 24, 2009 1:51 PMAnd oh, i've a "dogmatic dignity" .... if you think about the captchas, they try to make sense
DawnOfWar on May 24, 2009 1:53 PMAs long as there are developers who think:
It cuts into your sovereignty as a programmer.
There will be the need to motivate developers. You're not a frakkin country. Not checking in to source control may be the equivelant of borders, but when you're working on a team for someone else, you don't have the right to go dark. Sovereignty.
K2TheX on May 25, 2009 2:16 AMSo, I guess your next post will have to explain the advantages of reCaptcha compared to orange ...
MyKey_ on May 25, 2009 2:51 AMHey Jeff,
I don't know whether this ever happened with orange, but I had to do an extra reload after posting my comment because I didn't show up the first time.
MyKey_ on May 25, 2009 2:55 AM@Max
“And people, stop acting like prima donnas - chances are you aren't the best, and constructive criticism and competition are here to help you. Shut down your egoes for a second, use your brains.”
I’m all in favor of constructive criticism, but I don’t think that’s what Jeff is arguing here. Rewriting someone’s code “because it sucks” is not constructive, and encouraging developers to “show off how good they are to their peers” is not asking them to shut down their egos.
@MyKey_
"I don't know whether this ever happened with orange, but I had to do an extra reload after posting my comment because I didn't show up the first time."
I don't think that's anything to do with the improved captcha - I used to have to do that with the old orange method.
Personally, I’d like to congratulate Jeff on finally fixing the captcha. Now if only he could fix the other problems with comments, such as adding threading, or at least numbering comments.
Steve W on May 25, 2009 3:47 AM@Steve W
Agreed! Numbering comments would be an improvement.
MyKey_ on May 25, 2009 3:56 AM@Steve-O
"but the person rewriting it is not smart enough to understand it or even work with it."
That's pretty much my definition of "this code sucks".
Anonymous on May 25, 2009 6:43 AM
Internal competition has to walk a fine line between in-fighting/insecurity and promoting an enjoyable/learning atmosphere at work. Anything that destroys cooperation within your software team is going to be detrimental at some point.
Where I work the notion of code "ownership" is an officially sanctioned, strictly enforced policy ("thou shall not touch my code or you shall be piunished). I cannot convince the management that it is a counterproductive practice so I learn to live with it.
And here I get something unexpected. Based on the comments above, I conclude that officially-sanctioned "code ownership" is not such a limited practice as I thought. In fact, most commentors seem to accept it as quite natural.
I am very (unpleasantly) surprised. Was I wrong in my beliefs?
Jeff I don't think you have any basis for this argument I know best you don't get out
Anonymous Faggot on May 25, 2009 10:46 AMHey, great post, and I'm glad to see a popular site using "reCaptcha". It's a great example of killing two birds with one stone.
A. L. Flanagan on May 25, 2009 11:04 AMFight, slaves, fight!
Fight, slaves, fight!
Fight, slaves, fight!
Gooooooooo SLAVES!
I just wanted to say Jeff, this was a very timely post. Keep up the good work!
Matthew Sweet on May 26, 2009 7:46 AMAnd somehow developers rise to say designers are prima donnas, vain people who can't stand criticism...
I'm licensed to say that, since I'm of both sides of this. : )
But an interesting thing to notice, nonetheless.
Bruno Bergher on May 26, 2009 8:15 AMThe irony is that this really is true, even when we know our code is not the fastest written...How DARE they improve my algorithm?
Go reCAPTCHA!
If you refresh enough you are likely to still see "orange." :D
(And you might win the lottery too)
Practicality on May 26, 2009 8:20 AMBad analogy. 'Racehorses' are herd animals:
http://en.wikipedia.org/wiki/Horse#Behavior
so... you absolutely can 'herd racehorses.' In fact, you herd these horses any time you let them wander the pasture, or lead them into a stable.
If you race a horse 100% of the time, you'll only wind up with a dead racehorse.
Cooperation and teamwork both are well and good, but when bonuses and promotions often are geared to individual performance, they can be thrown by the wayside. If someone has family responsibilities, going home to the wife and saying, "I didn't get the raise, but I sure did work well with everyone" isn't going to cut it.
It's a competetive world, boys and girls. If someone isn't up to snuff when it comes to being able to do the work, it is doing a company absolutely no good to waste time getting them to a serviceable level. It's best to cut your losses and move on. Having someone who needs to have his code reviewed and rewritten constantly is worse than having no one at all. No one is perfect, but you probably can think of someone you've worked with who clearly wasn't good enough.
Ideals are great, but let's live in the real world. It's survival of the fittest.
Jay on May 26, 2009 11:23 AMGreat post! Programmers need to 'race' in order to stay competitive. You need a few people in your organization who can make others 'race' and keep them not only on the edge of their seats but also on the edge of technology. I currently fulfill a role something akin to that in my workplace :) Programming is challenging and that's why we like it. Moreover, programming has a lot of challenge left because it is still largely an art. Every program can be made better from one perspective or another, and every time you 'race' yourself you become a better programmer.
Tathagata Chakraborty on May 26, 2009 11:37 AMDepends if you are self-centered and competitive. Some of the worst code I wrote in the .NET framework is being rewritten from scratch right now, and I couldn't be happier about that...
Bertrand Le Roy on May 26, 2009 11:42 AMMicrosoft does this and has got hit a lot more than it would admit.
Google, on the other hand, takes Grand Challenge type problems and asks their guys to cooperate, not compete. They dont fight each other, or peer-pressur-ize the office, they fight tough problems and do concept mashups to make new solutions to big problems. ( I'm not going into negative aspects of known Microsoft management strategies. )
The end of "The Era of Orange" ;-) seems like the end of Agent Orange! :-D :-D
But Rays of hope from The Mountains are still very tricky, as always...
ReCAPTCHA-ing the web isn't all that appealing for a *workhorse*, race horses may rightfully disagree.
Haha, CodingHorror readers are sitting in front of the their PCs pressing the refresh button on reCaptcha trying to get it to display the word "Orange"...
UPDATE: 'Practicality' beat me to it :)
-Agent Orange
Juan on May 27, 2009 3:04 AMI like the idea of using this on doctors. They are hard people to get to listen to you.
Regis on May 28, 2009 4:40 AMRules are essentially abstractions. They're meant to encapsulate the details of some process so that thinking isn't required to carry out the process in a consistent way.
Since a rule is essentially an abstraction, it follows Joel's "Law of Leaky Abstractions", stated thus:
"All non-trivial abstractions, to some degree, are leaky."
Level 1 & 2 programmers can't identify the leaks. They aren't able to perform necessary re-evaluations of the rules to make them more robust and more performant. I work with many developers (some with 10 years under their belt) that are stuck at level 1-2. They lead teams of others, and their non-technical management just accepts their poor performance and chalks it up to: "Well, i guess that's just how long things take."
AUTHOR: Anon
DATE: 05/29/2009 12:33:00
URL: http://thegame.com
hahaha! Excelen joke, and it is true.
Walter
At my last job I had a coworker who didn't care about code quality, only that "it worked". Eventually, I tried something like this and got nowhere. Ironically he's now in charge of updating his own code, so he's starting to get it, but still seems to treat all projects as one off solutions he'll never look at again - despite being forced to look at them again.
On the other hand, I have no illusions of perfection, and want other programmers to review/improve my code.
I can't believe no one has mentioned the fact that both animals mentioned are motivated by threats in order to perform the behaviors they are associated with. The race horse has a small being at least a quarter of its size (presumably containing a quarter of its natural talent as well) sitting on its back whipping it to run in a circle. The sheep have to deal with a yappy little dog nipping at its ankles all day in order to be herded.
Count me out of being either...both possibilities sound horrifying.
Mike Foster on May 31, 2009 10:34 AM@Jay: The company should have rules for programming. Also there should be code reviews in any case. Some rules could be enforced by automatic check runs.
If someone breaks the rules, he should correct the mistakes, not someone else. If the breaker doesn't correct, then he might get away with it, but others start to dislike the rule breaker.
All code should look a bit similar, not different. And there are many rules that are not just about style, for example normalizing the database to the third form. You can compete with others still, but there should be some minimum rules that should be followed. I mean if your company regards it good / obligatory practise to use some rule, then make the rule a rule, not a gossip. If you just gossip about how someone didn't follow a "rule" and therefore is worse than others, what good that gives?
Silvercode on June 2, 2009 4:06 AMAnyone is welcome to rewrite my code!
distil on June 3, 2009 8:05 AMJust show me the money. Its the only motivation I need. YOu can have your reasons. Money works for me. It can buy whatever else I can think of.
about this on June 4, 2009 12:10 PMi don't believe this applies to all coders..
some coders i've encountered don't even care what will happen next to their codes once they've seen it working.
they will even appreciate it if somebody modifies their codes! saves them the work.
yayix on June 5, 2009 10:32 AMBeen there, done that.
Josh on June 5, 2009 1:14 PMReally, what you have written is a bit of a nonsense.
Motivation is a managerial issue and there are many different techniques to motivating individuals, groups and teams which applies to any profession.
Stick to talking about programming (because your 'About Me' section suggests you might know something about that) and leave articles on management techniques alone!
Greg on June 9, 2009 6:05 AMShoot, must not show this at work otherwise they will actually force me to code again :)
Raul on June 12, 2009 10:06 AMAnybody notice that the guy in the bed is "Randall Monroe", rather similar to "Randall Munroe," of XKCD fame?
Allen on July 20, 2009 8:12 AMsome coders i've encountered don't even care what will happen next to their codes once they've seen it working.
links of london on August 26, 2009 3:19 AMhaha... so true!
I admit, the thought of someone ELSE redoing my code makes me a cringe a bit to myself, especially when it's something I've been working long and hard at.
Travis on September 25, 2009 9:05 AMIt was a very nice idea! Just wanna say thank you for the information you have shared. Just continue writing this kind of post. I will be your loyal reader. Thanks again.
Wow gold on September 30, 2009 1:55 PMJust show me the money. Its the only motivation I need. YOu can have your reasons. Money works for me it can buy whatever else I can think of
sevgiliye hediye on October 14, 2009 8:38 AMThis is only a preview. Your comment has not yet been posted.
As a final step before posting your comment, enter the letters and numbers you see in the image below. This prevents automated programs from posting comments.
Having trouble reading this image? View an alternate.
| Content (c) 2009 Jeff Atwood. Logo image used with permission of the author. (c) 1993 Steven C. McConnell. All Rights Reserved. |
Subscribe in a reader
Subscribe via email
Posted by: |