Beta

×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Why Coder Pay Isn't Proportional To Productivity

timothy posted more than 4 years ago | from the productivity-is-a-blunt-edged-word dept.

Businesses 597

theodp writes "John D. Cook takes a stab at explaining why programmers are not paid in proportion to their productivity. The basic problem, Cook explains, is that extreme programmer productivity may not be obvious. A salesman who sells 10x as much as his peers will be noticed, and compensated accordingly. And if a bricklayer were 10x more productive than his peers, this would be obvious too (it doesn't happen). But the best programmers do not write 10x as many lines of code; nor do they work 10x as many hours. Programmers are most effective when they avoid writing code. An über-programmer, Cook explains, is likely to be someone who stares quietly into space and then says 'Hmm. I think I've seen something like this before.'"

cancel ×

597 comments

Sorry! There are no comments related to the filter you selected.

As always, make yourself known (3, Insightful)

sopssa (1498795) | more than 4 years ago | (#30537916)

Programming is usually team work and as such kind of hard to measure compared to salesman who just pulls for himself. Another thing is that coders aren't usually that good at expressing themself, so it may not be obvious who is being more productive than others.

And how do you measure that productivity? Is it the amount of code you write? What if its bad code.. Is it the quality of code? What if that shows up as less productive.. No one notices unless you make it visible and show your boss or developer that you're the man.

But being awesome coder and making upper level see it won't get you 10x salary. It might get you a better salary, but at that point you should probably aim for developer position or boss level, because that will happen eventually.

I know a person who used to run a application company. There was a coder who worked as such for some years, but he also took more important stuff to handle in the company. His boss always told how good coder he is and definitely noticed him over the others working there. Later he became the boss running that company, when the old one stepped down and only owned the company anymore.

But want to just work as an average coder? Expect average salary.

Re:As always, make yourself known (1)

sopssa (1498795) | more than 4 years ago | (#30537934)

To clarify, I mean developer more as a designer like guy.

Re:As always, make yourself known (2, Funny)

Anonymous Coward | more than 4 years ago | (#30538000)

Thanks for the recap of the summary.

there are Programmers then here are PROGRAMMERS (1)

pilgrim23 (716938) | more than 4 years ago | (#30538008)

Writing a new routine for an accounts payable system is one thing but.. there are just so many Gary Kildalls, Bill Gates and Paul Allen, Woz and Jobs, or John Carmacks in the world and these are paid by the universe accordingly. Of course there are also many Phil Katz out there too..

Re:there are Programmers then here are PROGRAMMERS (4, Insightful)

spiffmastercow (1001386) | more than 4 years ago | (#30538228)

I'd argue that there are more of them than you think.. It's just that all the hard (and cool) stuff has already been done. So the guy who 30 years ago might have developed the first viable JIT compiler is now working on some esoteric feature of some esoteric codebase that you've probably never heard of. There's a lot more programmers now than there were when those guys got their start,

And for the record, I'm probably a better coder than Bill Gates ever was (as for a business-man, not so much).

Re:there are Programmers then here are PROGRAMMERS (0)

Anonymous Coward | more than 4 years ago | (#30538350)

Have you written an interpreter for an embedded system with 64 kB of RAM? BG is a lot better than you give him credit for. Not as good as Paul Allen, no, maybe not as good as Simonyi, and gods know he can't hold a candle to Knuth, but he was pretty decent in his day.

Re:As always, make yourself known (4, Insightful)

JWSmythe (446288) | more than 4 years ago | (#30538032)

    But, code is a product, and expected to be created. The value is obvious when it's completed, but still worthless to the bean counters until someone in sales sells it to a customer. The more customers they sell the code to, the more profitable it's become.

    The thanks never comes down to the programmers. When the product is completed, it's likely they'll be let go, since no more work needs to be done. The sales staff could continue selling it for years, and making a profit.

    I was told, I have to be able to sell the product. That's not where I want to be. I like creating things. I prefer to leave it up to sales to make it profitable. Unfortunately, the way most bosses run the show, development will always be a negative cashflow area, and sales will always be positive. In that, they consider development bad for the company, and forget that without our work, they'd never turn a profit.

Re:As always, make yourself known (2, Insightful)

sopssa (1498795) | more than 4 years ago | (#30538096)

That's probably where the term "code monkey" also comes from. It's sad but true. The only solution probably is to start your own company, or do things independently. However that usually requires you to create the idea too, not just following specs. But theres on good thing - on internet age it's easy to get marketers for you who promote the product for a share of income (CPA marketing).

Re:As always, make yourself known (2, Informative)

BrokenHalo (565198) | more than 4 years ago | (#30538114)

In other words, the work of a true programmer is beyond recompense: for citation see The Tao of Programming [canonical.org]

Re:As always, make yourself known (5, Funny)

Intron (870560) | more than 4 years ago | (#30538250)

The thanks never comes down to the programmers. When the product is completed, it's likely they'll be let go, since no more work needs to be done. The sales staff could continue selling it for years, and making a profit.

This is why I always leave lots of bugs in the code, and name the variables: a, aa, aAa, Aa, etc. They can never fire me.

Re:As always, make yourself known (2, Funny)

Verdatum (1257828) | more than 4 years ago | (#30538322)

Yes, we all know about "Job Security". God I hate it when people who aren't me do it. They move on to a bigger and better job, but don't bother to fix the their code before escaping.

Re:As always, make yourself known (4, Insightful)

FooAtWFU (699187) | more than 4 years ago | (#30538262)

When the product is completed, it's likely they'll be let go, since no more work needs to be done. The sales staff could continue selling it for years, and making a profit.

Software that's finished in finite time? (Forever-finished, not just this-release-finished.)
What a concept! Exactly what segment of the industry are you working in over there? If my organization stopped development for a year or two just to sell the existing stuff, our competitors would soon crush us handily.

Re:As always, make yourself known (4, Insightful)

liquiddark (719647) | more than 4 years ago | (#30538352)

Probably games. God knows they seem to stop working on the damn things as soon as the first blush of cash crosses the table.

Re:As always, make yourself known (2, Interesting)

rolfwind (528248) | more than 4 years ago | (#30538058)

And how do you measure that productivity?

Perhaps instead of trying to measure productivity directly, it could be done in other ways. For instance, there needs to be a project done - get two small teams together to tackle it: the first that gets a functional prototype done has their Tech. Dir. given the job, as well as being able to assemble his team from both. Notice which people always gets to be chosen on a team in both phases, promote those people, and let go of the people never chosen.

Sure, that may be a bit of a popularity contest in the second phase (not so much the first) but then again it's about teamwork and coding already has too many "uber-genius" prima donnas that are a nightmare to work with.

If managing were as easy as reading a guage that said "PRODUCTIVITY", you might as well get rid of the expensive managers and have a monkey read it.

Re:As always, make yourself known (5, Insightful)

PopeRatzo (965947) | more than 4 years ago | (#30538164)

No worker in America has pay which is "proportional to productivity". That's not how our system works.

As long as you've got CEOs making 200-400 times the pay of the average worker in the same corporation, it is impossible to have any pay which is "proportional".

The specific kind of profits which most American companies strive for, the short-term profits that they return to their equity shareholders, make it necessary to pay all workers less than they are worth. And the trend is accelerating. If the same reduction in real income for workers that started during the Reagan administration continues, in 20 years the majority of American workers will be making about ten percent over minimum wage.

Re:As always, make yourself known (3, Insightful)

dkleinsc (563838) | more than 4 years ago | (#30538378)

This very problem was written about [wikipedia.org] (at great length) by some guy named Karl Marx. Basically, his point was that the capital owners will always pay their employees less than they're worth to the capitalist, because that creates profits.

Re:As always, make yourself known (0)

Anonymous Coward | more than 4 years ago | (#30538186)

Not a good measurement. A fully perfectly working prototype could be easily put together if you totally ignore the fact that you later have to maintain it. Or do you mean prototype as in "proof of concept" with the idea that it will scrapped for a "proper" implementation later? I wish that was the case, but unfortunately I have never seen it happen in the real world.

Re:As always, make yourself known (2, Funny)

Verdatum (1257828) | more than 4 years ago | (#30538346)

If managing were as easy as reading a guage that said "PRODUCTIVITY", you might as well get rid of the expensive managers and have a monkey read it.

Oh, so you've met my manager! (Hopefully he isn't reading this. If so, then, uh, lol j/k!)

Re:As always, make yourself known (1)

HermMunster (972336) | more than 4 years ago | (#30538216)

In WA State, as well as others I'm sure, Microsoft managed to get passed a law that says that programmer's needn't be paid for overtime, essentially making them non-exempt. I'm sure this is more the case than the author's explanation. They don't pay more for more productivity because they don't have to. Though programmers do get bonuses and other compensation based on how good a job they do.

Because it's hard to measure (1, Redundant)

rolfwind (528248) | more than 4 years ago | (#30537954)

Especially for organizations that love their metrics.

With a trucker, it's easy: they drove X miles, had Y accidents, Z fines/tickets, and Q complaints from customers he dropped stuff off. They'll want to maximize X, and minimize everything else.

Because a programmer's code doesn't live by itself but is meshed in between those of other programmers most likely along with a bunch of other factors - it's hard for a point haired boss to measure his productivity just by bug count and whether the project gets done. In that case, it might be best just to have his technically minded supervisors judge members of their team.

Re:Because it's hard to measure (0)

Anonymous Coward | more than 4 years ago | (#30538006)

There is a still a problem with this as the managers still need numbers to go by. Our upper management/directors can only go by hours, whether or not you are clocked into the building. I have gotten bitched at a few times for not always hitting 40hours, yet I always end up fixing more and doing more than alot of other people around who spend their time just gabbing about WOW or some other stupid crap. The manager I report to has told me he doesnt give a crap about hours as long as I finish what Im supposed to and that I consistently finish it in it time and do a good job on it, and as such usually just gives me a verbal slap on the wrist since as he said he doesnt care if Im there or not as long as I get the job done.

Personally I hate that upper management even looks at what just the regular programmers are doing individually, besides that I thought being salary meant I was being paid to do a job, not fill a chair for 40+ hrs a week.

Re:Because it's hard to measure (2, Informative)

base3 (539820) | more than 4 years ago | (#30538100)

besides that I thought being salary meant I was being paid to do a job, not fill a chair for 40+ hrs a week.

You're close. Being salary means you're paid to do a job and spend >= 40 hours a week at work.

Re:Because it's hard to measure (2, Interesting)

Anonymous Coward | more than 4 years ago | (#30538366)

Speak for yourself. Around here, salary means = 35 hours per week, including 6 weeks of vacation. Salary isn't that much lower than comparable position in US, but yeah, I likely pay more than you in taxes. Suits me fine though.

Re:Because it's hard to measure (0)

Anonymous Coward | more than 4 years ago | (#30538028)

Scrum anyone?

Re:Because it's hard to measure (1)

Simon80 (874052) | more than 4 years ago | (#30538484)

Scrum is a good way to force programmers to be conscious of how well they can estimate the time taken to do things (a good thing), while also helping to document where people spent their time. I don't think that necessarily makes it good for measuring developer productivity. The problem is that any high level productivity estimate will fail to take into account the quality of the work, at least in the short term.

Re:Because it's hard to measure (5, Insightful)

nine-times (778537) | more than 4 years ago | (#30538174)

It seems to me that it's probably true that it'd be very hard to come up with good metrics for a programmer, but I think people should be more careful about metrics in general.

Sure, you can measure a bricklayer by how many bricks he can lay in an hour, but is that really how you want to measure him? What about quality? Doesn't it matter if the resulting wall looks good? Doesn't it matter whether the resulting wall will hold together under stress?

But now even those are pretty simple things. Let's get a little more complicated. You're a contractor and you hire 6 bricklayers. One guy doesn't seem to work as quickly as the rest, and they all give you comparable results. You fire the slow guy and suddenly all the other guys slow down. Quality drops. The client is less happy. What happened?

Maybe if you look into the situation, you find that the slow guy was slow because he was spending some of his time communicating with the client. He was spending part of his time overseeing the other bricklayers, keeping them on task, and keeping them from being too sloppy with their work. He's been serving a vital role in your team, but you don't see that just by measuring a couple simple metrics.

Like all statistics, productivity metrics can be useful, but they can also be misleading. You should make sure you really know what they mean before you make too many judgements on them. In evaluating your employees, it's better if you actually know your employees and have a sense for who they are, how they work, and how they fit together as a team. The value of a person just can't be represented in a couple of numbers.

Re:Because it's hard to measure (-1, Offtopic)

Anonymous Coward | more than 4 years ago | (#30538310)

if by "brick" you mean "turd", I layed down two of them last night. Blocked up the toilet real good, they did. What's the deal with low flow toilets? I don't consider myself a prolific shitter, but most of my brown trout need two or three flushes to go down. Where's the water savings in that? Granted, if all you're doing is draining the limber log, a standard toilet wastes water, but in that case I generally don't flush anyhow. Yellow is mellow but brown goes down -- word to live by.

Re:Because it's hard to measure (1)

BrokenHalo (565198) | more than 4 years ago | (#30538296)

Hmmm. Methinks you misjudge the work of a trucker. A trucker tends to be (in fact has to be) a highly tech-savvy person with an aptitude for maintaining a very high level of concentration for long periods of time.

Even if you never use it in your employment, I would suggest that the time and expense of learning to drive a seriously heavy truck would be well spent.

Its also ego-saving (1, Insightful)

Anonymous Coward | more than 4 years ago | (#30538456)

I expect 99% of the programmers who read this article consider themselves to be in the unnoticed uber-programmer category.

And probably more like 5% of them actually qualify.

I, of course, am in that 5%. But you probably aren't. Because you aren't me.

This has been known for some time. (5, Interesting)

MarchHare (82901) | more than 4 years ago | (#30537964)

See, for instance, section 2 (Productivity) of the Hacker FAQ [seebs.net] .

Re:This has been known for some time. (5, Interesting)

seebs (15766) | more than 4 years ago | (#30538092)

I really have to get around to rewriting that some day. But it's been a loooong time, and it's translated into enough languages that I'd feel sorta bad modifying it.

Re:This has been known for some time. (1)

PopeRatzo (965947) | more than 4 years ago | (#30538180)

Hey, it's seebs! Thanks for your work, which appears to have endured. I'm honored to be in the same thread as you.

Re:This has been known for some time. (1)

MarchHare (82901) | more than 4 years ago | (#30538208)

Well, you answered my question, then (in the other comment thread).

Thanks. And greetings.

Another contributor to productivity invisibility . (5, Insightful)

YXdr (1396565) | more than 4 years ago | (#30537974)

The uber-coder's code works the first time - it sits there silently and invisibly working.

Meanwhile, everyone is looking at the hard work and long hours being put in by the guy who's code needs lots of help. He gets the notice, not the guy who did it right.

Re:Another contributor to productivity invisibilit (5, Insightful)

GasparGMSwordsman (753396) | more than 4 years ago | (#30538066)

The other item that almost everyone overlooks is that an Uber-coder writes READABLE code. If you look at what a really good programmer writes you will be able to understand what is going on, even 10 or 20 years after it was written. Unfortunately, most people suck...

Re:Another contributor to productivity invisibilit (0, Offtopic)

meerling (1487879) | more than 4 years ago | (#30538244)

That's usually the case, but sometimes you write a piece of code that is so creative to solve a problem, it's not that someone else is incapable of reading it, rather they can't comprehend the complexity of the code. I've done that a few times.

The first time was in highschool. I wrote an app to help me with my algebra/trig.
I never saved it, but rather rewrote it from memory every day. Some days I had brainstorms of insight that allowed me to do marvelous things to improve the functionality and reduce the size. By the time the year was out, the entire program was one page of spaghetti code that nobody else could fathom, and it worked perfectly.
Back then, 6k memory was a common desktop memory, I had 16k, so yes, we saved every byte we could.

Challenge: Bet most of you under 20s couldn't write a full app for anything useful in less than 20k.
      (And no cheating by copying any of the archive stuff, like the 9-liners amongst others.)

Re:Another contributor to productivity invisibilit (0)

Anonymous Coward | more than 4 years ago | (#30538334)

That's usually the case, but sometimes you write a piece of code that is so creative to solve a problem, it's not that someone else is incapable of reading it, rather they can't comprehend the complexity of the code.

I think GP's point is that you are not an über-coder, because an über-coder would've found a simpler, more easily understandable way to solve that same problem.

Re:Another contributor to productivity invisibilit (1)

geekboy642 (799087) | more than 4 years ago | (#30538360)

It is harder to debug than to code. Logically, if you write something as creatively as possible, you are not smart enough to debug it. If you are a smart programmer, your 'clever' code can be so impossible to debug by others that it must be entirely replaced to be corrected. Write legibly and clearly. Your compiler can optimize just fine, as long as you follow the general rules of legibility and reuse of code.

In a world where 2GB of ram on a desktop is standard, it's nothing more than intellectual masturbation to compete on how small a program can be made. You're not designing embedded codes or programming a TRS-80 anymore.

Re:Another contributor to productivity invisibilit (1)

Mike Buddha (10734) | more than 4 years ago | (#30538374)

That's usually the case, but sometimes you write a piece of code that is so creative to solve a problem, it's not that someone else is incapable of reading it, rather they can't comprehend the complexity of the code. I've done that a few times.

Even though the piece of code solves the problem it is bad code. Chances are, if someone else can't understand it, you won't be able to understand it in two years when you need to go back and maintain that code. Unless you can comment the heck out of it, incomprehensible code is worthless from a long term standpoint. I have a long standing policy of discarding code that I think is particularly clever, because as a rule, it is almost impossible to maintain. If I have to spend two days figuring out what I did last year that was so "elegant", then it's a failure.

If you come up with a clever piece of programming, either comment it so that a non-programmer can understand it without coaching or toss it and write something more simple. I usually find that once a correct algorithm is discovered that solves a problem, a simply coded, maintainable solution can be written. Memory, storage and processor cycles get cheaper and cheaper every year; there's no need to be stingy with them for the sake of pride.

Re:Another contributor to productivity invisibilit (3, Interesting)

clodney (778910) | more than 4 years ago | (#30538308)

Another factor is that the manager likely recognizes the uber coders, and any piece that is particularly difficult or important gets assigned to the uber coder. So their productivity may appear to be no better than others because the lead has compensated by giving them the pieces that nobody else can be trusted to do.

One guy has great productivity creating a frequency distribution report. It works, looks good, and everyone is happy. It took him a week to do. The uber coder could have batted that out in an afternoon, but instead spent a week ensuring that histogrammer behind the report was multi-core aware and could scale to billions of data points without dragging the system to its knees. The fact that the report programmer would have floundered at that task for weeks is not going to be apparent to most people - even many other people on the team. So the uber-ness of the uber programmer is hidden by the work they are assigned.

Re:Another contributor to productivity invisibilit (1)

Fulcrum of Evil (560260) | more than 4 years ago | (#30538316)

Unfortunately, most people suck...

So they usually blow it.

Re:Another contributor to productivity invisibilit (0)

Anonymous Coward | more than 4 years ago | (#30538104)

Agreed. I notice it around this office as well, we have sections of a project that are horribly managed, horribly coded, and buggy as hell. Yet the coders working on that part of the project are consistently recognized and rewarded because they are putting in SOOO many hours working on stuff, yet those people that just write code that works and doesn't need to be re-written get no recognition.

People do notice (3, Insightful)

Colin Smith (2679) | more than 4 years ago | (#30538170)

As I pointed out previously, incompetent programmers require more servers. Their code spends more time not running, requires a larger support infrastructure to deal with the problems created and generally reduces profits all round.

These days it's difficult to point at a specific individual, but teams are easy. You can see which teams are a group of competent engineers and which are just a clusterfuck[1] of developers.

[1] the collective noun for developers.
 

Re:People do notice (1)

benjamindees (441808) | more than 4 years ago | (#30538444)

incompetent programmers require more servers. Their code... generally reduces profits all round.

Anyone who has only spent time as a developer and has never actually dealt with economics will probably agree with you. But if you spend just a few seconds thinking about it, it's easy to realize how wrong this can be.

If I take a task that was previously done by a secretary making $12/hr, write an inefficient script in some high-level language and put it on a dedicated server that costs $0.20/hr to maintain, I've made 6000% profit.

Am I an incompetent programmer because I don't write in optimized assembly? Probably. Is my code more profitable. You bet your ass.

Re:Another contributor to productivity invisibilit (1)

imp (7585) | more than 4 years ago | (#30538256)

Uber coders also know when to trash old code rather than update it to new standards. The culling of the herd to fit the available resources if often more important than keeping the sickly and poorly written code alive. It optimizes resource use for everybody: the code is smaller, less of it has to be maintained, etc. These skills are often overlooked as well since they are devlishly hard to measure.

This is absolutely critical for small companies to have. Otherwise the code grows faster than their ability to keep it up to date. They need more people doing more work than is necessary. This can push the small company over the edge of profitability (either there are too few people to do the work needed so sales suffer, or there's too few sales to support all the mouths needed to keep this extra code around).

Another trait of uber-coders is they have a global view. This global view often allows then do things much more efficiently because they know exactly the right level to do it. They don't have to do a lot of extra work "just in case" at the wrong layers. Poor programmers do the extra work and justify it as being careful, when they are only being wasteful to the project.

Large companies could benefit from these traits, but the way management is setup makes it difficult to properly measure these skills, reward the teams that practice them and to save the company money (which, in theory should be split between the company and the uber-coders). Sometimes the skills are recognized outside of the normal set of metrics, but often times they are not.

finally, if you think you are an uber-coder, it would be in your best interest to also be an uber-communicator. Not that you have to communicate a lot, but often times the right communications at the right times help more than huge reports that nobody does more than glance at anyway. The best prose for me often times is cut down by 1/2 from my initial drafts and 3/4 rewritten, but everybody is different. The uber-communication skills is what will get you noticed, promoted and have raises go your way. This is especially true if you can make other people more productive by merging the uber-coding and uber-communicating roles.

Re:Another contributor to productivity invisibilit (1)

Locke2005 (849178) | more than 4 years ago | (#30538470)

That's why I've always had the utmost sympathy for sysadmins. If everything is working perfectly, they're invisible. But if something is broken, THEN they get all the attention!

Slashdotted! (1)

alop (67204) | more than 4 years ago | (#30537976)

That was quick

Re:Slashdotted! (1)

tomhudson (43916) | more than 4 years ago | (#30538134)

That's okay - wait until a dupe is posted ... though you won't be able to claim uber coder status, since you won't be able to say "Hmm. I think I've seen something like this before."

Unless you try with "Slashdotted! Hmm. I think I've seen something like this before" FTW.

Negative LOCs (2, Insightful)

arcmay (253138) | more than 4 years ago | (#30537982)

Some of my most "productive" days have resulted in a net deletion of many hundreds of lines of code. Mostly this is cleaning horrendous cut & paste jobs, and refactoring APIs to dump buggy, unnecessary functionality. That one day of effort probably saves weeks of bug-hunting and spaghetti-unwinding further down the road. It would appear to be negatively productive by any naive metric.

I'd argue coder pay should be proportional to productivity. It's just that there's no shortcuts to measuring a coder's productivity.

Re:Negative LOCs (1)

GasparGMSwordsman (753396) | more than 4 years ago | (#30538080)

Some of my most "productive" days have resulted in a net deletion of many hundreds of lines of code. Mostly this is cleaning horrendous cut & paste jobs, and refactoring APIs to dump buggy, unnecessary functionality. That one day of effort probably saves weeks of bug-hunting and spaghetti-unwinding further down the road. It would appear to be negatively productive by any naive metric.

I'd argue coder pay should be proportional to productivity. It's just that there's no shortcuts to measuring a coder's productivity.

On behalf of who ever has to maintain that code after you, THANK YOU.
=P

Re:Negative LOCs (1)

benjamindees (441808) | more than 4 years ago | (#30538252)

Once I had to de-bug an extremely long script written in awk, that parsed invoices destined for a dot-matrix printer, mostly dividing them into pages. The text output was not fixed length and the script was not consistently dividing the invoices into correct pages. The script was over 100 lines. After a couple of days of studying the code, learning awk along the way, determining exactly what it did, and why, I commented it all out and replaced it with a single call to 'lp'.

Re:Negative LOCs (1)

Locke2005 (849178) | more than 4 years ago | (#30538410)

I'm always amazed when I can improve code merely by deleting part of it -- that's a real reflection on just how crappy the original code was! In general, when I'm maintaining badly designed and implemented code, it tends to get smaller, not larger. Some people think it is "finished" when there is nothing else you can think of to add to it. I prefer to think it is finished when there is no way to further simplify it. "Refactoring" is something good coders have been doing for years, before anybody decided to put a label on it.

One particularly bad case: C++ code for Intel's NetPort. Three classes with different names but absolutely the same body, obviously created by cut-and-paste. Anybody that didn't understand he could create a single superclass and subclass the three from that SHOULD NOT be writing C++ code!

If something is hard to measure... (3, Insightful)

judolphin (1158895) | more than 4 years ago | (#30537984)

It's also hard to reward. Also, "Paying a developer by the line is like paying an plumber by the pipe."

Re:If something is hard to measure... (1)

benjamindees (441808) | more than 4 years ago | (#30538286)

But it's really not hard to reward. Just pay by the task. For recurring or ongoing tasks, pay a fixed weekly/monthly rate.

It's only hard to reward if you or your dipshit accountant don't actually understand the first thing about programming and insist on trying to pay by the hour and control every aspect of the process.

Re:If something is hard to measure... (5, Funny)

Ethanol-fueled (1125189) | more than 4 years ago | (#30538380)

I knew a couple folks in my small development shop (~20 people) who were always being rewarded because the informal metric was lines of output. I had to take over for one of the top performers after she left for vacation. Looking through her code, I discovered that the code was merely average, much like mine. I asked another top performer if I could look through his code because I wanted to better understand his interface. His was also mediocre code with roughly the same ratio of lines to output as my code was.

When the other top performer came back from vacation, I took the two of them into the break room and asked them why they are getting undue credit based on the "lines of output metric". They both chuckled and gave each other knowing glances before one of them said, "No, silly, it's how many lines of cocaine we bust out to the boss...see?" The woman pulled out a small bag of whitish powder, a razor blade, and a scratched-up mirror tile. The guy rolled up a 20 dollar bill, tight as a drum, and passed it to me. "Go! Go! Go!", they whispered as I bent down with the tooter in my nostril, snorting 3 medium-sized lines of sweet Columbian. I had felt a strong euphoria like 1,000 cups of coffee overwhelm my body. The guy giggled sheepishly in a high-pitched voice as he went back to work. The woman who was still with me chopped up 3 more gaggers and snorted them up before we fucked madly in the utility closet like wild beasts during the rut. Oh, what a day that was!

Anecdote from folklore.org (5, Insightful)

dysfunct (940221) | more than 4 years ago | (#30537994)

This anecdote [folklore.org] sums it up quite nicely. Now all we need is a few more of those and we have data :P

Re:Anecdote from folklore.org (3, Interesting)

Beardo the Bearded (321478) | more than 4 years ago | (#30538158)

I pulled a codebase down from 10,000 versions to 2.

That's right, the previous system had one different file for each of 10 pulse rates, 255 ID numbers, and a mortality switch.

I got it down to one version for each of the two chips.

I lost that job.

I don't even think it's that well-defined. (5, Interesting)

seebs (15766) | more than 4 years ago | (#30538030)

I have, on rare occasions, been Amazingly Productive. There are very narrowly-defined kinds of work where I am super fast. One of them is debugging. So, when we were doing our "no new features, clear out every P1 and P2 bug in this branch" run, I was awesome -- I regularly fixed many more bugs than anyone else. On the other hand... A lot of the time, I'm not much good. If I have a bad-ADHD week, I can have an entire day go by where I simply never quite get around to doing anything but mostly keeping up on my inbox.

So am I super productive, or not very productive, or what? I don't know. Realistically, the answer is probably "if you give me the sorts of work I'm good at, I'm great, otherwise I'm sorta mediocre." But I'm not sure how you'd measure that.

There's also a much more basic failure-to-apply-economics in the article. The value of something which does 10x as much is not necessarily exactly 10x. Is a monitor with 3x as many pixels worth exactly 3x as much? No. Is a video card which can render exactly 2x as many polygons worth exactly 2x as much? No. On the high end, you might see people paying 2x as much for 20% more polygons. On the low end, you might see people paying 20% more for 5x more polygons. Or there might be other factors; you might care about power consumption, or form factor, or...

I just bought a new Eee. It's SLOWER than the previous one I was using. I paid about the same amount for it, several months later. But it has a higher resolution display, and better battery life... So is it worth the same amount? I have no clue.

Long story short: The marginal value of the "more productive programmer" is not necessarily linear with productivity. Add in other complexities (plays-well-with-others, can do trade shows, reliable about giving feedback on progress) and general market forces, and I don't think it's just a question of measurement; I think it's largely that, in general, programmers are willing to work for comparable amounts of money, and the marginal benefits aren't as large as you might think they would be if you looked only at some measure of productivity. Even if it were a very good measure.

Re:I don't even think it's that well-defined. (1)

MarchHare (82901) | more than 4 years ago | (#30538156)

Hey, are you Peter Seebach? If so, just a few comments above yours, I provided a link
to your insightful (and funny) Hacker FAQ. I've always recognized myself in it.

Have you ever considered reformating it to a more modern HTML document? It's simply
that in its present form, it really DOES look like a text from 1999... it shows
its age. :-)

Re:I don't even think it's that well-defined. (1)

Tekfactory (937086) | more than 4 years ago | (#30538384)

I don't know if you've ever read any of the Flow or finding Flow books, but there is a premise that people work at their best when they have;

A simple well defined problem

Theorhetically then a good Programmer or Dev Lead is one that can narrow his/his team's focus and get working at their best on one issue at a time. Simultaneously they need to have their eye on the big picture and ensure that none of the simple, even elegant solutions still works with all the other parts it needs to. Maybe he does this with good design or good requirements.

Since Lines of Code, or time spent in the office can be gamed and are meaningless as metrics, then how about trying to measure Quality, fitness for purpose, do the customers like it? Can we measure problems/bugs each programmer generates? Can we measure the level of support calls, and customer goodwill lost due to rotten code?

Productivity isn't just getting crappy alpha to crappy beta to crappy shipped on time, or even the mediocre 'we fixed the worst stuff' (that we knew about) before it shipped.

I liked your stuff about the intangibles too.

One Word... (1)

Balial (39889) | more than 4 years ago | (#30538078)

"Defects"

Does the code someone produces work? And actually meet the spec? Or is it always broken and doesn't actually do what it was designed for?

skip (1)

jcombel (1557059) | more than 4 years ago | (#30538086)

common-sense topic
first sentence has no verb
second sentence starts with a conjunction
ctrl f4

Also (5, Interesting)

Maxo-Texas (864189) | more than 4 years ago | (#30538102)

in addition to the factors pointed out by others there is this:

Programmer "A" is an expert and they have a strong opinion that approach "Y" is the best approach- and it is a solid approach.
Programmer "B" is an expert and they have a strong opinion that approach "P" is the best approach- and it is a solid approach.
Programmer "C" is an expert and they have a strong opinion that approach "3" is the best approach- and it is a solid approach.

I've seen A,B, and C get into very loud, very heated arguments over this (I've been programmer A at times when I thought the "solid" approach was missing something that I saw intuitively which they wouldn't accept until I proved it to them laboriously).

Programming is not plumbing. The goal posts are subject to change.

What is efficiency?

Delivering a 100% perfect product 3 months late?
Delivering a 99% perfect product 1 week early?
Delivering a 100% perfect product 3 weeks early but then they change the scope and (as one manager said to me) say "this isn't scope creep". (I turned to my programmer and asked, "can you deliver this change by the previous deadline" and they said "no" and I asked "what date can you deliver it by, and she said 5 days later, and I turned back to the sheepishly smiling manager and said, "is that date acceptable?" -- I mention this because it's a great negotiating technique. And you avoid delivering the product later than the delivered deadline without being an ass and refusing changes).

I've known "great" programmers who were- as long as they were the only one in the company- because they used operating system cheats that worked-- as long as someone else didn't use them too.

A lot of great programmers fail to understand the business side of things.

And you can never control being put on a crappy project with a bad deadline and a bad manager.

---

However, fundamentally- the compensation isn't there because there are too many people willing to do the work. I do not recommend to people who ask me that they enter the IT field in general any more. It's pay is not sufficient to cover the low status, increasing lack of freedom, required holiday work, and offshoring risk.

classic (0)

Anonymous Coward | more than 4 years ago | (#30538138)

Error 500 - Internal server error
An internal server error has occured!
Please try again later. ...staring off into space...I've seen this before...

What about the slow workers (2, Interesting)

PPH (736903) | more than 4 years ago | (#30538146)

And if a bricklayer were 10x more productive than his peers this would be obvious too

And he'd end up getting shoved off the top of a building by the bricklayers that he made look bad.

Many years ago, I had the opportunity to assist on a s/w project to replace a (broken) legacy system. It had been identified by the FAA as not providing proper control over engineering data sufficient to maintain our production certification. And, over the years it had cost the company about $250 million to build and maintain. So we (myself and five other developers) build a new system over the course of about 6 months. It was blessed by the FAA and manufacturing loved it (it actually worked). After it was all done, my team got ....

...laid off.

Aside from actual coding shops, where the s/w IS your company's product, the whole free market capitalist model breaks down. The further you are away from the finished product, the more the corporation resembles a socialist economy, where headcount matters more than productivity. And much, if not most, software is produced in this setting. MS Word may sell millions of copies, but the are more lines of code (or kBytes of executable) developed internally. My boss only had 5 people under him. He was a first level manager. The legacy system employed over 100, making its manager a unit chief over several layers of PHBs. Guess who has the political power in that organization.

Re:What about the slow workers (1)

cryfreedomlove (929828) | more than 4 years ago | (#30538202)

If capitalism is broken, then what should we do as an alternative?

Re:What about the slow workers (5, Interesting)

istartedi (132515) | more than 4 years ago | (#30538302)

The kitten of capitalism is fine. It's just that it grows into a cat.

It's not capitalism you want to get rid of. It's corporatism.

If you've ever dealt with a private bureaucracy, you know that they can be just as bad as government. The problem is more that the organazations don't scale. Also, the tendancy for all these corps to behave in a similar way dulls the effect of competition.

As individuals we don't have much power; but we can start by patronizing small businesses even if it costs more. Think of the added cost as a tax paid to a shaddow government, the true government of the people--the one that fights the big corporations instead of working for them.

No, this is not communism. Communism is dead. It's a 19th century idea born out of the first wave of industrialization. We need 21st century ideas, so forget the tradtional worker vs. capitalist tension, please, Please forget it. Let's not relive that.

Precisely. (4, Insightful)

unity100 (970058) | more than 4 years ago | (#30538184)

When i have a task. i find myself 'procastrinating' for days on end, unable to commit myself directly to writing the code. during the period, the task regularly comes to my mind in sudden, odd places, doing odd things, like in wc taking a dump, trying to go to sleep, going to the grocer's and so on. then, after a few days, i suddenly sit down and swiftly complete the task. it seems like im hatching things, dealing with the thing in subconscious before doing it.

the good side, it works. and good. the bad side, i feel like im procastrinating and being irresponsible during the hatching period and its annoying.

Re:Precisely. (1)

Mike Buddha (10734) | more than 4 years ago | (#30538432)

I have the same exact issue. It feels like I'm not getting anything done for weeks, because the program isn't written and the deadline is looming. I may take a few false starts just to get going doing something, but eventually the best design hits me and I'm off like a bolt of lightning.

I think UML would make it easier to look like I'm doing something when I'm just thinking.

Re:Precisely. (2, Interesting)

chthon (580889) | more than 4 years ago | (#30538446)

I am glad that there are other people who have the same symptoms as I, when it comes to programming. Last week Thursday I just wasted 6 hours doing nothing on my job. Friday it got better and Monday I was back up to speed. But I have the same behaviour on my own hobby projects, yes, it really feels as if you are hatching something.

Re:Precisely. (1, Interesting)

Anonymous Coward | more than 4 years ago | (#30538468)

I find if I force myself to do a task, I can usually muddle through it, even without flashes of inspirations from sitting on the can. (Which while seemingly more productive, does take longer than just knuckling under and doing something I don't really want to do.)

On the other hand, if you just need time to think, I find there's usually enough drudge work to fill a day with mindless tasks that I can still feel productive doing (responding to e-mail, reviewing my bug lists, documenting code, finishing up pet projects), without requiring so much of a commitment that I can't think about what I really want to think about.

Re:Precisely. (1)

sphix42 (144155) | more than 4 years ago | (#30538482)

That 'hatching period' isn't employed by many coders and the result is a product which isn't thought-through. I always take time for a nap and an episode of Futurama whenever I get tasked with a new project. Finding the right solution, using whatever path works best for you, is the primary goal of programming.

Hire a lazy person (1)

Gothmolly (148874) | more than 4 years ago | (#30538196)

As I tell my team all the time - "if you're finding it's hard to do, you're probably doing it wrong." Cargo-cult chimps are a dime a dozen, they beat out code all day long that kind of works and mostly sucks. The good programmer DOES sit there, stare into space, and comes up with a 5-line function to do the same work.

Why can't it be done? (1)

asadodetira (664509) | more than 4 years ago | (#30538200)

To me there a good productivity indicator would be the time needed to achieve a desired functionality. For some applications the quality of the code could be measured in terms of the computational expense of the code (does is take too much time/resouces to run). Something harder to measure would be the maintainability. For this one could follow standardized guidelines to produce a more or less readable code. Still there always will be intangible aspects, such as the team work previously mentioned, or coding with the goal of future interoperability. A good coder will solve a problem fast, create code that makes efficeint use time and memory and is maintainable.

Hmm. I think I've... are you kidding me?????? (2, Informative)

mswhippingboy (754599) | more than 4 years ago | (#30538204)

To me an "uber" programmer is one who does NOT stare quietly into space thinking "I've seen this before", but rather, without pausing to take a breath implements the algorithm as fast as he can type.

It's as if the solution, no matter how complex, is already assembled in his brain and it's just a matter of spitting it out to a file as quickly as his fingers can move. It's not so much the recollection of a some prior scenario, as it is the seamless integration of numerous previously experienced scenarios as well as novel algorithms into a new cohesive algorithm that sets an "uber" programmer apart from the run of the mill code monkey. In my experience, these type of folks are few a far between.

Re:Hmm. I think I've... are you kidding me?????? (2, Interesting)

SomeJoel (1061138) | more than 4 years ago | (#30538400)

And what, pray tell, does your uber-programmer do when he's *not* writing out algorithms "as quickly as his fingers can move"? Or are you suggesting that this tremendous programmer you describe has a near infinite workload where he's constantly typing out new and revised algorithms?

Lost me at the first sentence (2, Insightful)

PHPNerd (1039992) | more than 4 years ago | (#30538206)

The most productive programmers are orders of magnitude more productive than average programmers.

There, fixed that for you.

Great Article! (0, Troll)

SparafucileMan (544171) | more than 4 years ago | (#30538210)

Oh, wait, it wasn't an article. It was a 2 paragraph blog post that someone crapped out with some random anecdote and zero facts, figures, or research.

I don't know why /. still surprises me with this.

It's easier to measure it by tasks accomplished (1)

zullnero (833754) | more than 4 years ago | (#30538214)

Rather than lines of code. I figured that had been well understood by most people these days.

It's a big part of the reason Agile has caught on so much...theoretically, all one has to do is measure the effectiveness of a developer in dealing with high priority or tasks assessed as complex, rather than how much code is being produced. The only gotcha is that you have to avoid the trap of rewarding developers who do lots and lots of simple tasks over developers who take on the complex tasks, but that stuff usually hashes itself out during the scrum planning. In a waterfall system, you're kind of stuck evaluating developers by how much "stuff" they produce (documentation, code, tests, etc.) instead of quality because you don't keep track of the individual tasks like you would in Agile.

oh but they are (1)

maxwells daemon (105725) | more than 4 years ago | (#30538232)

I have never seen a bad programmer make more money than a good programmer in the long run. Unless of course the bad programmer goes into management.

Extrinsic versus intrinsic motivation (1)

toppavak (943659) | more than 4 years ago | (#30538258)

Its been well known [ted.com] for a while that financial motivation for creative work does not result in increased productivity or quality of work. Trying to incentivize coders to be more productive is often counterproductive since they'll be motivated to just hammer out something that works rather than spending a few moments actually thinking about the problem and coming up with an efficient solution that will be better for the codebase in the long run. Trying to reward individual coders based on some arbitrary measure of productivity will never properly reward the right coder nor produce the highest quality of code possible. Using subjective judgement by technical peers rather than objective measures cooked up by HR, providing comfortable and respectful working conditions and encouraging the exploration of the intellectual and creative sides of coding are probably some of the best steps one can take to help good coders produce great code. If you provide the right environment, you have a good chance of attracting a lot of great talent even if you don't offer the best pay in the market because having a job where you're intellectually challenged and your expertise is valued (and listened to!) can be worth a lot more to a good programmer than an extra few grand a year.

A good reason pay SHOULDN'T be proportional... (1)

Beorytis (1014777) | more than 4 years ago | (#30538270)

If you haven't seen this TED.com video with Dan Pink on the science of motivation, it's worth a watch: http://www.ted.com/talks/dan_pink_on_motivation.html [ted.com] In case you don't want to watch TFV, it could be summarized as: "Using compensation to motivate tasks requiring higher cognition doesn't work. Behavioral science has understood this for decades, but business isn't listening."

Re:A good reason pay SHOULDN'T be proportional... (1)

Dunbal (464142) | more than 4 years ago | (#30538412)

Behavioral science has understood this for decades, but business isn't listening.

      That's because strategic decisions are usually made higher up the corporate ladder. However your place ON the corporate ladder is determined by how good you are at office politics - NOT cognitive ability. This is why in mature corporations you usually end up with a clueless senior management who all got the job because they're buddy buddy with whats-her-name, dictating insane directives and getting in the way of the actual work being done, to the detriment of the company.

How do you measure bricklayer productivity? (1)

line-bundle (235965) | more than 4 years ago | (#30538278)

What does it mean for a bricklayer to be 10x productive? How many bricks they lay per hour? Are they straight etc etc ....

The main problem is that there is no good/easy metric to measure productivity (except perhaps for salesmen)

I'm not "doing nothing", I'm thinking (4, Interesting)

handy_vandal (606174) | more than 4 years ago | (#30538312)

My dad was a programmer for the Star Tribune, back in the seventies and eighties.

Two things he said stick in my mind.

1. He had his own office, and sometimes he'd put up his feet and stare off into space. He told me that people passing by his office assumed that he was "doing nothing." But, he told me, he wasn't doing "nothing", he was very much doing something: thinking.

2. When he got, say, a directive from On High that he must "write a new program for the secretaries", the first thing he did was go and sit down with the secretaries, ask them about their work, and stick around for a while to actually watch them work. He called this the "going native" phase (he took his degree in anthropology). If he'd started coding on the basis of the directive from On High, the end result would be something the secretaries didn't need and wouldn't use.

Hmm... (1)

Locke2005 (849178) | more than 4 years ago | (#30538326)

'Hmm. I think I've seen something like this before.'" I say that a lot when sitting in front of my computer... usually when there is pr0n displayed on the screen!

You're all on the wrong track entirely (0)

Anonymous Coward | more than 4 years ago | (#30538336)

As with any pricing that hasn't been interfered with or regulated in some way, the reason that programmer A, who is 10x as productive as programmer B, does not earn 10x as much is that it doesn't take 10x as much to get him to work. In other words, it has nothing to do with relative value. Most of the comments here are about the perception of productivity and the lack of or need for hard numbers. But they won't change anything. Pricing is, as always, determined by supply and demand. Enormous demand would be required to push a great programmer's salary to 10x what it is today.

As proof that it's not about perception or measurement, consider a sales position. Does a salesperson who is 10x as effective as average make 10x the salary? Nope. They might make 2-3x the salary of their less effective counterparts in the same position, but that's it. Employees don't get paid in direct proportion to their value, because all businesses everywhere want to retain a lot of that value for themselves. This means that company B isn't hiring the uber-salesman away, not if it takes a massive salary. Demand of that magnitude just doesn't arise.

Re:You're all on the wrong track entirely (1)

Fareq (688769) | more than 4 years ago | (#30538436)

[In general] Management's inability to determine which programmers are 10x more productive leads them to be unable to demand those most-productive workers.

If management were able to realize that some programmers were 10x more productive, and were also able to figure out which ones were that 10x more productive, in many cases management would begin to insist upon hiring only those which were at the top end of the spectrum. The tendency for some organizations to actively seek this and other organizations to not seek it would tend to separate the industry, moving a larger fraction of those top-tier programmers to places where they are valued higher, and leaving the companies that don't apparently care one way or the other with fewer top-tier programmers.

This in itself would make the disparity more obvious, since those shops that sought top-tier talent would be drastically more productive now that there were relatively few top-tier programmers to "bail out" the shops that weren't picky.

You probably still wouldn't see 10x, but it would start to spread more than it is now.

Myself, I won't hire anybody that I don't think is in the top-tier category. I won't (and currently don't have to) pay 10x as much. But since I could snag top talent for only about 10-20% more, I'm all over it -- when I can identify it.

Quotas in code are as stupid as in factories! (2, Insightful)

SexyKellyOsbourne (606860) | more than 4 years ago | (#30538364)

Programmers cannot be measured by any simple metric -- this is true. It's been debated ad nauseam for years.

Still, I don't see why the hell people are trying. Quotas and flat numbers measuring simply by "production" are always stupid things in the long run, just as they were in factories.

In software, they'll cause the same problems that they did at brick and mortar factories before TQM principles were established -- people fearing the data and fudging it in desperation. If this is counted by, say, lines of code produced, you had better believe it will be written in the strangest manner possible in spite of defects. But with any quota/by objective system in place, no teamwork will take place -- they'll all be concerned about their own numbers or even hurting others. No one will experiment or come up with ideas and find any process improvements.

And the person who actually does a good job in realstic terms may not compare to someone who skewed the numbers objectively to feed their kids. This will not give them any pride in their workmanship and will be a serious demotivator, if not burning them out entirely from cynicism about their profession.

What's the alternative? Judge the programmers based on quality. Have the team define what quality code is, both what's good and what's bad, and attempt to try to find ways to measure that. All of that's going to be in the eye of the beholder and specific to an organization, as not all programming projects are the same. This is all part of greater total quality management principles, but...

Sounds like the old joke ... (0, Offtopic)

ubrgeek (679399) | more than 4 years ago | (#30538386)

> "A salesman who sells 10x as much as his peers will be noticed, and compensated accordingly. And if a bricklayer were 10x more productive than his peers this would be obvious too."

But if you sleep with just _one_ sheep ...

Value, labor and the fallacy of mixing the two (2, Interesting)

steve buttgereit (644315) | more than 4 years ago | (#30538394)

The Austrian School of Economics in determining the value of products actually discounts the idea that the value of the end product is somehow connected to the labor expended in producing the product. There are many examples of this in tangible products... for example in the art market, a painter, prior to earning fame may not be able to sell a painting at all or only for a few dollars; after the painter earns fame (and is probably dead) that same painting worth a few dollars many now be worth tens of thousands of dollars. The labor that went into the product didn't change... it's still the same product. But the value of that product to society increased through unmeasurable and intangible factors.

The same amount of code and development time may have gone into a $20 dollar shareware game and a $500 dollar business app. Assuming both sell equal copies, which has more value? Which was the more 'productive'? By looking at lines of code and development time alone their value should be equal, but that's not the case. True the idea behind each of those apps contributed to the overall value differently, but even then the ideas may have taken the same 'labor' to develop while producing uneven value.

I've managed development teams myself. Over time I've learned how long certain types of feature take to develop and how well they should work in that given period of time... sort of a baseline. If a develop provides the product in less than that time with the same quality that developer is clearly more productive than a developer that fails to meet that baseline. This could be formalized to a degree, but would still maintain subjective standards of quality and estimates of effort. I agree with the premise of the posting however... you cannot judge productivity on scientifically measured quantities like lines of code or number of bugs; coding is too creative an endeavor for that and it starts to look like judging value in the way the Austrians rejected long ago.

Measurement metrics (2, Interesting)

arjan_t (1655161) | more than 4 years ago | (#30538404)

This is indeed somewhat of a problem in our profession. It's in general hard to find good metrics that quantify the performance of a programmer. Lines of code, number of closed tickets, or years of experience are all sometimes used but even though these might be indicative of performance, they all don't necessarily have to mean much.

Lines of code has been discussed quite often over the years, but it's typically not seen as a good indicator. People may use a lot of white space, or write a bunch a spaghetti code based on blindly copy-pasting stuff around. This blind copy pasting will result in extremely bad code that's often impossible to maintain. A better performing developer may actually refactor all this duplicate code and abstract it into some common class or method, in which case the LOC produced by said developer may actually be negative! Worse yet, people may check in stuff like .dia files to their source code repository, which might boost your supposed LOC productivity with thousands of lines, while all you did was draw a box with an arrow pointing to it.

On the other hand, LOC also doesn't mean nothing. I've seen developers reading slashdot all day instead of coding and as a result their daily, monthly and even yearly LOC count was extremely low. We use among others statsvn http://www.statsvn.org/ [statsvn.org] and though not perfect it does give a very crude indication of who's very active and who's basically doing nothing all day long.

Number of closed tickets is an indicator too, but just as with lines of code hard to really use for measuring some one's performance. Tickets (issues/bugs) can vary wildly in complexity and the "estimated amount of hours" and "impact" is hardly ever accurate. Given two bugs, one can be as simple as adding a forgotten quote somewhere, while the other can amount to weeks of digging through the lowest levels of some code base. Yet, on average, if tickets are assigned to developers without really taking into account their abilities, then over a longer period of time all developers should on average get an equal amount of quick&easy and hard tickets. In that case, the number of closed tickets might be indicative again. Someone who barely ever closes a ticket might not be that top performer, despite the inaccuracy of the ticket measurement.

Years of experience, which is I think used the most, is maybe also the most debatable of them all. It's a very natural measurement tool which takes no personal stuff into account. It's a very basic and easy to measure number. But here too, it can be deceiving. I've seen programmers who had some 8 years of Java experience, but appeared to be totally unable to pass a basic Java test and produced nothing but WTFs in their code like concatenating strings to each other with commas in between instead of storing them into a list, simply because they didn't grasp how a simple list actually worked! (I kid you not, I actually encountered this). In contrast with this, there's the guy (or gal) taking up some part-time job while still studying, who understands even complex stuff in the blink of an eye and produce nothing but exemplary code. But here too, given a group of all reasonable knowledgeable programmers, the ones with the most experience typically win out. When I look at my own code that I produced 10 years ago and compare it with what I produce now, I most definitely see a vast improvement.

Even though management might often have difficulties with measuring the performance of a programmer, there is one group of people who are true experts here: the team mates of said programmer; his or her fellow programmers! If you have worked in a team for some time, everybody knows who's the ace, who's the simply capable one and who is obviously trailing behind. As a programmer you actually work with the code of that other programmer. You are either able to extend that code with the greatest ease because of the elegant design and clear names being used, or you curse every minute that you have to spent in that code. As a programmer, you actually know whether the answer you get from that other programmer actually makes sense. If he or she answers your every question with a "yeah, well, uhm, it's not supposed to do that, but sometimes it happens anyway. I have no idea why, must be a strange VM error", they you simply *know* that person is subpar. On the other hand, if you almost always get an answer detailing you the exact location of some occurrence and a short but concise explanation under which condition something happens and why, you *know* this person is ace ;)

Coders save employers' butts 10 time more often (1)

WebManWalking (1225366) | more than 4 years ago | (#30538420)

That's how to get noticed.

Even more effective... (1)

TheMiller (520200) | more than 4 years ago | (#30538424)

Even more effective than the programmer that avoids writing code by writing efficient code is the programmer that writes code which allows his coworkers to write less code. If you've got someone who's good at this sort of thing, the best use for them is to write the tools that improve everyone's efficiency.

Best vs worst disparity even higher (1)

cruff (171569) | more than 4 years ago | (#30538426)

But the best programmers do not write 10x as many lines of code

I beg to differ, since the worst programmers manage to avoid work by dumping it off on someone else when they are in a position to do so, the best programmers write much more than 10x the lines of code than the worst ones.

The 90/10 Rule (2, Interesting)

manlygeek (958223) | more than 4 years ago | (#30538448)

Thank you John D. Cook!! I think you hit that right on the head. Writing a lot of sloppy code (or insanely terse code for that matter) is MUCH worse in the long run then thinking about it a bit and writing good solid, well documented (i.e. Self documenting) code. One of my first big coding jobs was for the best boss I've ever had. He was not an ubergeek. In fact, he was an Agriculture major from Texas A&M. He had the idea that code productivity was like building widgets; x widgets will be built in y days at the rate of x/y. Now I educated him a little bit and told him in advance that it would take me 90% of my time to build the engine that the rest of the code would use and then in the remaining 10% of my time, the rest of the functionality would be done. Though he didn't know me too well, a fellow programmer whom he did know (and who wrote code by the bucket load) convinced him to let me try it my way. Everyday he would come in and ask for a "percentage done". I would tell him what I had worked on but also reminded him that it wouldn't look like much progress. To make a long story short, he just about lost it waiting for me to get the 10% done as I had said would get done in the first 90% of the time I had to do it. But I delivered just as I said and built a most useful product for him. I went from "10%" done (in terms of functionality and lines of code) to complete in one week (this was a several month project). Because of the way I had built my engine, I was also able to accommodate several additional feature requests that I received when I was working on the first 10%, and which would not have been able to be built at all if I had done it his way. I never had trouble with him trusting me after that and I didn't let him down. Of course this was many years ago and probably wouldn't work with today's Agile methods too well. But the point carries that automation is basically a front loaded investment and there is a balance between risk mitigation and long term viability. Version 1.0 might take me longer to engineer but by the time we've gotten to 2.0 I've caught up with you and by 3.0 you can't even see my dust trail. Its a luxury I don't always get (at least not up front) but I work pretty hard to educate my management and there's nothing quite as convincing as success... that is if both you and your boss can survive the onslaught of "Get It Done Now".

Economics!!!! (0)

Anonymous Coward | more than 4 years ago | (#30538450)

UH...becuase the salary depends on supply and demand! DUH!

Programming and Art (1, Interesting)

Anonymous Coward | more than 4 years ago | (#30538452)

A couple of observations.... An Artist expects a royalty because they have, well, produced art. And art can be enjoyed over and over, replicated in many ways, and serve as the starting point or context for additional works of art.

The same thing can be said about programming. Even more so, because a great sort, or a great compiler, or a great debugger, gives and gives, and produces work that can be leveraged over and over in new contexts.

This leads me to a personal story. Once upon a time, I wrote a great rules engine for the State of Texas. The use of this rules engine turned around a portion of the project that was at the time 6 months late at the time I joined. The group I joined was slated to have the most programmers of any of the various portions of the project. In two months, using my approach and technology, they caught up all of the 6 months of lost ground, were never behind schedule again (except when other teams failed to deliver), and was the smallest group of the seven teams.

I built a tool that allowed nearly anyone to step into anyone else's section of the policies we were implementing, and debug and fix the rules. Was it perfect? No, but I had great plans.

So about a year into the effort, I went to management and suggested a list of productivity improvements we could make.

And they gave me my walking papers.

You see, what I had built had no bugs. It allowed nearly any developer to step into any role and be productive. They began moving as much of the system into the Rules because the Rules Engine made big problems simply go away.

I was an amazingly productive programmer, because I coded my entire job away.

Now after having written four versions of the Rules Engine (because I kept doing it for other projects and other companies) and having coded myself out of a job 3 times, I finally did the last version as an open source project. And because I used it in my current job on a project, with a number of those improvements alluded to earlier, on the second project on my current job, they didn't even need me. A fresh out of college business analyst made all the changes from the rules on the first project for the second project. I only had to give a bit of tutoring, and some nudges here and there at the beginning.

And at the current job, I again am getting some feeling that the software development group is grumbling about my productivity. They don't care about the Rules Engine, because they have it. They don't care about the improvements, because they have them. Any additional work I do to the Rules Engine I do on my own time, and I find myself increasingly refactoring code, adding database tables, and fixing various Java bugs.

I fear I have again coded myself out of the most interesting parts of my job.

At least if this job dries up, I won't have to rewrite everything a fifth time.

Hello. (0)

Anonymous Coward | more than 4 years ago | (#30538464)

Alright gentlemen, I'm in a bit of a bind. You see, I had some time here in my cubicle where my boss and co-workers were out to lunch. After already eaten a huge burrito I felt the need to "break wind." Figuring that it'd be courteous to do so along I let her rip. Well, now my co-workers and boss are back in the office. And now I think I might have accidentally shat myself.

I'm pretty sure I feel the warm stream of feces running down my leg as I'm now typing this. So what am I to do? I'm pretty positive that my co-workers can smell what's going on, judging by the stench. The bathroom is way down the hall past my boss' office. If he stops me while I'm walking by I fear that he will immediately know what's going on as well. Heck, even if I make it to the bathroom I don't have a change of clothes and my pants are practically stained all the way through...

and! (1)

hypergreatthing (254983) | more than 4 years ago | (#30538466)

reads websites all day long like slashdot to broaden their horizons while thinking of how to do things better! Exactly!

Now how do i get a raise for doing that?

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?
or Connect with...

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>