Forgot your password?
typodupeerror
Businesses Programming The Almighty Buck

Why Coder Pay Isn't Proportional To Productivity 597

Posted by timothy
from the productivity-is-a-blunt-edged-word dept.
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.'"
This discussion has been archived. No new comments can be posted.

Why Coder Pay Isn't Proportional To Productivity

Comments Filter:
  • by MarchHare (82901) on Wednesday December 23, 2009 @03:34PM (#30537964)

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

  • by seebs (15766) on Wednesday December 23, 2009 @03:40PM (#30538030) Homepage

    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.

  • by rolfwind (528248) on Wednesday December 23, 2009 @03:42PM (#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.

  • by seebs (15766) on Wednesday December 23, 2009 @03:45PM (#30538092) Homepage

    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.

  • Also (Score:5, Interesting)

    by Maxo-Texas (864189) on Wednesday December 23, 2009 @03:46PM (#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.

  • by PPH (736903) on Wednesday December 23, 2009 @03:50PM (#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.

  • by Beardo the Bearded (321478) on Wednesday December 23, 2009 @03:50PM (#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.

  • by istartedi (132515) on Wednesday December 23, 2009 @04:07PM (#30538302) Journal

    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.

  • by clodney (778910) on Wednesday December 23, 2009 @04:07PM (#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.

  • by handy_vandal (606174) on Wednesday December 23, 2009 @04:07PM (#30538312) Homepage Journal

    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.

  • by Anonymous Coward on Wednesday December 23, 2009 @04:13PM (#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.

  • by steve buttgereit (644315) on Wednesday December 23, 2009 @04:15PM (#30538394) Homepage

    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.

  • by SomeJoel (1061138) on Wednesday December 23, 2009 @04:16PM (#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?
  • Measurement metrics (Score:2, Interesting)

    by arjan_t (1655161) on Wednesday December 23, 2009 @04:16PM (#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 minu

  • Re:Precisely. (Score:3, Interesting)

    by chthon (580889) on Wednesday December 23, 2009 @04:20PM (#30538446) Homepage Journal

    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.

  • The 90/10 Rule (Score:2, Interesting)

    by manlygeek (958223) on Wednesday December 23, 2009 @04:20PM (#30538448) Homepage
    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".
  • Programming and Art (Score:1, Interesting)

    by Anonymous Coward on Wednesday December 23, 2009 @04:21PM (#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.

  • Re:Precisely. (Score:1, Interesting)

    by Anonymous Coward on Wednesday December 23, 2009 @04:23PM (#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.

  • But it is... (Score:3, Interesting)

    by tjstork (137384) <todd.bandrowsky@NOSpAM.gmail.com> on Wednesday December 23, 2009 @04:27PM (#30538504) Homepage Journal

    Just to throw some names out there:

    Steve Wozniak - Apple I, II - (uber king because he did hardware and software)
    Bill Gates / Paul Allen - original MS Basic
    Charles Simonyi - Word, Excel, Multiplan
    Ellison,Miner,Oats - Oracle
    Mitch Kapor - Lotus 123
    Ray Ozzie / David Woolley - Lotus Notes
    John Carmack / Michael Abrash - Doom, Quake
    Linus Torvalds - Linux
    Mark Andreseen - Netscape

    Most of those people on the above list were just programmers starting out without really all that much but a computer and an idea. Most of them went on to be billionaires. Below them are another tier of thousands of unnameable programmers that are millionaires, and below them are millions who form the back bone of their departments.

    It's pretty much, you get paid great not to just code, but more importantly, to have great ideas and code them.

  • by Anonymous Coward on Wednesday December 23, 2009 @04:29PM (#30538516)

    I have always liked this quote.

    "Measuring programming progress by lines of code is like measuring aircraft building progress by weight" -- Bill Gates

    The problem is design progress of almost anything is very difficult to measure, and when multiple people work on the same project it makes it almost impossible to sort out who did what. Sales does not have that problem because progress is not measured, however results can be measured before the paycheck is cut, and everyone is responsable for themself only. Design works differently, the end results are not immediately available, often you work in groups so your work can not be seperated from others. And you can't predict how far you are because you are always expecting unexpected hurdles and that is where you will spend your time. Trying to set a target will fail as well because almost nothing can be numerically measured to compute progress, for example starting over is some progress (you learned from your mistakes) yet it is not something that is really going to be useful either way to determine progress.

  • by EWillieL (15339) on Wednesday December 23, 2009 @04:40PM (#30538596)

    Mmm-hmm.

    I've had to clean up after one of those guys. He'd crank out the first cut of a codebase, and I'd go through and factor out the instant cruft his stream of consciousness had spewed out. We actually made a pretty good team.

    He was (still is) brilliant, but his codebase would quickly degenerate into an inmaintainable plate of spaghetti without someone like me, and he knew it. He told me as much.

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

    As much as programmers often hate them, this is where good management comes in.
    A manager who knows when to apply you to the project and where to put you on a team is going to get the most out of your abilities and you will both benefit.

    Unfortunately, good managers are about as hard to find as good programmers :-)

  • by rolfwind (528248) on Wednesday December 23, 2009 @05:06PM (#30538866)

    Where is "around here"? France? Germany? Elsewhere?

    Companies in my part of the States make it a point of pride to drive you to make work your life, for managers who work 50 hrs a week make their staff feel guilty if they work 80 hrs near crunchtime, the 40 hr workweek is an illusion even in the beginning of a project. And vacation? Heh. 10 days maybe?

    American workers aren't that much more productive than Europe and I see why. Just the typical failed 'more pain more gain' mentality.

  • Re:Precisely. (Score:3, Interesting)

    by shutdown -p now (807394) on Wednesday December 23, 2009 @05:19PM (#30538984) Journal

    I have seen this described a lot by many other programmers, and often experience it myself, so I'm inclined to assume that it is, in fact, the basic nature of our work.

  • by shutdown -p now (807394) on Wednesday December 23, 2009 @05:30PM (#30539094) Journal

    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.

    There's also a third category, my favorite: weeks of digging through the lowest levels of some (old, undocumented, messy) codebase, which is ultimately followed by a fix that adds a forgotten quote. How do you even quantify that kind of thing?

  • Small tight code (Score:4, Interesting)

    by EmperorOfCanada (1332175) on Wednesday December 23, 2009 @05:45PM (#30539210)
    The best coders I have seen wrote amazingly little code. I am not talking about crazy pointer arithmetic but just way less code than lesser programmers. Often the best programmers also deployed the available resources way better. When all is said and done the best programmers leave code that everyone worships as pure genius that everyone else builds on with ease. A great example was someone who did some great code where they took the bull buy the horns and moved the project into proper multithreading and some crazy memory usage. The server went from using maybe 10Megs per process to a collective 8Gigs spread across many threads. Sounds complex but every programmer took one look at the code and went wow. 20 servers out of 23 previously heavily loaded servers were shut down as unneeded. Even with 50% client growth every year our next server purchase will probably be in a decade. That super programmer moved on and we just kept building on his code for a long time. Programming and debugging went from a chore to a joy. Anyone could tell which code was new code because it was ugly and complex compared to the simple elegance of the original code. Without a doubt that programmer could replace the 50 pretty good programmers we have on staff now. Plus his code eliminated 3 full time system admins and has resulted in zero downtime in two years, thus avoiding millions in losses over the last and next few years. So what should his pay have been? 5 Million a year? On a different topic, in my travels I have seen sys admins who ran well oiled machines that were amazing. At the same time I have seen sys admins who weren't properly backing up critical data. Critical as in the company would go bust in the event of a HD failure. In these same companies they had HR, CFO's, and Sales people who were paid multiples of the Admin. These "senior" managem who's screwups would be hard pressed to completely wreck the company usually saw the various computer people as a bit of a joke.
  • by sartin (238198) <sartin@ac[ ]rg ['m.o' in gap]> on Wednesday December 23, 2009 @05:47PM (#30539232) Homepage

    Heck forget memory limits, those were easy (he said, using his tongue to push his dentures back onto the roof of his mouth while tugging his pants up over his belly button), one time my lab partner and I re-coded our elevator simulator (written in machine code, not assembler, you wimps!) so that we could enter it with a hexadecimal keypad that was broken so the "E" key debounce didn't work. For you whippersnappers who never entered machine code with a keypad (not keyboard!) or switches, that means we rewrote it so that no machine instruction (one byte instructions) or data byte had "1110" as the lowest four bits. No that was programming.

    Cyril, my lab partner, wound up being Bob Moog's protege and has become the key designer at Moog. Wonder if he remembers that afternoon in EE lab.

    Then there was Bob in high school, who reconfigured RSTS control blocks through the front panel switches on the PDP-11/40 to enable root-like privileges. Now, that was art: several levels of indirection, the machine needed to be halted to use the panel, but it was a timeshare system and you had to get it running before any of the users noticed. Pure art, until that one time he made a mistake and caused a crash that rewrote the master file directory with all zeroes. That was a long night writing, testing, and running a program in BASIC that used heuristics to read the disks and a three month old backup (for getting user IDs and old passwords) to recover the directories on the disk. When the security guard came in at 3 AM, Chris (the friend helping me fix Bob's mistake) had to talk the security guard into not waking up the Dean of Students to report us. Bob got kicked off the admin staff for a while. Things got boring after that.

    Now, back to my afternoon nap.

  • by sartin (238198) <sartin@ac[ ]rg ['m.o' in gap]> on Wednesday December 23, 2009 @06:07PM (#30539402) Homepage
    Oh, I don't know about most programmers being good enough to invent data structures. In the 1980s, my friend Karen was credited by her co-workers at Sperry as the inventor of doubly linked lists. She encountered a situation that obviously needed them and got rid of a bunch of old, inefficient code. Exactly none of her co-workers had seen them before, nor had they thought of using something like that to fix the performance problems they were encountering due to poor data structure choice.
  • by jc42 (318812) on Wednesday December 23, 2009 @06:17PM (#30539456) Homepage Journal

    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.

    Actually, this is the way that "creative" professions have generally worked. Consider the typical sculptor or painter. Even those that reached a level of fame have usually been paid only once for each creation. It is then owned by the client, who can resell it and not give the creator any part of the sale. There are a few countries that have dabbled with royalties for resale, but this is rare, and the royalties are typically small. The real profit from art goes to the sponsors and investors.

    Authors and musicians have had some small success in getting royalties for their work. But this is most often "honored in the breach". It's well known that recording artists don't get any royalties at all, and may lose money, unless the recording sells around 1.5 to 2 million copies. Before that, all the income goes to the owner of the recording, which is the corporation that produced and marketed it. Even after a recording reaches the profitable stage, the artist typically gets only a few percent of each sale. The situation is similar with authors, who may be paid a small "advance" before production, but rarely makes a profit until several million copies have been sold. Most writers have worked for corporations such as newspapers or other periodicals, who pay a salary and claim all income from sales.

    The movie industry has a few showcase stars who have made a small fortune in royalties. But most actors are "starving artists" who have to work at part-time jobs to get rent and food money. Movies are owned by the producers, not the actors. The few stars are held out as bait to attract the many workers who will never be stars and will never make a decent living from their creativity.

    Software programmers like to think that they're something new that the world has never seen. But in reality they are merely creators in a new medium, and they are treated as the commercial world has always treated creative types. They're workers who can be paid a small salary to produce, and when they produce something that sells, the corporation can claim the profits. A few stars can be paid some royalties (still only a few percent of sales) and held up as public examples to attract the many workers that the industry needs.

    Don't expect to see this change in your lifetime.

  • by arjan_t (1655161) on Wednesday December 23, 2009 @06:18PM (#30539472)

    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.

    There's also a third category, my favorite: weeks of digging through the lowest levels of some (old, undocumented, messy) codebase, which is ultimately followed by a fix that adds a forgotten quote. How do you even quantify that kind of thing?

    That's a good question. It's actually not an uncommon situation at all. Some years back we discovered that posting a page to a Tomcat based server would sometimes just disappear. We spent day and night researching this, had discussions via mail with some Tomcat developers, set up probes and loggers just about everywhere, even spent a lot of time reading huge amounts of Tomcat's source code looking for a possible clue, when eventually we found the culprit: an overambitious system administrator had changed some timeout value in the AJP connector between Apache and Tomcat to an extremely low value. It was a sheer miracle that there even were requests at all that made it through. The ultimate fix that had costed several weeks worth of time, a couple of emergency meetings, starts of drafting migration plans to just about anything else that possibly wouldn't have this problem, consisted of adding I believe no more than three zeroes to this particular timeout value...

  • by jc42 (318812) on Wednesday December 23, 2009 @06:39PM (#30539666) Homepage Journal

    Somehow I think that Bill may have had a slight "edge" over other applicants for the chief software architect position.

    This is made clearer if you investigate his full name, William Henry Gates III. His father, William Henry Gates II, was a fairly successful businessman who had the money to send him to Harvard, where he made the contacts needed to start a business with inside access into IMB's management level. Yes, he was a geeky kid who got into the new small-computer stuff, and he even learned a bit of programming. But his real background was business management, and he was born with the proverbial silver spoon in his mouth. He cultivated the computer-geek image, while developing his insider-to-upper-management-levels reality.

    Of course, lots of people in the computer biz know all this. But it's surprising how many in both the computer industry and the MSM have fallen for the computer-geek-who-made-it-big public image.

    (I've also seen the claim that his given name actually is "Bill", not "William", but I've never seen verification of this. Not that it matters much. It's not too unusual in American society to have nicknames as given names on birth certificates.)

  • by mwvdlee (775178) on Wednesday December 23, 2009 @06:55PM (#30539782) Homepage

    Hence, the code of a good coder looks as if any beginner could have made it whereas the code of a bad coder appears as if the results of a sophisticated mind.

    To put it in another way; any idiot can make something simple look difficult but it takes a genius to make it look easy.

  • by JWSmythe (446288) <jwsmytheNO@SPAMjwsmythe.com> on Wednesday December 23, 2009 @07:14PM (#30539962) Homepage Journal

        This release finish is usually enough for most companies. They can thin the herd of most of their developers, keep just a very few on, and when it's time to start on the next release, hire on fresh meat for a fraction of the cost of the last crew.

        There used to be company loyalty. That's long since gone. Back in the day, if you had a job and were good at it, you would continue the job for the rest of your life, get yearly raises and promotions. Now, once they can terminate you and bring on someone cheaper, they will.

        How many people have you worked with for more than 10 years? If you've had the same job for that long, I'd be willing to bet the number could be counted on one hand. My record is 8 years. I could tell you everyone who had come and gone. There was some loyalty there, but they shifted their view and started looking at the cost over loyalty. "Oh, we can get rid of this senior guy with 8 years experience with us, for someone who doesn't know us at all, and pay less than half as much." Unfortunately, I had settled myself into being there as my long term career.

  • by geekoid (135745) <dadinportland @ y a hoo.com> on Wednesday December 23, 2009 @07:14PM (#30539968) Homepage Journal

    I would rather a few fat cats made off better then they should have then the entire economic system collapse.

    Took me a long time to realize that, but in the end that's the conclusion I came to.

  • by geekoid (135745) <dadinportland @ y a hoo.com> on Wednesday December 23, 2009 @08:58PM (#30540766) Homepage Journal

    "If you've ever dealt with a private bureaucracy, you know that they can be just as bad as government. "

    actually, there usually far worse. Government bureaucracy can be figured out and has consistent rules withing that specific framework. And you can go over the head of the bureaucrat to your elected officials.

  • Re:Here we go again (Score:5, Interesting)

    by clockwise_music (594832) on Wednesday December 23, 2009 @10:57PM (#30541368) Homepage Journal
    He also wrote an article about how Exceptions are pointless and a waste of time,
    and that we should track "ErrorNumbers" ourselves manually.

    He completely ignored the fact that exceptions were developed to solve
    the problem of "working out in the stack where the error happened", and when
    people pointed that out how ridiculous his solution was he refused to change
    his mind. So screw it.
  • by SnapShot (171582) on Wednesday December 23, 2009 @11:45PM (#30541568)

    ... they designed the system, got the experience and then left to either set up their own company, to go abroad or become a contractor, and leave the bug fixing to someone else.

    There used to be a solution for that back in the 90's. It was called equity ownership. If you tell a programmer, "build this app" he'll build the app. If you tell a programmer, "help build this company" then there's a good chance he'll help build the company.

  • Food for thought (Score:1, Interesting)

    by Anonymous Coward on Thursday December 24, 2009 @02:08AM (#30542120)
    I was Principal Engineer at a major software company for 18 years, and my productivity was considered to be superior to almost all the rest of the staff. I got lots of incentive stock options because of my performance. Fortunately I was paid better than most of the staff as well, though I did not survive a large layoff at the end of 2005. To position the company for sale, recently hired "pointy-hair" management decided to off-shore most software development and I was let go because of my "cost". Suckage, given that I was a principal architect of the company's flagship product (which contributed about $90M USD / year in sales), and was the principal and lead developer of the distributed transaction processing framework that was the heart of all the company's leading edge products. I was published in academic books and journals, made major presentations at IEEE and ACM computing conferences, and was considered one of the "leading lights" of real-time transaction processing systems. In the end, productivity, innovation, quality means squat. The more you cost, the more likely you are to be let go when the economy is tight. Good pay counts, but make sure to keep your marketable skills up-to-date, even if you have to do it on your own dime and time.

PLUG IT IN!!!

Working...