Slashdot Mirror
Why Coder Pay Isn't Proportional To Productivity
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.'"
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.
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.
See, for instance, section 2 (Productivity) of the Hacker FAQ.
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.
That was quick
--alop
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.
It's also hard to reward. Also, "Paying a developer by the line is like paying an plumber by the pipe."
The Institute of Incomplete Research has determined that 9 of out 10
This anecdote sums it up quite nicely. Now all we need is a few more of those and we have data :P
:/- spoon(_).
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..
- Minutus cantorum, minutus balorum, minutus carborata descendum pantorum.
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.
My blog: http://www.seebs.net/log/ --- My iPhone/iPad app: http://www.seebs.net/seebsfrac/
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...
"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?
common-sense topic
first sentence has no verb
second sentence starts with a conjunction
ctrl f4
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.
She was like chocolate when she drank... semi-sweet at first and then increasingly bitter.
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.
Error 500 - Internal server error ...staring off into space...I've seen this before...
An internal server error has occured!
Please try again later.
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.
Have gnu, will travel.
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.
Deleted
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.
Read radical news here
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.
I want to delete my account but Slashdot doesn't allow it.
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.
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.
Sometimes the light at the end of the tunnel is the headlight of an oncoming train.
The most productive programmers are orders of magnitude more productive than average programmers.
There, fixed that for you.
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.
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.
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.
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.)
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.
Its been well known 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.
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 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."
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)
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.
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.
-kgj
Unfortunately, most people suck...
So they usually blow it.
"We returned the General to El Salvador, or maybe Guatemala, it's difficult to tell from 10,000 feet"
'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!
I've abandoned my search for truth; now I'm just looking for some useful delusions.
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.
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.
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.
Just another "DOJ fascist authoritarian totalitarian bootlicker" -- Zeio
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...
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.
by Mike Buddha -- Someday the mountain might get him, but the law never will.
> "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
Bark less. Wag more.
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.
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/ 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
That's how to get noticed.
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.
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.
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".
Be More, Be Manly, The Manly Geek Ubergeek Extraordinaire Blogger: www.manlygeek.com/blog Podcaster: podcast.man
UH...becuase the salary depends on supply and demand! DUH!
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.
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.
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...
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?
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!
I've abandoned my search for truth; now I'm just looking for some useful delusions.
The really good coders are the ones that can talk the talk to the business then translate that to something the rest of the team can use. They have vision and have design skills. A good coder just doesn't start writing things. They think about the problems, think about the solutions. They know when to apply the large sledgehammer to a problem and when to apply a small Ball Pein Hammer. They inspire confidence with the business and the developers. A good coder knows why Architects suck, but has the skills that are most sought after in an Architect.
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.
This is my sig.
My wife got fired from her job at a hospital because she was 'only at 98% productivity'. What her (clueless) boss didn't realize was that as the first point of contact at her department, (the main) part of her job was sending referrals to the other ten therapists there-essentially feeding THEM most of the business. Can you see why she was only at 98%? She was carrying 11 therapists including herself. Needless to say, the productivity of THE ENTIRE DEPARTMENT dropped by about 50% within a month after she was gone! Her boss was heard to mutter: "I had no clue that she was doing so much for us".
For the lack of a better metric, the developer with higher IQ should earn more. Programming is a highly g-loaded job, so I would rather maintain a 10 year-old code of someone with IQ 125 than of IQ 105. Anyways from what i've heard, the hiring tests they give at Microsoft or Google are basically IQ tests.
Probably we should even devise an IQ-based project metric. Something like a "this projet is 1000 IQ-months." Since this does not exclude employing a 100 monkeys for a month, maybe it is better to express it in terms of standard deviations, or IQ above 100, or something like that.
Being salary means you're paid to do a job and spend >= 40 hours a week at work.
Not necessarily. The first part is right but the hours is entirely up to the company and employee to negotiate. Some employers MIGHT want you there for >= 40 hours but others don't care at all as long as you get your assigned tasks done. My wife has a salaried job but she only puts in 20-30 hours per week because that's all the work there is. Nothing would be gained by her continued presence in the office and her employers know that. A salary just means you get paid a fixed amount regardless of the number of hours worked.
I was once directed to write a (motor) fleet management software package for our ~12 vehicles. It took several days to convince management that it would be cheaper and better to purchase a commercially available solution.
Keep Doing Good.
Yup. You have read the tale of the Wizard Mel, I'm sure? :P
This is 100% true! In 1973, I was making minumum wage ($1.75). A gallon of gas cost 50 cents. A scoop of ice cream 20 cents. A hamburger 30 cents. Today a gallon of gas costs 2.95, a scoop of ice cream 2.00 and a hamburger $1.00. Also, all of these are taxed more then before. To stay even, the minumum wage would have had to go up by about 10X to $17.50 an hour. Right now it's about half that-which means that the average minimum wage worked has about HALF the buying power that one had in 1973.
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.
Except that you could also say the capitalist always always pays people exactly what they are worth, and increases costs to consumers to create profits.
Both are non-sensical. That's why in reality, someone decides if payment being offered is worth them working for the company. Pretty much by definition, you are being paid what you are worth because only you can really decide that by accepting an offer. If you think you are not "being paid what you are worth" then you need to find someone who will pay you that, or at least leave and not suffer the insult of a continued paycheck.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
1) Code an uber-efficient program to save a manufacturing company millions and increase output.
2) Get laid off by a stupid manager because he craved power over the status quo.
3) Shop around to competitors explaining that you could do something similar for them in 6 months, especially those who have a similar legacy system.
4) BIG TIME PROFIT!
Sure you'd have to code from the ground up but hey it's a paycheck and I'm sure you could do it again. That's how capitalism is supposed to work. Eventually there's a good chance one of those companies will snap you up and realize what a gem you are. I agree that situation sucked but that's not about capitalism, just some schmucks afraid of change.
"All great wisdom is contained in .signature files"
Who's actually met a manager who could competently rate a coder's skills?
"The basic problem, Cook explains, is that extreme programmer productivity may not be obvious."
The basic problem is that extreme programmer productivity is a myth.
The parenthetical may seem odd, but, for example, I was once asked to "fix" some code that was working correctly, but returning numbers management didn't like. I said: No thanks. You can't use a context "diff" for SLOC counts and expect the number of adds, deletes, and changes to always match what you expect. The utility generates the edits needed to alter the code from A to B. They're usually the most "efficient" list of edits, which isn't always what was done. Simply changing the counts with a formula isn't the solution.
Yes, sometimes I'm a dick, but it's probably warranted - deal with it.
It must have been something you assimilated. . . .
You're on the right track if your customer can stand behind you and verify that you have their rules down correctly in your code.
That's right. I used to get upset about it, but now I just laugh. The most recent example of sysadmin invisibility came out when the CEO thanked "everyone" in the organization for their contributions. "Everyone" that is, except IT. We're just the department that gives everyone else the tools that they utilize to do their jobs with.
The value is obvious when it's completed
And that's the problem. Would you pay the programmer when the first drop is made to production, when the beta test has been completed or when all the bugs have been found and fixed. One could argue that it's only when that third consdition has been met, that a program is really completed - and as we know, it never happens.
It's obviously the worst suggestion in the world to pay up when the program is released (either to prod or to customers) as that produces a perverse incentive to slap it together as quickly as possible - with no heed for the number of mistakes it contains.
politicians are like babies' nappies: they should both be changed regularly and for the same reasons
I blame you specifically for the fact that my computer, which is literally thousands of times more powerfull than the one I had 20 years ago still feels about the same, and in many ways even slower.
Paying taxes to buy civilization is like paying a hooker to buy love.
In terms of productivity, the code produced by a programmer could be quite small, but yield much better results for a problem at hand. And knowing the limitations of such a method versus an "obvious" solution would be equally important, but not necessarily evident in the resulting code.
If you can't reliably measure coder productivity, then why would there be a simple correlation between productivity and pay?
It seems clear from this thread that employers generally suck at identifying the most valuable coders. I' ve heard managers trash coders as a class (as compared to the designers who manage the project).
Basically, coders are hidden from the world by layers of management. Often that management cannot competently evaluate their work. That problem cannot be meaningfully addresssed from within. Value of a worker can only be determined by reference to the market for similar workers.
The focus should be on showcasing your capabilities to the 'outside' world, as much as doing good work for your employer. MBA morons will covet you proportionately to how others covet you.
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.
I would argue that a coder who gets distracted by irrelevant issues is not, in fact, an "uber-coder." It definitely limits the tasks you can assign to him if he really digs into the billions-of-row multi-core performance for every single task. And I think one of the most important skills a programmer can have is to be aware of the entire problem domain, and know which tasks are worthwhile and which are not-- instead of just burying his nose into an editor 8 hours a day.
But anyway, that's just me, and I don't manage programmers, so take that how you will.
Comment of the year
"For the lack of a better metric, the developer with higher IQ should earn more... Anyways from what i've heard, the hiring tests they give at Microsoft or Google are basically IQ tests."
Ready...Aim..
I think the pay should be, pay suggested by sloccount x 3
Yeah, this thread is full of those "primadonna programmers", who want to believe they all are so much better than the average. Let me get this straight: I will not hire you or your kind. The good programmers are the ones that provide value for the company. They are professionals, and can be a bit hard to find.
* Primadonnas whine about choice of language, environment, platform, bloat, speed, coding standards etc. A professional just does the job he is told to do.
* Professionals understands the business' needs and priorities, and act thereafter. Primadonnas don't.
* Companies don't fail because of slightly buggy or slow programs. They fail because of bad marketing, time to market or a bad business plan. Code quality is not that important. So the primadonna mad skills are not worth nearly as much as you would like to think.
* Primadonnas often have a misconception that code is somehow art. Newsflash! It isn't. Coding is just creating classes that fit together to form a product, and real professionals know that.
* Real professionals don't have any opinions on using others code, letting anyone else change in their code or even abandoning their code. Primadonnas are often territorial of their code, and are reluctant to use code written by others (esp. 3rd parties).
* Primadonnas often spend time "thinking" (i.e. facebooking, surfing etc) and codes like 25% of his time and goofing off the rest. A professional comes in, works the day and leaves.
* I can admit that code written by primadonnas can be well thought through, but code designed by a professional isn't that far after. Apart from the pro churning it out immediately and the primadonna "thinking" about it the whole day first.
* I also agree that a tie isn't always necessary for programmers. However, a professional often wears one just to show that he is a professional to distinguish himself from the primadonnas, and because he wants to be taken seriously.
I could go on all night, but you primadonnas around here: stop whining and start behaving like real pro's. You might get promoted that way, get a raise or at least not be the first to be laid off. Get off your high horses.
Most managers just arn't going to assign one (uber) programmer 10x the workload of another, so the company doesn't get the benefit. What happens in practice is that the uber programmer is under-utilized and therefore benefits from his uber-ness not in terms of pay comessurate with what he can do but in terms of spare time comessurate with assignment completion times for what he was asked to do.
We can debate the relative merits of the real value of the minimum wage at another time but, in the interim, in the interests of accuracy, for a slightly less anecdotal analysis of the relative value of the US dollar, see MeasuringWorth.com (which suggests $8.48/hr as an equivalent minimum wage, not $17.50, based on the consumer price index). That's a lot closer to par.
I believe most economists suggest that the CPI slightly-overstates inflation by failing to make any adjustment for increases in product quality (things squeezable ketchup bottles instead of glass, or music on an iPod instead of a Walkman, or safer cars less likely to kill you in an accident).
The World Wide Web is dying. Soon, we shall have only the Internet.
Some rambling thoughts on some dude's unprofessional, horribly designed blog is NOT a valid source for submission content. Get this crap off /...
An artist isn't paid for their productivity either. One who can jam out a design and final work in 10 hours gets paid the same as one who does it in 20. Someone who paints as much as possible every hour of the week can find himself getting paid less than someone who only paints 5 hours a day, 5 days a week.
Ginga no Rekshiya Mata Each page.
In a large company a software engineer is hired to fill a well-defined position with a specific budget. There is only so much room to increase the monetary and equity compensation. And that's subject to strict corporate guidlines.
Anybody who's ever worked a union job can tell you it doesn't happen because your coworkers will beat the shit out of you.
...someone who stares quietly into space and then says 'Hmm. I think I've seen something like this before.'"
Finally! Now I know what to say when I'm caught spacing out at work.
It is by the juice of the coffee bean that thoughts acquire speed, the teeth acquire stains. The stains become a warning
Of course, unless the uber-coder took twice as long (usually that's the case) and requirements change mid-stream (ditto) and the hardware/distro changes as well (ditto-ditto)
It's finding the right balance folks.
to the bean counter on the 6th floor.
Thanks.
This is *SO* true it isn't even funny.
True story. Working for a hardware company that produced a hardware product that required a fair amount of microcode to complete it, one guy's code was so solid it was practically inhuman. Everything he ever wrote just worked. When it came time to "mad rush" to get the product out and every one was fixing bugs in there stuff, he was no where to be seen. His stuff just worked and his presence wasn't needed. Management however, gave him an extremely poor review because he "wasn't pulling his weight to get the product out". Everyone was in a self induced death march, except for him and he was punished for it.
Not surprisingly, the guy left... Beware of the "hero" programmer that saves the day while not doing shit the rest of the time.
Is using standard library functions considered cheating? Or more specifically, standard functions from libc?
Not that it matters to me, I'm not in the correct age group for your challenge, since I'm 30 now.
GLaDOS for President 2016! "Well here we are again. It's always such a pleasure." -- GLaDOS, 2011
I know that where I work, most of my best work is done behind the scenes. I get it done, tell my boss that I want to be the one to demo it to the client since it is awesome, but it ends up being an engineer and my boss demo'ing it.
I am currently an programmer analyst.
I somehow landed on the team of pretty much all really good programmers.
Now, the pay is not the best, but I do know that every 6 months, we have a review and are actually given numbers based on our performance. Now, the performance does not have to do with time barriers (unless we constantly do not hit the deadlines), but on aspects like how independent we are (i.e. we get a project and not sitting in our team mates cube the entire time asking them about it), team work (i.e. we all do our part that is given), and normal factors such as showing up to work on time and stuff like that.
I agree that with many programmers today, it is very difficult to get as noticed as some of the old school programmers since alot of code that is truly worthy of being called a breakthrough has been done already, and many of us, like myself, simply program on top of that breakthrough.
I personally think that an uber programmer can do a couple things:
1.) be given specs and know exactly how to do them. Maybe not right away, but they will be able to do it. I do it every once in awhile, and I know that some of you probably do as well. We will sit there just thinking and getting everything in place in our heads not touching the keyboard, and then everything will just click and we will go nuts
2.) Constantly learning. Some people will just refuse to quit learning, and it will show. We will be working, and then they will learn about something new, try it out, and then tell everybody else about it.
3.) Is the first person to show everybody their code. I work with a couple dudes who do this. The dudes are seriously brilliant. They will get done with a chunk of code, and want to share it with everybody. On the other side, there is one guy who will do a chunk of code and compile it, then share it so that only that person ever knows what is in that code. I just think if you an uber programmer knows they wrote something amazing, they will want, at the very least, people on their team to see it.
4.) Solve problems in other people's code extremely easily. Again, this goes back to this guy I work with. Regardless of the issue with a script kiddies code or just a programmers code, this person will look at it, think about a little bit, and then just solve it.
Of course, these are just my opinions dudes. If you think I am incorrect, I already know you will say something, I just figured I would throw this out there
The world is how you make it
it can't be broken down and measured on a spreadsheet so that one person is easily comparable with another
and this infuriates PHBs and and business types, who can't translate a programmer's salary directly how it impacts the bottom line like they can with sales force, capital expenses, etc
in any larger organization a good programmer not only delivers good product but also carries the weight of X affirmative action hires, Y gender equity hires, and Z nepotism hires none of whom can do the job but are politically impossible to get rid of
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.
I believe this is a restatement of a completely trivial matter that should not even have been posted here, which is: besides quantity there is also quality!
It doesn't matter if you don't get paid what you're worth, as long as you aren't going to be paid better anywhere else. Because what's your game options, quit and get a different job that sees even less of your value? Go independent and try to bill rates that high? Join a start-up and try to get that much of the total? Quit or take a long vacation and pray they'll miss you enough to take you back on a higher salary? Yeah right.
A lot of people might know internally what you did, but it's hard to convince outsiders that the projects you did really were that hard and you were that crucial to the solution and your solution was that great. Maybe even your boss knows you're brillant and he's rather fire the whole team and hand the money to you if that was what's needed to make you stay, but it will never come to that. Because who else would pay you that much money? Nobody. I guess maybe if you got some entrepreneurial skills and build the company around yourself it might happen, but that takes a very special kind of people which rarely overlaps with mastering coding.
Live today, because you never know what tomorrow brings
most "Programmers" are M&P grades and not hourly paid
As a contractor it works out pretty well. Quote a month, finish in a week, show the client normal milestones. Wait for feedback, rinse-repeat. Let the client be the one that pushes deadlines. :)
There's no shame in being efficient, just don't lie and say you're tracking by the hour when you're really invoicing your quoted total to accomplish a project. Good clients are happy to pay exactly what they expect to pay. Hourly comes with maintenance.
I almost stopped reading when he said Joel Spolsky.
Joel is always looking down his nose at other coders who don't have degrees from MIT. Yet he thinks pointers are the ultimate test of a programmer. He has written one tool that is of note - Fogbugz. That is, if he even wrote the code.
He just reeks of "I know better". He wrote his own language to code-gen classic ASP applications, along with PHP. Right there is a red flag. Did they move to the new ASP.net platform? Nope. That wasn't good enough I guess. No they decided to stick with classic ASP and write a language that outputs both ASP and PHP. Epic arrogance combined with ignorance IMHO.
Then look at Fogbugz. It's just a typical bug tracking application. That's it. Did it need a new language? Hardly. So now these guys wasted all that time on something only they can use and it makes zero dollars. Way to go. Real top notch development there. Fact is his company is small potatoes.
Why do I rant on Joel? Because this guy is believing the shit he spouts and extrapolating from it. Frankly I'm sick of hearing from him about what makes a good programmer. If you aren't a good programmer yourself then STFU about what makes a good programmer. Writing a few insignificant applications doesn't make you a rock star.
I haven't written any code since I was born!
...compensated in proportion to their productivity because you cannot measure their productivity.
Warning: this article may contain humor, sarcasm, parody, and perhaps even irony. Read at your own risk.
There is an anecdote in the business world about an efficiency expert that did an analysis for a company. The expert reported to the owner of the company that everything was optimal with the exception of a certain person in an office who appeared to do nothing other than sit in his chair with his feet on his desk, staring off into space.
The owner of the company mentioned that the person was in that position when he came up with an idea that made the company millions of dollars.
Sometimes thinking IS doing.
With regards to the "uber" programmer, is it better to start creating a new algorithm as fast as you can type or to find an existing algorithm that just needs a minor tweak to work? Starting from scratch means that you have to debug from scratch. Starting from an existing template that you know about and perhaps wrote means that you have most of the testing done ahead of time.
In the modern world, those who create wealth are *never* paid anything close to the value of what they created. The lion's share goes to the rich fat-cats that sit at the top of the corporate ladder, contributing nothing that wouldn't have been present otherwise.
Exploitation - its how humans do things.
This what comments are for. Good source code consists of good commands that are self readable and good comments where the code is not self readable.
After updating a few hundred 20+ year old software modules written by "clever programmers" I will insist that if your code is not readable then you have written bad code. Some of original authors wrote quite fast and quite efficient code, but the sheer amount of time to repair even a small issue in one of these programs, far out weighs the cost of writing a 2 line explanation of what is happening and more importantly, why.
+1 funny.
"Lazy" programmers also put in more work front end to write easy to read code AND code that can be reused with minimal effort. They also document what they do so they don't have to puzzle out what the code does months and years down the line.
This sort of thanks always stops at sales and their higher ups. Going on that statement this "thanks" never trickles down to anyone else involved in the sales process, the running of the business that the sales people work for, etc.
It is not strictly a problem (if it is a problem at all) of coders.
8000/40/4 = 50.
Typing was hardly the bottleneck. In fact I bet there was quite a bit of staring into space.
people get paid in proportion to how difficult management perceives replacing them is. In this, coding is no different than most other jobs.
This posting is provided 'AS IS' without warranty of any kind, implied or otherwise.
There's no "incentivize"; the word you're after is "incite".
If only my client would've known that progress is not measured by lines of code. Instead they use a team from India to write their product, which has 100x more lines of code than it should have, and I'm stuck here cleaning up the mess.
College-Pages.com - Online Colleges, Degrees, and Programs
That's the same as many other jobs. And, by the way, if you can't measure the direct impact easily, human nature and the basics of organization mean that in almost any medium to large entity, those who are highly productive, but not measurably so, will be underpaid relative to those who are measurably productive.
Now you finally understand why your pay sucks.
I don't think it's utterly beyond belief that a good CEO can make deals with other bigwigs and boost the company's bottom line at least 200x as much as an average worker can.
The multiplier can be much greater than that -- but there are still ways to make it work for you.
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.
As a developer ( I don't think we have enough of an development group to really qualify for low level programmer positions) I can most definately say that when you pull something off that works, and works well, for years with little maintenance, it definately gets recognized.
Over the course of my full-on Software career that started say 5-6 years ago, I have definately gotten alot better at debugging and avoiding pitfalls. To have a pair of developers work on something for 1 month and have it run smoothly for the next year or two and save time in the organization daily, you DEFINATELY notice when it runs without any major hiccups. It isnt always that way. Minor hiccups are OK, but I think the most problematic is when there is an identified issue and it can't be quickly solved. If a bug turns up a year later, and you can fix it in half an hour on your system, you are doing ok as far as I can tell.
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.
Slashdot social media options: AIM, ICQ, Yahoo, Jabber and Mobile Text. Why no MySpace?
...And if you MUST include your clever bit of unreadable code, make sure you include the original code in comments and explain how you transformed that code into your unmaintainable code. That way, when somebody has to fix your inevitable bugs, atleast they still have SOME level of maintainability.
And before somebody replies that the two pieces of code may go out of sync; let's just hope the maintainer isn't as much of an arrogant "leet" coder as the original developer and does the right thing.
Slashdot social media options: AIM, ICQ, Yahoo, Jabber and Mobile Text. Why no MySpace?
absolutely agreed!
even if it's a 'new' language to you, it can make sense.
Oddly enough, 20 years ago they DID do a lot of unmaintainable optimalization.
Slashdot social media options: AIM, ICQ, Yahoo, Jabber and Mobile Text. Why no MySpace?
In my opinion programming is an art form. There is a lot of nuance to it, and you need to have a trained eye to know what to look for. It would be obvious to people that you cant judge an artist by how many paintings he has done. You just have the talent, or you dont.
I have.
A salesman creates 10-times the revenue when his sales increase that much. A bricklayer can save the cost of 10 other employees. However, software programming doesn't yield that factor-of-10 monetary benefit. A company can't survive by paying employees more than the revenue, really the profit!
Some 21st century economic ideas are mentioned here: :-)
http://en.wikipedia.org/wiki/Jobless_recovery
"Many people seem to have a piece of the answer to the economic puzzle of the 21st century, including about jobs. As the pieces are put together, emerging from a response to the 2007 global financial crisis, we may well eventually see a new synthesis moving beyond Keynesian economics, in a way that will have the same profound effect in the 21st century as Keynes' work had in the 20th century, although reflecting the changes since then, perhaps reflecting a positive psychology change in emphasis from focusing on managing scarcity to focusing on creating abundance."
A 21st century issue: the irony of technologies of abundance in the hands of those still thinking in terms of scarcity.
No doubt whatsoever that the time has to be productively spent. In my admittedly contrived example I assumed the uber coder was given the histogrammer because it really was performance critical and a high risk component in the system.
+1 Bloodhound Gang reference?
I feel fantastic, and I'm still alive.
I blame your selective memory for making you think your computer is slower than what had remember 20 years ago.
by Mike Buddha -- Someday the mountain might get him, but the law never will.
I find that programs grow and shrink periodically. Features are added in the growth phase, then the experience of writing that code and seeing how it works in detail provides the insight to generalize it and reduce the amount of special cases, which causes the code to shrink. Generalizing code feels productive and is a very important aspect of code maintenance, but it usually doesn't contribute features, which is what non-programmers see as the real improvement.
I don't consider myself uber-coder, but somehow the description fits. I would call the uber-coder as a strategic coder because he/she will overlook whole project and see the problems coming ahead of time. Unfortunately the position in programming team doesn't always allow these programmers to excel and stacks too much mundane work on them. If organization is functioning properly these programmer are recognized and given lead, architect, mentor roles that will enable whole unit complete tasks faster due to coherent direction and technical solutions this uber-coder provides. On my career the programming positions I have held have ended up first as Software Architect, and second as Director level quite quickly and overall contribution as lines of code has never been that great.
I don't care if you go to an AA, aA, or Aa meeting, but I suspect you had better get to one of them, and soon ... ;-)
Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
No, that's what comments are for, you can't expect people to be able to read your code.
For a trivial example consider regular expressions - it doesn't have to be complicated before somebody will whine that they can't read your code. With enough comments they can get a clue, know where to look to fill a hole in their knowlege and then be able to work out what the code does. For less trivial examples they can go and ask an engineer, scientist or mathematician about the simple matrix algebra that was ignored because it wasn't on the test.
This equilibrium is what they hard sell to the populations, as the justification for their policies, but no way do they ever want to achieve that.
The globalist fatcats will *always* make sure there is a great imbalance in wages (a lack of equilibrium) so they can take advantage of wage arbitrage, plus get paid to destroy any approaching equilibrium, then get paid again to start to reconstruct it..but they will never let it actually get there. It isn't nearly as profitable for them after that point of equilibrium, nor would they be able to maintain so much political power, which is even more of a lust for the uber rich than just the mere accumulation of currency units. The dig on that ultimate control over other humans, that is theior primary goal and lust, that is why so many political and economic top people appear to be so sociopathic at times..it is because *they are*.
They have done this construction/deconstruction, keep the people divided and conquered repeatedly over the years, and that is by the use of war, external or internal and frequently both, by destroying the infrastructure and a lot of the population in other areas that are approaching parity with them (and in their own areas frequently as a blow-by). In many instances, at the tippy top of capitalism, (WW2 is a prime example) they fund all the warring sides *at the same time*, destroying a lot of what had been built up, which therefore needs another infusion of the people's capital (their labor and most of their wealth, overtly or through other political controls) to them so they can rebuild..what they engineered to destroy in the first place. They get *rewarded* for being high level criminals. Over and over again.
It's pretty easy to wipe out a productive middle class during a war phase and reduce them back down to serf/peon class, to be exploitable in the normal kingly manner, your own people or those folks over yonder, it doesn't matter to that class of exploiters.
It is very wasteful and downright painful for the global populations as a whole that they keep on doing this, that we can't achieve a fair and balanced natural economic equilibrium, but it serves the purpose quite well (for them) by maintaining these top 1% crooks and predators in their positions at all times.
The aristocracy was never abolished in practice, just in a lot of cases they dropped that public "royal blood" stuff and started wearing more "normal" attire so they would not appear to be as such. Just a camouflage maneuver and so they can continue to fake out their herds of slaves by telling them they now live in some sort of "elected by the people" government, when it has always been these same fatcats calling the shots and doing the most in the way of profiting from other's work.
They are *wolves* and will always act in a predatory manner. They may even war on some other of their fellow wolves now and then, but the wolves as a class are always united in that they need to keep the wolves and prey animals/herds separate and cowed.
Here's an obvious example of wolf class versus their prey animals, so they can keep feeding on them and make it look like they aren't. All this war on carbon and new taxes and permits and credits and treaties and schemes and laws and so on. Well, the serfs and peons (and I include any alleged "middle class" that exists anyplace, they are still the property of the wolves, they are temporarily allowed a few more toys in exchange for perpetual lifetime indebtedness and subservience to the wolves) will be paying for that, because there ain't a singe fatcat wolf predator out there who is going to drive less, fly less, eat less, stop living in multiple mansions, etc.
All the ones "negotiating" all this nonsense...whatever they negotiate is NOT going to apply to them or impact their lifestyles in any practical measurable manner. The wolves will remain wolves and their sheep will be eaten just as much and be shorn a little closer to the hide, that's all.
I can see from the comments that the one thing coders are really really good at is making excuses for being unproductive, incompetent, and unpleasant. Count your blessings you even get paid. For anything.
Those most recognized and rewarded in a technical organization are those who work a crisis to gain recognition (i.e. mess up big, and get a raise for fixing it). Those who avoid crisis are left in the shadows (i.e. a solution won't impress a boss unless it actually gets his balls out of a sling, merely preventing them getting there will get you nowhere). See also XKCD: http://www.xkcd.com/664/
http://www.folklore.org/StoryView.py?project=Macintosh&story=Negative_2000_Lines_Of_Code.txt&topic=Software%20Design&sortOrder=Sort%20by%20Date&detail=medium
A productive programmer is one who solves the business problem at hand.
An excellent programmer understands the problem, and helps the organization solve it in the most efficient manner possible.
Over the last 15-20 years, middle-class Americans have become poorer in real terms year on year, and there's no sign of that trend stopping.
I look at the material goods and homes the middle class people I know have, and I cry bullshit.
You are using one absolute metric - money. But real wealth is measured in all sorts of things. Lots of people I know take more time off with family. This reduces your wealth metric but are they truly poorer, or have they just made a different life choice than generations past? Then look at the vast array of electronics that are common in any middle class home today, look upon that and cry your spell of doom with a straight face. Yes the rich are better off but so are the middle class (to date).
Only the very rich are become better off, while the middle is clearly declining. As to the bottom? Being broke is being broke.
I have been to Africa. I have been to recovering eastern european countries. I have seen true poverty and I say nuts to your "worse off" doom and gloom, when even the homeless here are better off than many of the people with "homes" in Africa!!!
The U.S. economy has issues, but has so very fall to far before any are truly poor... perhaps we'll start to see signs when unemployment hits 20%, if it ever gets there. Or if the government decides to suck the life out of the middle class, but so far they don't seem to be up to it, not really.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
This topic is terrifying! Productivity only makes sense when you have a static goal, which is not the case in any working environment I've encountered. Instead, I've found that I'm paid for tolerance. When a manager asks me to deliver X, but a marketer suddenly promises Y, I get paid for not killing both of them. When my manager asks me to make 1 + 1 = 3, and a marketer promises a client that 1 + 1 = 6.255, I get paid for not going on a murderous rampage. Seriously - if it weren't for these wages - programmers would have a worse reputation than postal workers. We get paid to be driven crazy.
Can you say you are "deciding" when your family is hungry or your children are sick and a job is the only way to get health care benefits without going broke?
Agreeing to take a job at a specified price is as I said the definition of how much you are worth (and of course in this sense worth is purely in monetary terms, since people have so many other facets valuable in other ways). If there are preconditions making you take the job like lack of savings and a family to feed they are simply making you re-calculate that figure to be more accurate for the choices you have made.
I don't think you understand that well enough, a persons "worth" is determined by all aspects of their lives. If you have a lifestyle that requires a certain level of income, is that really a factor of how much you are "worth" or instead how much you have chosen to spend? There is a distinct difference. You say that person is not deciding anything but is forced to take a job. I say they have spent a lifetime "deciding" what will happen to them through actions they have taken and choices they have made.
Also, I don't understand how anyone could argue there is one absolute inflexible number that represents a workers "worth", since even artisans working for themselves must build things the market is willing to buy, and in tough times customers will buy fewer things at lower prices. The notion that you are forced to take a job because of family obligations represents being paid less than you are "worth" doesn't make any sense, you are being paid what you are worth at that time for the market and economy in which you live. Not to mention that your "worth" obviously changes depending on the work you are doing, if a former banker is working at McDonalds should he be making bankers wages?
"There is more worth loving than we have strength to love." - Brian Jay Stanley
Pretty much by definition, you are being paid what you are worth because only you can really decide that by accepting an offer. ...
Only in a competitive market, though
Why does that matter? That doesn't matter at all. If you accept an offer you are saying "I am worth that much". If you truly think you are worth more you will starve, or find someone that agrees. Again, the very definition is what you accept.
Accepting a lower offer than you were planning on means you have re-calculated for conditions at hand. Worth (monetary) is never a fixed thing, and the value is always a function of the environment in which you live. Businesses have to recalculate prices for products, so too much workers recalculate value of output. Or were buggy-whip makers always to be paid the same forevermore after the invention of the car? I'm sure the Buggy-Whippers Local 504 thought so, but workers soon realized otherwise. The worth of all things change over time.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
'nuff said.
Meaning, I could give a hoot how long a piece of code is or how long it took to write. What I *do* care about is shipping deliverables on time and within the quality standards. Nothing else matters.
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.
The worst programmers I've met are the ones who are heads down and program. They are usually very arrogant and think they are gods. Case in point, there's a guy I currently work with who is a disaster. People are in awe of him because he will work until 4am and has improved the performance of our application 100-fold.
The problem is that during the design phase, he completely disregarded all of our design recommendations and did things his way. It turned into a complete disaster, with nothing working as it should, deadlocks and complete lack of scalability, etc. So yes, he worked until 4am to improve things and did improve the performance from the initial disastrous numbers, but it was all his own fault! As well, because he was so arrogant and stubborn, he ended up producing something that no one wants anymore because the interface is too abstract and hard to use. Now, our the product is being shut down before it has even launched, because we couldn't convince any consumers to "wait until the next release" to get it to do what they actually want. All the fellow programmers think he's an asshole, but all of the managers who don't understand what he does will undoubtedly promote him.
The best programmers are the ones who keep it simple, design things excellently and program it once, with maybe a couple of iterations of performance enhancement. I've met plenty of brilliant programmers in my time, and these are the key traits that they exhibit. The "brilliant", nerdy programmers that heads-down program are rarely any better than a smart, easy-going programmer that both works hard and spends more time listening to their customers and making common sense design decisions.
My favorite programmer metric is deceptively simple. Called "Delivered Testable Requirements" it simply counts the testable requirements delivered in the module, modification, etc. Of course, the "deceptively" part is that two things are typically missing from software development ... One is formal testing and the other is requirements so, Never Mind!
Most managers couldn't be fucked to tell a top programmer from a potted plant.
This also applies for many technical positions. I've witnessed complete retards having been hired for support or QA positions that were so utterly and obviously incompetent that made me stand speechless for 10 seconds. Really it took a few minutes to find it out, but the manager responsible for them still hadn't figured it out after a month.
fucking whiny ass bitches need to shut the FUCK UP.
you are a coder, nobody gives a shit. you know that guy in radio shack who sold you batteries? the one that you looked down your nose at, and were rude to because he was too slow and you were in a hurry? The one whose wife has two jobs so they can afford a shitty little bungalo in a semi-ghetto where the police budget has been cut.
He probably worked for IBM. Before they layed him off. So they could hire your arrogant prick of an ass.
Fuck you. You can code, so can everyone else within stones throw of a community college course on programming language.
Just, just shut the fuck up.
thats why you go to school to become a bricklayer, because youre not a bricklayer unless you can finish the job perfect
Some "uber" programmers, in addition to the store of techniques, have the ability to see patterns in how things work. If they don't have the algorithm they need in stock, they can adapt similar algorithms that at first glance don't seem relevant.
Christopher Alexander's "A Pattern Language" would be one example where an algorithm of sorts, one tied to architecture and city planning, was adapted to the programming world. Published in 1977, the book has been fairly influential in several areas. The Design Patterns movement mentions "A Pattern Language" in at least one of its core books.
Then you have GST or General Systems Theory. Predating pattern language by several decades, it looks at how things are similar at vastly different levels. For example, the chaotic flow of a simple candle flame and the explosion of a nova have a lot in common mathematically. If you were familiar with GST as an "uber" programmer, you might look at micro/macro examples for algorithm sources, especially if they are dealing with new territory.
As far as an "uber" programmer being able to remember everything they have done, said programmer might have a surrogate memory in the form of a database, with lots of descriptive keys, that touch on what they have done OR seen in the past.
A quick nap when I need it (which is most afternoons) makes a big difference in my productivity. I totally agree with your statement:
-kgj
"We're All Marxists Now" used to be a battle cry, or a complaint, or something.
But that's old news. "We're All Temps Now" better describes our condition.
-kgj
Frankly, its your own fault if you don't take the time to exemplify yourself to your superiors. I've seen plenty of people sit silently on the sideline, complaining about how no one knows what they do (the occasional 'give me back my stapler'), and turning that into a negative atmosphere. I've tried sticking up for these people in the past, only to be told to mind my own business; and I took that to heart.
this is my sig, there are many like it, but this one is mine.
I've actually had that experience....where it felt like I didn't get anything done because I was tracking down a really nasty intermittent bug for weeks--then it turned out to be a hardware issue.
Or where it turned out that the linux kernel had a bug where it would hang when adding a leap second. Combined with this, in one of our customer sites an NTP server erroneously indicated that a leap second should be added. The clue in that case was that the system hung at the stroke of midnight on December 31 (once corrected for timezone).
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.
That is all good except that it may be totally useless. The solution may be scalable for millions of data BUT if the application never needs to handle more than a few thousands of data, then the solution is just over engineering.
The ubbercoder should have implemented a good, simple, correct solution that fits the data that the application must actually deal with. Instead, he just wasted time playing with himself.
There are limits...