The other thing I've seen happen is that the more productive programmers are asked to do the more complicated things. So they'd be the ones creating a javascript drag-drop widgets framework while the less capable were stitching together CRUD apps with a bit of business logic in the backend.
This then looks like they're both delivering products, the CRUD app may even earn a lot more money for the business in the short term too.
I've even seen this kind of skill discrepancy in call centres when I temped as a student, this isn't restricted to the programming field. There's always a couple of people who knew how to fix actual problems rather than just enter payment details, they'd always be handed the troublesome clients but rarely got paid more.
I ended up as one of these myself, but none of us ever complained about being paid the same as Bob the lazy call avoider because it made our jobs far more interesting and satisfying.
In the end I guess part of being a high performer is that you know you're going to get the jobs that interest you and that in truth would just frustrate and demoralize your colleagues. It's not always about the pay.
That's a really good point. It's worth remembering that the person picking the low hanging fruit will often fill up the baskets faster than the person who climbs up to the tall branches, But since anyone can pick the low hanging fruit, you may need to send your most talented people into lower-yield environments, since they're the only ones who can do it.
Productivity really is difficult to measure, especially in software development.
It's not low/high hanging apples. It's apples and oranges. 1X programmer does job that is immeadiately visible and has value. 10X programmer writes code that has potential value, which is to be seen in the future, probably when some other 1X programmer implements his code. I now remembered a quote Anthony Hopkins said on 'Inside the actor studio' which he learnt while having a role as a butler: When you're in the room it has to be more empty. Same goes to great programmer and software system as is mentioned in the article.
Oh yes, completely agree. I was making a minor point about productivity, but this isn't the biggest issue at all in software development.
The biggest productivity difference between two programmers isn't that one of them produces more of the same thing as the other. Or that one of them produces more of a better thing that the other. Or even that one of them produces a more of a better, different thing than the other. It's that one of them actually grasps the thing that should to be done and does it. And it can take a long time to even realize or understand what it is the programmer is doing (often, the programmer doesn't fully understand it at first either).
My biggest problem with the 10x productivity claims is that it ignores the most relevant difference. The best programmers don't do the same things faster, they do completely different things.
> My biggest problem with the 10x productivity claims is that it ignores the most relevant difference. The best programmers don't do the same things faster, they do completely different things.
I thought the 10x productivity claim was originally from a study of comp sci students working on some algorithm (maybe compression algorithm) homework. In which case the "I think I've seen this before" example from the article probably factors in most.
A good manager in a software company should have a decent grasp of project complexity and output quality of his subordinates.
The examples listed seem to appear at companies that have in-house developers, but don't really think of IT as an area they should focus on. Similarly, I often found my ex ad-agency co-workers have trouble understanding why I have to browse blogs/manuals, take time to think things through, sketch graphs and sometimes just start over instead of refactoring.
Really, software managers should have no trouble noticing a 10:1 skill difference between devs.
There are very few good managers, and when you think about it very few programmers work in software companies. Instead they work for trading firms, utilities, banks, government agencies, etc.
When the business of the company isn't software, there is a good chance that the manager won't be a software developer. The criteria the developer is judged by will have nothing to do with the complexity of the software or the time it takes to create. Instead, their work will be judged and compensated by the value it delivers to the organization. Even if it's crappy software.
> The criteria the developer is judged by will have nothing to do with the complexity of the software or the time it takes to create. Instead, their work will be judged and compensated by the value it delivers to the organization.
You say that like it's different, or should be, at a software company.
I disagree. I think that all work for an organization should be judged and compensated by the value said work delivers to said organization, regardless of the organization type, regardless of the work type.
> Even if it's crappy software.
Surely you're not suggesting that crappy software is always wrong/bad.
Good software is often more expensive than crappy software. That added expense doesn't necessarily produce more value.
Good programmers know that they're trying to maximize benefits-costs, not maximize the former, not minimize the latter.
Really, software managers should have no trouble noticing a 10:1 skill difference between devs.
I absolutly agree with you, and on HN many of us are in a filter bubble in which the companies we are surounded my have a good deal of people that know software and creativity. The reality out in the real word though is much different. Many companies have managers that have never worked on software in their life, there is a school of thought that management is management, and for some disciplines it is true management is transferable, those of us in technology know this to be idiotic but if you came from a traditional enterprise and have seen multiple manager move from inventory to shipping and be successful you would believe the converse to be true. Years of observation reinforce this to those individuals and create cultures in which management is management.
How many people are "software managers" in a company, vs "managers" who happen to have people doing software in their dept? I worked someplace where they proudly stated "we're not a software shop!". They had 100+ software engineers working on stuff that managed billions of dollars in money for the company. But "they're not a software shop". OK.
They really weren't as bad as that statement makes them seem, and I think it was more a misguided "rah rah" statement than a core mentality, but there were days when I couldn't quite tell.
Love this example for two reasons, the first being the one you mentioned, and the other being the fact that the troublesome/interesting call probably isn't generating more revenue for your employer than the simple/boring call.
Have you tried it? (Don't forget to make sure it works in all the browsers at decent speeds!) It's not the most difficult thing, but it's reasonably complex, it doesn't seem like a bad example. How many teams have one person working on satellite code in Common Lisp and another doing a basic e-commerce site for a client?
Writing a CRUD app with business logic sounds more complicated.
The tough part is extracting the business logic and correctly mapping this to code. If done well, this will create more value to the business than a drag-and-drop framework.
That's the specific type of programming that's mentioned in the article "I am a programmer":
"We're middle-men (and women), glorified translators, and we're in the unbelievably fortunate position that programming computers is still much too hard for the average user of those computers, so we translate wishes and domain knowledge into a mental representation of machinery that performs some useful task."
The business logic is "the hard part" only in terms of client communication and project management, and then only barely.
Learning that "an Account Rep has Clients", and then modelling and implementing that, is ... not challenging? Three lines of ActiveRecord ('Duplo')?
They both vary tremendously depending on the problem, but on the whole, 'javascript widgets' trumps 'business logic' hands down. The fact that most business logic is simple is why you can glue things together so fast in Rails.
Olark's whole business is making a single javascript widget, and last I checked, they're still hiring.
Making things behave as expected in as heterogenous environment as the browser can be enormously complex as the sophistication and scope of the UI you present the user grows.
Boy, I really have a different opinion of enterprise software. The number and complexity of all of the various cases is astounding! To make it worse, they frequently come with no underlying framework, so you have to extrapolate and hope that you don't bake in something that's going to change next week.
IMO, making that software to handle the business processes IS way more valuable to the business than a drag and drop widget framework. Especially if you execute it well, it can make the business hum.
Enterprise software is not complex because it needs to be it's complex because the east way to deal with complexity is to create a complex system. Take the database design for my current project when I joined the project the database design had over 500 tables for a brand new system. But, by making a few minor design changes I cut several hundred tables from the design without sacrificing anything. At one point I removed 30 tables by adding a single field to a single table.
PS: Yes, copy and paste is easy, and yes it looks like work, but it's rarely the correct solution.
See my other reply below to toyg, if your company is writing a lot of similar software your going to have to start making flexible standard stuff rather than rewriting it every time.
But I agree with you if you're going in with a blank slate.
The business logic is "the hard part" only in terms of client communication and project management, and then only barely.
Yeah, but it's the part that most customers actually want. They pay for that, not for javascript widgets. A lot of customers are incredibly happy with basic, predictable interfaces, as long as they perform all the necessary "magic" calculations in the background, quickly and reliably.
So many developers waste their time chasing "the shiny", but most of the money is actually elsewhere.
This was an extensible product, it had to be able to handle extra functionality and the widgets were a way of achieving this, so it had real business value.
And to answer the original question, yes it was complex, but that was 5 years ago. People didn't really know how to build complex solutions in javascript and there were no working examples you could just copy, paste and modify.
You were also very restricted by the speed that IE6 ran javascript on old computers.
As far as usability is concerned, basic predictable interfaces are what you should be building unless the data & interaction you're modeling is unique enough to require non-standard UI.
interesting/boring* doesn't always correspond to complicated/easy.
Actually, it might be even more complicated to _complete_ the extremely boring task.
* - in this particular example, js drag&drop being an interesting task is a subjective assumption, but I guess "yet another CRUD app" being boring is an objective reality :)
patio11 10 minutes ago | link
Programmers are paid in proportion to the value they create.
If you want to make more money, work on stuff that makes money,
then ask for that raise.
Is there really any other explanation? Think about this like patio11 or Greenspun: work on stuff that makes money/value for the business, go talk to your managers, point to the thing you created and say "this generated $X in revenue for us. I'd like to partake in some of that revenue."
Then head out to dinner or happy hour and enjoy your raise, or jump ship if the company laughs at you.
Isn't this how the labor market for programmers works? If not, why aren't we making this happen?
It is a valid argument for raises, especially early in your career. But at some point, you are no longer selling your personal value to your boss - you are competing with other programmers who are willing to give the same value for a lower salary.
To get past that point, you need to have specialized business knowledge so that outside programmers cannot compete with you.
The trick to getting very high salaries is to decrease the pool of competitors for work, by increasing specialized knowledge above and beyond your coding skills.
I agree. I've struggled with highlighting my accomplishments in the past, "tooting my own horn" so to speak. I guess to me it can feel like bragging or boasting, but that is something to get over.
I have found that where I work, if I don't explicitly tell my manager(s) what I've been working on and spotlighting the important things I've gotten done, they simply won't know about it.
It gives them ammunition to "fight" for you, to justify raises etc...
Isn't the obvious, uncomfortable answer, that management wants to maximize profitability? It's almost the definition of their job to find these 100x productivity programmers and pay them the 1x salary. Also, note that when you have an entire team of 100x programmers, and you are only paying them 2x or 3x the salary of the 1x programmer, the manager has succeeded well in their goal - not only has the pay-me-more-for-my-skill argument disappeared (they are all the same 100x skill level) but you are extracting the massive amount of excess productivity into profitability. bottom line is that if you really are a 100x programmer, it is difficult to fully capitalize on that skill
The romantic image of an über-programmer is someone who fires up Emacs, types like a machine gun, and delivers a flawless final product from scratch. A more accurate image would be someone who stares quietly into space for a few minutes and then says “Hmm. I think I’ve seen something like this before.”
I disagree with all the reasons he listed... because this is true of all careers, not just programming. I think it has more to do with our ideas about pay more than anything else.
Quite simply put, in almost all professions you're paid for being there for 9-5. If you show up and do your work poorly or not at all, you might get fired. If you do well, you will get a small raise. So to a small extent productivity is correlated. But the salaries aren't proportional to productivity; the biggest predictor of salary is if you're fulltime. You're getting paid for your time, not what you're producing.
Programming at the level of HN readers isn't a science, it's a creative art. You buy artwork based on it's value to you as a finished product. Very few people commission art from artists other than those who are very well known.
Conclusion - sell finished works of art, not your time. Effectively, SHIP A PRODUCT PEOPLE WANT.
Can we please stop using the phrase "circle jerk" to demean people we disagree with? Just because there may be "a bunch of idiots on here" doesn't make it Reddit.
I don't 'disagree' with him, one 'disagrees' with opinions, and I don't waste my time on that - opinions are like assholes, everyone's got one and most of them stink. There was a factual claim being made, that somehow people who read some specific pages on the internet (the HN pages) are smarter than others, a claim arising from snobbery and self-aggrandizement; one of a false duality, too, like your 'doesn't make it Reddit'.
Yes, it is. "Circle jerk" is a term used to denigrate someone who gives (in your view) unnecessarily effusive praise by comparing it to an adolescent sexual behavior. If you feel the praise is unwarranted, you're welcome to express that feeling -- and if you have evidence to support this, you're welcome to present it -- without the insult.
It's not an 'in my view', it's objectively wrong to outright assume that somehow people who read some site are better than others. There is no reasonable way to interpret the original comment in any other way.
Furthermore, it's not an ad hominem because an ad hominem is an argument that is being made by discrediting that argument not on its merits but on an unrelated other characteristic of whoever made it. I'm not doing that in any way - the use of 'circle jerk' in this context is perfectly warranted as a way to express disapproval of the poster's myopic thinking methods (or rather, myopic world view based on lack of thinking).
Software development is not an art, it is craftsmanship to make a tool. That isn't meant to demean development -- it just isn't the case that your code is making a statement on humanity or causing a user to ponder the meaning of existence.
I think there's a simple explanation for this: asymmetry of information. While the programmer knows that they are a 10x programmer, the company hiring them does not. Interviews, resumes, and referrals only provide a limited set of information, and surely not enough to boost the company's perception of you up to the 10x range. So that's why salaries are much more compressed than skill.
The standard economic solution for these types of markets is to offer a "warranty", the idea being that the better product will be able to outcompete on "warranty". For programmers that might mean agreeing to a contract where you get paid, say, $300k, but if after X time you aren't performing well enough then you have to pay back most of it. Actually this is sort of what happens already with equity.
If you have two programmers, and one is "10x more productive" than the other in that he knows when to reuse or adapt other code, but there is a problem that actually does require writing code, which one will put out a more correct, reliable solution faster? I would guess that it would be the 10x more productive programmer, because he/she doesn't just know when to reuse or adapt other code, but also when to reuse or adapt algorithms, architectures, etc. or "solutions" generally.
I'm annoyed that Cook is still undervaluing these programmers in this article by not explicitly mentioning solutions in general, but only "reusing code", which is just a special case of reusing solutions.
The '10x more productive' in this article was referring to people who reuse and adapt, you seem to have it backwards. You are infinitely more productive if you realize the problem is already solved. Not only is it faster, but it also isn't as likely to suffer from bugs.
But I also think you are assigning to him a slightly different opinion than I understood it. It's not just 'This would be a good time to use Excel!" or "This would be a good time to use Library X!", it's "This codebase already has something that is slightly different; we can probably generalize that slightly and save a lot of headaches". He is talking about people who write code every day, but people who are better able to apply existing frameworks to the new problem instead of banging out something from scratch.
Also with regards to your "still", this article is not new.
No, I don't have it backwards and that is indeed the kind of programmer he was talking about. I am only saying that the "This codebase already has something that is slightly different; we can probably generalize that slightly and save a lot of headaches" situation is just a special case of better, more adaptive problem solving that doesn't necessarily rely on the "codebase already [having] something that is slightly different".
And I know the article is not new, the point of "still" is that the article seeks to address the undervaluation of these programmers, yet doesn't give them their full due. This is because most (if not all) of the same programmers who practice that special case of efficient problem solving also are capable of more generalized forms of efficient problem solving, and Cook doesn't mention this.
> are capable of more generalized forms of efficient problem solving
I still don't understand what you are trying to say. The entire point of the article is that "people who are capable of the more generalized form of efficient problem solving are more valuable". He's not saying that you never have to sit down and get your hands dirty and write something from scratch, or that the most efficient people never do that.
You are agreeing with what he wrote and acting like he said the opposite.
A corollary of this article is that experience is also undervalued. It is experience and the ability to reflect on it intelligently that prevents people from making a mess. Its that mess that is killing productivity in most shops.
Maybe, but if you paid the juniors appropriately on that scale they'd never get into the industry and if you paid the seniors on that scale the business couldn't afford them.
I think we should address 2 questions first before we can answer this. Why do some programmers think they are 10x or 100x more productive than others? Is it a myth or is it for real? Give some concrete examples of 10x productivity for a start.
Do you have any references for this, my good man? I don't mean to question your comment; I want to learn more about how this has been established and the nature of it.
I don't have any references to academic research, but my own experience interviewing people supports the claim. When presented with a simple coding problem, some people just breeze through it, others take most of the interview to finish it, and some candidates just can't solve it at all.
To the extent to which coding on a whiteboard is an indicator of real-world productivity, there definitely seems to be at least 5x difference.
I have worked with people who needed to see the whole picture before they could implement anything. Whereas I can seem to be able to jump in and start building even while lacking information. I have some weird ability (or perhaps not so weird, it is probably just a result of experience) to infer what is not yet there; the whole picture only becomes clear to me when I am done.
In those cases, I was seeing at least a 10x productivity increase because while they were sitting around thinking about the problem, I was already writing code, working on the parts that I did understand, while gaining a greater understanding of the rest during that process. Once we all reached the point of understanding, those gains became negligible, and our productivity was probably closer to par.
If you're writing the same old boilerplate code day in, day out, it is probably hard to realize increased productivity between individuals. However, if you're venturing into new problems constantly, I believe different developers can be quite a bit more productive over others.
There are many concrete examples where the productivity of a programmer may be positive or negative.
For example:
How many more tasks did you complete on average?
How much time did you require the assistance of your colleagues?
How many times per day do you interrupt other developers and prevent them from doing their job?
So the productivity multiplier is either over 1x or under 1x. When you multiply it up together for all the members of your team, and you normalize so that the lowest multiplier is 1x, you might realize that in fact some co-workers can be 100x more productive than others.
10 times is actually an understatement....For example Marco Arment made instapaper himself...try asking a 100 person team at xyz corp to make something like that!
This article and general theme are based on an invalid premise. Many of the most productive programmers are, in fact paid in proportion to their productivity.
Such people are likely to found startups or join at an early stage or they're likely to work at places like Google that issue large stock grants to many of their most productive programmers. Those who don't are more interested in stability than money.
Large non-software companies and governments fail to compensate their most productive programmers proportionally because they have difficulty identifying the benefits they're getting or simply don't value them all that highly. Most of us consider it obvious that such organizations aren't the most desirable work environment for programmers.
If he can't say that it's easy to measure whether someone is 10x more productive than the average programmer then how can he say they are 10x more effective?
Also I work at 200 person game company and there is no programmer that even performs close to that level. Maybe 2 to 3x the average for absolutely exceptional programmers. But your average would have to be pretty fucking crappy to get anything more than that (and even very talented programmers aren't more than 2x the average).
Productivity in the shortest time scales is hard to measure.
But, when someone spends a few days and makes an optimization that literally prevents well over 1 million dollars of new hardware from being purchased that's real value. (This actually happened.) Create that type of value a few times in 5 years and yes someone can really create 10x the value of the average programmer.
PS: Not a programming example but http://en.wikipedia.org/wiki/Polymerase_chain_reaction is one of the more extreme examples. Kary Mullis literally created billions of dollars of value paying him 10x what the average researcher makes for 40 years and it's still a net win.
Why programmers are not paid in proportion to their productivity? Because they procrastinate the other 50% of the time! (Obviously, it is a joke. But ironically, we're discussing that on HN...)
Or they procrastinate and take it easy because there is an upper limit to compensation per unit of time & effort. If I am truly 10x more productive, that means I should be able to keep a steady paycheck rolling in with 4 hours a week!
Well, my answer to that is the same as the others here. At most of the corporate places where the programmer is treated just like any peon, he/she will just get assigned more work.
The running jokes amongst my peers is that the project manager sees the programmer as a battery. Not far from the truth.
My only advice to fellow programmers who find themselves working in such an environment - quickly get out. Or else you will find yourself sliding into mediocrity and feeling miserable for yourself.
I worked for about 45 minutes today and finished all the work that was assigned to me for today and tomorrow.(I am not a genius,I just used a few modules from github!).
If I work more than that I will not get more money.All I will get is more work and stricter deadlines."You are smart.Why dont you work during the weekend and finish this.We have a demo!" has happened to me numerous times.And everytime I have ended up changing teams!
The best strategy at xyz corp is to pretend that you are slightly dumber than average!
I noticed something similar, though not as a programmer.
I tested videogames one summer, where it was my job to locate and report bugs. It was soon apparent that there was huge variation in productivity: some people submitted more and better bugs, in better written reports, than others.
Most people were hired as independent contractors through an outside company. A select few would be hired by the actual game company, and kept on through the season. Was it the most productive who were kept on? No. It was the people who put in the most overtime hours, and made themselves available when the company asked.
Call me an ignorant youth, but it seemed like, if they wanted to, they could raise salaries, fire the bottom X%, and hire some more talented QA testers, and still come out ahead.
Cook's explanation doesn't really explain this scenario, but I have a feeling the answer is similar, for both the QA tester and the programmer.
My theory: management simply doesn't care, and doesn't need to. If you were to walk out, they could easily get someone else at the exact same pay-grade. It's only when your value to the company is crystal clear, and you are clearly better than the competition, and that there's a viable threat that you will leave somewhere else and actually get better pay, that a company will pay you accordingly.
After all, economics doesn't say you get paid what you're worth. It says you get paid the market clearing wage. You might be creating $200 of value per hour for your employer, but if there are tons of people ready to work for $10 an hour and are just as productive, then you will get paid $10 an hour.
This is more conjecture, but I think for things to change, for people to be paid according to their productivity, two critical pieces of information are essential:
1. Exactly how productive you are, relative to your peers.
2. Exactly how much people of varying abilities make.
The problem is, for #1, the metrics are bad if at all existent. For #2, there's a huge taboo against telling people what you make, which ultimately helps employers keep wages lower.
I think my QA testing situation would have been different if say, the men in charge took some pride in it, and only hired great testers. They didn't, they were just filling slots, so the QA on the QA testers themselves was pretty shoddy.
"Call me an ignorant youth, but it seemed like, if they wanted to, they could raise salaries, fire the bottom X%, and hire some more talented QA testers, and still come out ahead."
Not ignorant at all; this is a very insightful observation. I've seen the same thing from the programming side. Unfortunately, an unskilled programmer can create more and longer-lasting damage than an unskilled QA tester -- some code sticks around for decades and has layers and layers of new code built on top of it. Thus, bad programmers can drag down other programmers' productivity long after they've left the project. So the advantage of replacing a lot of bad programmers with a handful of good ones who are better paid could be even greater.
Not to mention that a smaller group has much less communication overhead than a larger group (as described in The Mythical Man Month).
The other thing I've seen happen is that the more productive programmers are asked to do the more complicated things. So they'd be the ones creating a javascript drag-drop widgets framework while the less capable were stitching together CRUD apps with a bit of business logic in the backend.
This then looks like they're both delivering products, the CRUD app may even earn a lot more money for the business in the short term too.
I've even seen this kind of skill discrepancy in call centres when I temped as a student, this isn't restricted to the programming field. There's always a couple of people who knew how to fix actual problems rather than just enter payment details, they'd always be handed the troublesome clients but rarely got paid more.
I ended up as one of these myself, but none of us ever complained about being paid the same as Bob the lazy call avoider because it made our jobs far more interesting and satisfying.
In the end I guess part of being a high performer is that you know you're going to get the jobs that interest you and that in truth would just frustrate and demoralize your colleagues. It's not always about the pay.