21 ms·

Why programmers are not paid in proportion to their productivity (2009)

191 points by LionTamer 4y ago

jonnypotty 4y ago
You can't just guess at which 25 percent of your employees not to pay.
deleted 4y ago
[deleted]
cmollis 4y ago
true.. adequate programmers code exactly what you tell them to..and even then it may not be great. Great engineers step back and ask 'why are you asking me to do this?'..(probably silently).. which inevitably leads to a more refined solution, or none at all when they realize you don't actually understand the actual problem, more likely just a symptom of it. Nobody remembers what didn't happen and they certainly don't pay you more for that. This is usually a function of experience, but not necessarily. Productive developers are constantly mapping each development requirement into a larger context of the 'system processes' at large, cross-referencing their (usually deeper) understanding of the technical, business, and political issues involved (all involving some acquisition or expenditure of 'energy' in the general sense). Their productivity is more a function of their understanding of economics writ large, than their recall of algorithms or specific toolsets. It's the main reason senior development is so difficult to hire for..
- simonh 4y ago
  My favourite programmer productivity anecdote: https://www.folklore.org/StoryView.py?story=Negative_2000_Lines_Of_Code.txt https://www.folklore.org/StoryView.py?story=Negative_2000_Li...
- zasdffaa 4y ago
  > Their productivity is more a function of their understanding of economics writ large, than their recall of algorithms or specific toolsets I agree with your post except for that bit. IME it is very much down to a more creative and questioning approach to coding that separates the better from the less good. I don't think, again IME, that asking the question "but should we?" has ever got me that far (though it is a good question) because bad managers take no notice and good managers have already asked it.
  - cmollis 4y ago
    I think what I was trying to say is that the best performers attempt to understand the problem domain more holistically than, say, more average performers. What are the forces driving all of this and how do I deal with those forces in the most efficient way. Obviously, a dramatically more productive engineer also has deep experience is probably many toolsets, languages, etc., and that experience informs many of the decisions that they make when crafting a solution. However, I would argue that they have forgotten many of the picayune details of each, and only retain the most useful conceptual capabilities of those experiences so they can apply them quickly to some new and (seemingly) unrelated problem.
astoilkov 4y ago
I've been thinking about this myself. I'm highly productive and always avoid unnecessary complexity. My most common question is: Can we not do it? However, when I worked for a company I did get bigger promotions but that it was in the 10-20% range. I was literally 2-3 times more productive than people who got paid 30-40% less. If you take a big picture look, you will see things get more obvious when you give it enough time. In 10 years the difference will be big enough (I think).
- fendy3002 4y ago
  If they want and good at working on things I hate (tedious, repetitive work, testing) I don't mind it. . Without them my performance will go down too. I just take it as the company pay them well than they pay me bad. However if I feel that my pay is below market rate, then it's another matter.
gsibble 4y ago
At one company I worked at, after I quit, they had to hire 19 engineers to rebuild the piece of software I built on my own. What took me 9 months took them a year. I quit because they wouldn't give me a raise. Even the CTO recognized to me that I was the most skilled programmer there. I don't think talent is that hard to spot and while I agree measuring programming productivity in a concrete manner is difficult, knowing who's above average isn't hard. Seems more to me that managers just don't want to fork over higher salaries and engineering is looked at as a cost center to be minimized.
- tiffanyh 4y ago
  Unpopular view here ... if it took 19 engineers to rebuild your software - that seems like a failure on your part (not theirs).
  - jraph 4y ago
    Can you develop? It seems to me the need to rewrite the project at all, depending on the reasons, could be the failure, not that it took one year and 19 engineers to do it.
    - fendy3002 4y ago
      Yes, we're lacking context here. Most of the time developers will want to build things from scratch given the opportunity. It's simply easier (from one's opinion) and the time gap may provide with better tooling and frameworks. That applies whether the new lead developer is good or bad. And longer time is not a good indicator too, since previously op may cutting corners to make development faster. However 19 engineers handling one project that can be handled by one person previously is imo, a sign of not optimized work. That is, granted if the scope of work is the same for both.
      - heretogetout 4y ago
        IME it's a sign of one developer doing their best to get a system up and running well enough for business to get by (basically a MVP) and business not providing the staff necessary to improve upon it until it is too late. Maybe it needed 19 engineers all along. At least, that has been my experience in the past.
fefe23 4y ago
BTW: The linked article is from 2009. My experience differs from the article. Where I have been and worked, if someone just copies together stuff they found on stackoverflow, that's not considered productive programming. That's usually a sign of incompetence. Also, pulling in huge frameworks to solve some simple acute problem is also not considered productive programming. It may solve the problem at hand (poorly, usually) but it will create huge future costs for maintaining the dependencies, applying patches, and following changes. In my world, productive programming means solving an actual problem quickly and effectively, and in a way that minimized legacy costs in the following years. The code you leave behind is easy to follow, has few side effects or even none, is not just correct but obviously correct. And where it is not correct, it is easy to fix. You leave behind code that has documentation and good unit test coverage. Code that you needn't worry about. THAT is productive programming in my world. That said, I have personally witnessed 10x productivity differences under these definitions, too. My observation is that poor programmers get stymied by frameworks and environments they hardly grasp, and are either deathly afraid to touch anything or they try something and it breaks in horrendous unanticipated ways so they get paralyzed. A 10x programmer will not be paralyzed by fear but they will approach systematically. First you write unit tests for the existing code, so you understand the problem domain. Then you can start changing things and you'll know if you broke something because your unit tests will fail. Then you can start ripping out chunks of legacy code that is not actually needed anymore or was there to solve some hypothetical future problem that never materialized. To me the most important skill set in programming is time management and following a systematic approach to problems, as opposed to viewing programming as an art form and then feeling the oppressive weight of existing obstacles limiting your free spirit. The measure of good programming is not whether you solve that problem (that is a given) but by how much future headache your solution causes. Leave the world better than you found it.
- chrisweekly 4y ago
  >"To me the most important skill set in programming is time management and following a systematic approach to problems, as opposed to viewing programming as an art form and then feeling the oppressive weight of existing obstacles limiting your free spirit." THIS. Well said.
- 4y ago
ictebres 4y ago
Besides this being an extremely utilitarian way to view of humans that obfuscates inherent value of human beings, it is a general problem with wage labour under capitalism, where only capital earns proportional to its “value”. I think we should focus our energy more on the question how we can provide everyone according to their needs than how utilizable they are, if we want to live in a more healthy and thriving society than we currently do! At the end there is really no need to give some people 10 times more just because they are productive in a certain way. And this calculation already fails as soon as we add more dimension to it, e.g. someone might not be producing 10 times more productive code but maybe they do offer a lot of social skills that make everyone in the team have a better time during work hours.
mensetmanusman 4y ago
It’s because productivity is a function of the environment wherein one is practicing. E.g. if someone really believes they can make 10x more they should quit and start their own company to do that. I’m in an organization where I am considered super productive, but I know that is a quirk of how I interface efficiently with this particular organizational structure. If I was off on my own, I wouldn’t be nearly as productive.
- jpindar 4y ago
  Knowing how to write software is not the same thing as knowing how to market and monetize it.
reedf1 4y ago
The nature of labour and productivity has been understood by classical economists for hundreds of years now. You are not paid in proportion to the excess value you produce, or else you would be an owner of the company.
- cuteboy19 4y ago
  Many programmers are owners in their companies. Unfortunately for them, this is not always a good thing
- nequo 4y ago
  Then what are you paid in proportion to?
  - reedf1 4y ago
    There are entire schools of economic thought about that question. In the classical view, it's your labour power. In the neoclassical view, it's the scarcity of the labour you produce.
    - nequo 4y ago
      I am asking because in a simple model of perfect competition, you are paid your marginal product of labor, i.e., your productivity. Spence's signalling model of education is also based on the idea that people are compensated for their productivity. Even in efficiency-wage models, the equilibrium wage is set at the marginal product of labor.
twawaaay 4y ago
Developer productivity specifically and knowledge work in general is extremely hard to measure. Not only that, it is also very subjective. What is valuable to one person might be a liability to another. Just the other day I looked at results from a developer who spun a huge mess of AWS infrastructure, microservices, lambdas and so on all to solve a very simple problem. He probably congratulated himself for a job well done. So the success of this person would largely depend on the manager he has. For example, how much the manager values simplicity.
- ripper1138 4y ago
  There are certainly managers and directors that would be mesmerized by the architecture diagram in your example, and immediately put that dev up for promo.
  - twawaaay 4y ago
    Of course, and that is the point. How can we pay in proportion to the value a developer is creating if we can't even agree on what is valuable?
avelis 4y ago
> Programmers are most effective when they avoid writing code. They may realize the problem they’re being asked to solve doesn’t need to be solved, that the client doesn’t actually want what they’re asking for. They may know where to find reusable or re-editable code that solves their problem. This snippet is at the heart of it for me. The best analogy I give is a drawing of Pablo Picasso's horse. After many years of understanding your craft, a developer knows how to provide the most value with the least complexity required. It's not because the developer doesn't want to write code. It's more that they understand how to maximize the tools available for the system they work in. Reduction of complexity is better than the addition of it over the long term.
cryptica 4y ago
I'm so glad to see this article on the HN front page. It's spot on and it's what makes coding such a difficult career and why it feels so non-meritocratic. It's happened to me a couple of times that I had to work under the leadership of someone who was far less skilled than me. It's a painful experience and it can take over a year for non-technical directors to figure it out; also, by the time they start to suspect something is wrong, they may have become friends and don't want to admit to themselves that their chief engineer is simply not good. It's easy to say "Well, just quit and join a different company" but this trivializes how incredibly widespread this problem is across all companies including very financially successful ones. They have a huge amount of money; they can throw thousands of engineers at any problem; they don't need to be efficient to stay afloat and they usually aren't... And usually companies which are already earning a lot of money don't care about anything other than merely staying afloat - Everyone is just coasting along thanks to their market monopolies. In my last role, I was presented with what could have been a once-in-a-lifetime opportunity. It could have worked out really well but it worked out terribly because the top engineer was not qualified for the job and neither were the founders. It's not like I can just turn around an find another opportunity like that the next day; it took 10 years and a lot of things had to line up exactly right to get that opportunity. This was the best financial opportunity I had come across in over a decade. I still think it could have worked out very differently. Talent and skills don't attract such financial opportunities in this industry; it's all about luck. It's not even about social connections because people in this industry have an obsession with 'warm introduction' and this creates a huge amount of friction - It's literally impossible to socially network your way to a good opportunity; if you don't try hard enough, you won't get any opportunities. If you try too hard, investors or founders will feel threatened by you - It will make them uncomfortable. This industry is full of sheep; they're terrified to do anything differently than their peers, it doesn't matter how rich they are. They have FU money but they're terrified to say FU. It makes 0 sense to me. For the average person who is or aspires to be above average, the tech industry is a kafkaesque nightmare. You have to be content with being average and rolling the dice. This means you have to content yourself with mediocrity and work on your people skills instead.
fxtentacle 4y ago
"salaries usually fall within a fairly small range in any company" I don't think so? I've heard that some top-tier talent makes $500k annually while most beginners make $50k annually. Isn't that a 10x difference which would be in line with 1x beginners vs. 10x pros?
- NineStarPoint 4y ago
  The important bit is the “in any company.” Generally speaking the 500k developers are going to different companies than the 50k developers. The range at the 500k person’s company is lets say 300k-600k, while the range at the 50k company is lets say 40k-70k. The sorting of skill happens in line with a company’s ability to pay talent.
throwaway0asd 4y ago
https://en.wikipedia.org/wiki/Pareto_principle https://en.wikipedia.org/wiki/Pareto_principle If programmers were paid in proportion to their productivity most (maybe 80%) would starve to death. They would be better off providing data entry for minimum wage. On the other hand, those that are productive (aren't afraid to write original software) would be lavishly rewarded beyond most of our imaginations. Their output doesn't even have to be high quality. This would resoundingly benefit everybody. People doing a job just to put an unqualified body in a seat are an economic drag. Their contributions are often a net negative purely existing to qualify their own existence. For example, does the user actually want 10mb of JS executing for 10 seconds on every page load just to put a few lines of text on the screen? Does the user care that it took a large team of software engineers to pull that off and waste their time without which those software engineers would have to do something else? No, the user won't shed a tear. Yes, there are 10x developers. Yes, most software developers have no idea what a 10x developer is and are absolutely incapable of recognizing one even when working adjacent to one. The only valid question is why the industry tolerates, and even infantilizes, hiring people not qualified to do this work at their own expense. The simple answer, also economically valid, is because it takes them less effort to make a knowingly bad decision than confront the risk of defining what comprises valid selection criteria.
- dayvid 4y ago
  Programming work is also maintenance. You need people around to put out fires or keep things up to date. If you’re only paying based on performance, the high performers will do a big project and immediately leave to somewhere else. The lower performers (at least impact-wise) won’t be there to fix a mess or make incremental upgrades. This approach already happens. This is actually why a lot of software at larger companies aren’t user friendly. There are obvious small bugs or quality of life improvements that could be made for the customer, but it’s hard to tie to measured revenue impact so the SWE team does nothing to fix it.
- jstummbillig 4y ago
  If I understand you correctly (and please, if I don't, do tell) you are advancing that most employees would agree that 80% of their hires are individually a net negative to the company, and they (the employees) know that, and they are okay with that and don't change anything, because facing this predicament (I assume we are in agreement this sounds like a pretty big predicament?) seems daunting. If that is in fact what you think is going on, I think you are most likely insane and I am very interested to hear more.
pimpampum 4y ago
Cause no one is, that would be called participating employees into company's profit.
danbruc 4y ago
Because compensation should be proportional to investment and both the 1X and 10X programmers invest the same thing, eight hours of their time each working day. In practice things are more complicated as this creates undesirable incentives but I think the general point stands.
- coffeeblack 4y ago
  You go ahead and do that, pay your employees based on the hours they are “there“. Your competitor pays its employees based on each employee’s results. Then let’s see which company survives in the market.
  - NineStarPoint 4y ago
    It’s complicated to know, because identifying which of your employees is providing the results is a hard problem. In practice it often devolves into people spending at least as much time marketing themselves to management as they do actually being productive, and optimizes for people who are good at that marketing being in high positions instead of people who are most productive. The larger the company the more pronounced this issue is, which is why so many large companies aren’t kicked out of the market despite their lack of ability/willingness to pay according to results.
    - coffeeblack 4y ago
      That doesn’t matter either. If you have an average employee who complains a lot and he may leave, but that would be a hassle for you, then it makes sense to pay him a bit more so he shuts up and you don’t have to look for a new person. Otoh, if your underpaid star developer sits quietly in his corner and all you have to do is to pat him on the back once in a while to keep him happy, why would you pay him more?
  - danbruc 4y ago
    That is why I mentioned incentives. To make it more precise, assuming everyone works to the best of their abilities, people should be compensated in proportion to the time they work, not the output of their work.
serial_dev 4y ago
> Programmers are most effective when they avoid writing code. They may realize the problem they’re being asked to solve doesn’t need to be solved, that the client doesn’t actually want what they’re asking for. And how do you balance your urge to say "this feature is not what brings us the most value" in a team setting where the business/ product decisions should be evaluated by the product owners? I've only worked with one product owner who actually appreciated the engineers challenging product decisions and was capable of actually changing priorities based on our feedback. He didn't always change his mind, but I know that he was always listening and never made me feel like insubordinate little child. Most business and product people may let you share your thoughts, they smile and nod, and ignore everything you said. Do it a couple of times, you will be labelled as "not a team player". Do you want to know how our similar features performed in the past? You want to challenge whether some SAFe ceremony actually works for your "autonomous" team? You want to recommend hiring an analyst because the whole product flies blind without proper data? Want to take a step back and think about whether a project that takes many man-years to complete is bringing the business or the users any value? Too bad, shut up and code. I had to work too many times on a "super urgent, hundred million dollar feature" and "non-negotiable legal requirements" that still hide behind a feature toggle. In practice, you can figure out in a couple of months whether the person in charge of product vision is capable of listening or not. If they are not, you'll either learn how to keep your skepticism to yourself and do as you are told, or you start looking for a new position (or going solo).
kuharich 4y ago
Past comments: https://news.ycombinator.com/item?id=1012381 https://news.ycombinator.com/item?id=1012381, https://news.ycombinator.com/item?id=2485098 https://news.ycombinator.com/item?id=2485098
jrm4 4y ago
This touches on the very very obvious tension here that I think needs to be understood and stated more clearly: Software, in theory, is frictionlessly infinitely reproducible. We now know that there are quite a few 10x, 100x, 1000x programmers out there, and yet a lot of people still getting paid to write code, which is probably a massive waste of time. I'm not sure how we get to collectively recognizing this inefficiency, but something to try would be "more liability (some liability? like any liability at all?) for bad/harmful software.
e63f67dd-065b 4y ago
I have given the problem of how to correctly compensate according to productivity some thought, and one idea I keep revisiting are auctions. Assuming that you have a fairly good idea of what needs to be done and how to divide it up into reasonable chunks, I could imagine an auction where you just create a list of things and programmers in your company freely bid on them with how much money they’ll be paid for completing each task. The system doesn’t have to be complete. Imagine auctioning off the top x% most urgent bugs to be fixed every sprint, reviewing PRs, etc as extra work. There are some very big flaws with this approach, namely that requirement specifications are basically impossible to get right and review and that incentive structures are not well aligned: - If I bid $5000 to fix a bug, but introduce $10,000 of technical debt into the codebase, then I just made money by externalising the cost. - It makes you compete with your colleagues for buds and that creates a really hostile work environment that probably drastically decreases workout pace efficiency So it’s just been an idea that’s been floating around my head, but maybe an econ grad student can work something out from this.
- simne 4y ago
  Nice try. From history of aviation known, in USSR in 1920s tried to increase productivity of all production in similar way. They accepted ANY suggestion and pay for them average few pennies (for more economy effect paid more money). And said, documents shown thousands suggestions and payments, some people made hundreds suggestions per month, and this was significant increase to their salary. But this lasts only few months, because people for these pennies suggest mostly useless things and in some cases even harmful. For example, in planes construction used oval aluminum tubes, to save weight and to make slightly less air drag. One suggests to use cheap steel round tubes. Aluminum was expensive, so this was extremely economy effective, but plane load decrease about 20% and speed decreased also about 20%, and this was not acceptable.
ac50hz 4y ago
I have found that the most effective programmers are diplomats, they consider consequences and don’t dive into making unconsidered fixes. They understand that the code they write is not only for themselves and that nothing, especially not people, works in isolation. My preference is for clarity and comprehension over breakneck, manic late-night cola-fueled, pizza-box programming sessions. This isn’t The Matrix…
- commandlinefan 4y ago
  > My preference is for clarity and comprehension over breakneck, manic late-night cola-fueled, pizza-box programming Mine, too - but we're not the ones making the decisions and writing the paychecks... and our preference for "good" over "right now" is why we're not the ones making the decisions and writing the paychecks.
deepsquirrelnet 4y ago
There is little semblance of meritocracy, especially in larger companies where salaries are not even determined on an individual basis, but more as a function of years worked and meeting the minimum bar to sustain good yearly ratings. The structure itself is preset, and no matter how effective you are in your role, companies generally recognize that competing for talent has a narrow value range. Companies are hurting for sound product ideas and good business plans more than they are for talented people to implement them. As long as all of their corporate peers are generally in the same boat, turnover is merely a statistic. Talent comes and goes, and you only need to acquire at equal rates to your talent losses. Hiring is just as hit or miss, and article after article here demonstrates that corporate America has given up trying to innovate on that process. If companies could bureaucratically recognize talent internally, then maybe they could hire better candidates. But that’s expensive, and like I said before, the value proposition is limited. If they hire a 10x person, it’s a risky investment anyway, because they’ll leave a 10x hole to fill. It’s just easier to hire 10x people, which has better statistical stability in turnover.
larsrc 4y ago
The most productive programmers are the ones that make other programmers more productive. Making a tool or library or other piece of reusable infrastructure that increases the productivity of 100 engineers by 10% is 10x productivity.
- mring33621 4y ago
  I view helping others as a force multiplier. I prioritize that over my own stuff and have actually been rewarded for it sometimes.
- thunkshift1 4y ago
  Manager spotted
  - Apocryphon 4y ago
    Are there a lot of managers prioritizing internal dev tools and infra over flashy product release announcement bullet point features?
    - justin_oaks 4y ago
      Of course not. They're all skunkworks projects. Just like refactoring has to be. I've developed internal tools that help me a lot and help others too. None of the managers of any of my jobs has ever asked "When did you find time to build that?" I'm sure it's partly because management doesn't have a good idea of how long things take to build. The internal tool could have taken you a week but management probably thinks it took a couple hours.
      - Apocryphon 4y ago
        Then the parent comment makes no sense since the grandparent comment is espousing a view that managers would allegedly not.
kemiller 4y ago
I find a lot of my productivity boils down to knowing what work not to bother with. This can be hard to value.
declnz 4y ago
Oh God, are we still discussing 10x programmers? Please let's not.
- ziddoap 4y ago
  Not just 10x, there's even a 19x programmer in our midst! Seriously though, reading through this thread (and similar ones) is exhausting. Somehow everyone who programs and visits HN is the most efficient/10x/whatever programmer and simultaneously every mid+ manager somehow fell upwards into their current position by pure luck with no knowledge of anything at all.
efficax 4y ago
10x engineers don't exist, or if they do, they are less than .1% of engineers. 2x engineers, sure, 2.5-3x even, but 10x? A fantasy, a pure invention with no data to back it up. Factor that into your analysis.
bufordtwain 4y ago
Here's what I've noticed in my career so far. It's difficult if not impossible to assign an actual concrete value to programmer productivity. This makes it difficult to compare programmers side by side and assign a true value to each of them. Some companies rank developers but it's done subjectively. This fuzziness allows businesses to not pay fairly for extreme productivity (and conversely, forces them to pay too much for crappy productivity). Usually at any company there are one or more 10x programmers who do most of the work and a ton of mediocre developers.
- Supermancho 4y ago
  While I don't agree that it's impossible to assign concrete value, any value suffers from network effects. Gaps in people's skillsets can be made up with someone strong in a gap and another person for another gap and now you have 2 less productive people individually, but they make the group better overall. When you replace 1 guy with 19 (as per another thread), the management is easier as there is less need for focus and more flexibility in hiring/firing, which is worth a lot.
kozikow 4y ago
Sometimes to make a project work you need all types of work, not only high visibility, high impact work that gets management attention and raises. Good example is promo process at a particular large tech company - you win promo by picking a project that is high visiblity, appears difficult, standalone piece with "ownership". Maybe 25% of work that needs to be done meets this criteria. It's hard to get promoted for "product excellence". They tried to do a push a few years ago, when I was there. You won't get promoted for fixing an issue that annoys millions of users or maintaining a succesfull product, unless you really build a case around that with data, case studies, etc. You would spend more than half of your effort on proving that your work is valuable.
- alooPotato 4y ago
  > You would spend half of your effort on proving that your work is valuable. That seems.... reasonable?
- atwood22 4y ago
  If the product was successful even with the bug that annoyed millions of users, then have you really contributed anything by fixing it? Sometimes, the answer is yes, but I think it makes sense to require data to back that up. Similarly, data should be required for new products as well. Like great, you built this new system, but no one used it so you actually just wasted a bunch of time.
- mirceal 4y ago
  That's the tragedy of software development. Nobody wants to do work that isn't super visible (usually in the form of new features). Simplicity and robustness are not appreciated nor rewarded.
Supermancho 4y ago
> Programmers are most effective when they avoid writing code. I understand the sentiment, but there's weak evidence to measure effectiveness by offloading work to others. Not writing code for non-core purposes is not the same as avoiding it. Nor is avoiding policy-mandated code (things like tests and build scripts) making someone more effective, when it's shifting the load to others.
dbrueck 4y ago
The incentive structure for an above average programmer is usually somewhat broken, though stock options can theoretically patch this up some. The way to get maximum return on your above-average output is to go into business for yourself.
hn_throwaway_99 4y ago
I think the other thing that goes on these days is that, for better or for worse, DEI initiatives have flattened pay bands for everyone. I'm not making any comment about whether certain subgroups are over or under paid, but it should be quite obvious that the incentives mean that hiring managers are now terrified of overpaying certain groups and equally terrified of underpaying others. When, as this article points out, outcomes are extremely difficult to measure for any individual programmer, this results in less variation of pay yet still with wide variation in real underlying productivity.
TrackerFF 4y ago
If compensation was simply measured by productivity relative to your co-workers - and let us assume this is not a zero-sum game, and that your compensation independent from company revenue - wouldn't the most proficient and productive programmers seek to work with much less productive co-workers? Simply because they'd come out at the top, and get most compensation. Compare that to joining a "all-star" team, where there's much less variance. You'd get paid less - because the distance between best and worst programmer is much smaller?
globalreset 4y ago
The actual real reason is that most management is just bunch of morons busy optimizing for their own success, and no one worrying about any common sense good of the company. The company downfall is always hiring the first "manager". After that managers will just keep inventing excuses to expand their dominion, until the company is 50% management, there's more people than actual work that needs being done, yet all work grinds to almost complete halt. Even if a given individual is not a self-serving moron, they are overpowered by the dynamics of the group and they either comply and play the game, or they are out. The bigger the group, the easier it is to hide in a corner with incompetence, stupidity, politics, optimize for your personal gain, and the harder it is to actually competently judge the performance and contributions of each member. Hierarchies make people optimize for raising in the hierarchy, and accumulating power, at the expense of actually doing what the group needs. The way human groups organize in practice is pretty much always complete dysfunction without motivated, benevolent and competent leaders at the very top. Our own self-interest combined with natural bias and blind spots in aggregate always win. And the dysfunction grows more than linear with the size of the group. At the corporate size there is practically no actual owner/leader overseeing things (even the board is just bunch of self-serving assholes), so you effectively get a smaller and private replica of a communist state. If you read anything about communist state politics and management you're going to see 1:1 with every corporation you've ever worked in.
- Nextgrid 4y ago
  > most management is just bunch of morons busy optimizing for their own success, and no one worrying about any common sense good of the company That might be true but unless you're the owner of the company or have a significant stake I don't see why you wouldn't do the same as an individual contributor? The "company" is not some sentient being you owe some compassion to. It's a legal structure with profit as its sole goal. It won't shed a tear if it makes more profit at your expense, so you shouldn't either if you manage to turn it upside down.
  - 3a2d29 4y ago
    +1 to this I ageee managers optimize for their own success, at the expense of the company, but how does that make them morons? Sure the company is hurt and work grinds to a halt, but are you saying the rational thing to do is take actions that don’t optimize for your own success?
beepbooptheory 4y ago
I don't understand, how is a company supposed to make money at all if the worker is paid proportionally to their productivity?
- dbrueck 4y ago
  "proportionally to" != "strictly equal to"
einpoklum 4y ago
I am (among other things) a programmer, I absolutely do not management to have yet another string to pull me by, routinely adjusting my pay according to whatever social-engineering game they choose to decide "productivity" by. Plus, for some of my work - it might seem even to a "fair" lay-person that I'm doing practically nothing except wasting my time for a year, then do a year's work in a couple of weeks. At other times, my contribution might be _preventing_ the introduction of poorly-designed or faulty code; so, in a sense, negative productivity...
zackmorris 4y ago
I feel that programming ability rises by roughly an order of magnitude every decade, as one learns more approaches to problem solving. I've been programming over 30 years, so my daily productivity may be something like 1/1000 of what I'd be capable of if I had something like JARVIS in the Iron Man movies. That's a total humblebrag and I'm no Tony Stark, I'm not saying that. Just that I'm concerned that if we view programmer aptitude through the lens of productivity instead of the complexity of problem that can be solved, then programmers will eventually find themselves underemployed. For my mental health, I had to let my ego die and begin to look beyond my personal contribution (which will always pale in comparison to my dreams). I view programmers now as enabling larger groups of people to work and support their families. In a very real sense, we sacrifice our human potential on minutia so that others don't have to. Like how doctors move to small towns to help people instead of landing large salaries at major hospitals. I'm sad that people who win the internet lottery are often spared ego death, so hoard their wealth and never wake up to a greater understanding of how they could pay it forward outside of models built on the profit motive.
simne 4y ago
Because programmer usually is not businessman. That is, first you bet, then you could win, or lose. This is totally different lifestyle and different style of thinking. And that's not all. In reality typical win means, you just got much more than typical bank deposit give. For example bank give 10%, but you got 20%. And this also consider much different knowledge set and skillset, than typical programmer think. For real business much more important than abstract loc, how good you know business (and/or lifestyle) of your client, and how good your code fill his needs. Separate important problem, what people say they need, does not really equals to what they really need. And one also very important part of this puzzle, sometimes you must become salesman and convince your client to buy your solution, which client don't understand, but you sure, it is what he need, and may be more important to you, to what you invested your time and money. And for salesman it is very typical, to have ZERO permanent part of compensation, live only from percents of sales. And to be honest, sales are not 100% depend on salesman skills, but have few peaks on few famous parts of year, and also have huge known decline periods. So, if programmer want to be paid in proportion to his VALUE, he will deal with all things I mentioned. And yes, in many cases, this means, to become much more salesman and much less programmer. To be honest, in usual developed country it's worth it. In developing country, successful programmers paid comparable to big bosses and to media stars.
bennysomething 4y ago
Programmers are paid the market rate for their field, level, geographic area. It's just supply and demand.
- steveBK123 4y ago
  Only on entry to new firm. After that its the lowest raise they can get away with and not lose you.
focusgroup0 4y ago
In short, Programmers are not great Negotiators. Thus, they get "the business" from The Business.
Trias11 4y ago
Because engineering is considered as "liability" while sales are "assets". Investment in more sales gives almost immediate gratification while investment in engineering takes longer and carrying bigger risk. Thus majority of senior execs never like conversation about more investment into engineering
pcurve 4y ago
In most cases, end customers don't eat or use code. Code is a vehicle for delivering value to customers. Developers are not the only one contributing to creation of product. In cases where you 'can' establish direct correlation between more/better code = more margin, then you can flex your leverage.
ppeetteerr 4y ago
Um, they are paid in terms of their productivity. However, it's not how productive they are as a programmer, but how their work translates into business value. While measuring programmer productivity is not trivial, measuring the value of the average programmer on the revenue generated is much easier. For this reason, an average programmer at Facebook will be earning a lot more money than a great programmer at a small regional bank.
lamontcg 4y ago
How do you measure the productivity of someone that can wade into a horribly buggy 10 year old piece of code that has terrible edge conditions and is integrated with other 10 year old pieces of code that you can't break, and you need to work out how to fix it and test it? I often feel like I'm pretty slow in terms of my output, but I generally wade into really tough problems after other devs/teams have flailed at them for weeks and I manage to solve the problem. Does that make me a "10x programmer"? I don't tend to greenfield anywhere near as fast as that so I can't claim to have written some 40,000 line program from scratch in a month. I can write some 100 line patch in 2 weeks that nobody else could come up with though and keep some 10 year old 40,000 line production critical codebase still running.
- justin_oaks 4y ago
  Productivity is hard to define in cases like you've mentioned. If a normal developer is 1x but can't solve a particularly difficult problem, and a million others just like that one can't solve it either, how do we measure the productivity of the better developer who can solve the problem? Are they infinitely more productive?
AzzieElbab 4y ago
no one gets paid on proportion to their productivity. artists do not, actors do not, managers do not, politicians certainly do not. you get paid according to your perceived market value unless you contract per well defined project(not per hr)
SamvitJ 4y ago
"Programmers are most effective when they avoid writing code" is the crux of this article, and stated like a fact. IMO this is not as obvious as the author believes, and needs a solid defense.
mvidal01 4y ago
For some reason this thread makes me think of this Steve Balmer on KLOCs rant. https://www.youtube.com/watch?v=kHI7RTKhlz0 https://www.youtube.com/watch?v=kHI7RTKhlz0
stakkur 4y ago
Because that would be a stupid, factory floor mentality?
kwatsonafter 4y ago
It's because they're milking inventions they didn't invent for salaries that don't reflect their intrinsic value.
- kwatsonafter 4y ago
  If you disagree go talk to Alan Kay or Christina Engelbart.
collyw 4y ago
Define productivity. A previous colleague at my company rushed out a load of new code in 3 months, then left the company. What a steaming pile of crap he left us. After nearly a year and a half we have had our first week without support requests related to this. This guy wrote order of magnitude more code than the others on the team, but we have spent many more hours cleaning up the crap he left.

191 points by LionTamer 4y ago

jonnypotty 4y ago

You can't just guess at which 25 percent of your employees not to pay.

deleted 4y ago

[deleted]

cmollis 4y ago

true.. adequate programmers code exactly what you tell them to..and even then it may not be great. Great engineers step back and ask 'why are you asking me to do this?'..(probably silently).. which inevitably leads to a more refined solution, or none at all when they realize you don't actually understand the actual problem, more likely just a symptom of it. Nobody remembers what didn't happen and they certainly don't pay you more for that. This is usually a function of experience, but not necessarily. Productive developers are constantly mapping each development requirement into a larger context of the 'system processes' at large, cross-referencing their (usually deeper) understanding of the technical, business, and political issues involved (all involving some acquisition or expenditure of 'energy' in the general sense). Their productivity is more a function of their understanding of economics writ large, than their recall of algorithms or specific toolsets. It's the main reason senior development is so difficult to hire for..

simonh 4y ago
My favourite programmer productivity anecdote: https://www.folklore.org/StoryView.py?story=Negative_2000_Lines_Of_Code.txt https://www.folklore.org/StoryView.py?story=Negative_2000_Li...
zasdffaa 4y ago
> Their productivity is more a function of their understanding of economics writ large, than their recall of algorithms or specific toolsets I agree with your post except for that bit. IME it is very much down to a more creative and questioning approach to coding that separates the better from the less good. I don't think, again IME, that asking the question "but should we?" has ever got me that far (though it is a good question) because bad managers take no notice and good managers have already asked it.
- cmollis 4y ago
  I think what I was trying to say is that the best performers attempt to understand the problem domain more holistically than, say, more average performers. What are the forces driving all of this and how do I deal with those forces in the most efficient way. Obviously, a dramatically more productive engineer also has deep experience is probably many toolsets, languages, etc., and that experience informs many of the decisions that they make when crafting a solution. However, I would argue that they have forgotten many of the picayune details of each, and only retain the most useful conceptual capabilities of those experiences so they can apply them quickly to some new and (seemingly) unrelated problem.

astoilkov 4y ago

I've been thinking about this myself. I'm highly productive and always avoid unnecessary complexity. My most common question is: Can we not do it? However, when I worked for a company I did get bigger promotions but that it was in the 10-20% range. I was literally 2-3 times more productive than people who got paid 30-40% less. If you take a big picture look, you will see things get more obvious when you give it enough time. In 10 years the difference will be big enough (I think).

fendy3002 4y ago
If they want and good at working on things I hate (tedious, repetitive work, testing) I don't mind it. . Without them my performance will go down too. I just take it as the company pay them well than they pay me bad. However if I feel that my pay is below market rate, then it's another matter.

gsibble 4y ago

At one company I worked at, after I quit, they had to hire 19 engineers to rebuild the piece of software I built on my own. What took me 9 months took them a year. I quit because they wouldn't give me a raise. Even the CTO recognized to me that I was the most skilled programmer there. I don't think talent is that hard to spot and while I agree measuring programming productivity in a concrete manner is difficult, knowing who's above average isn't hard. Seems more to me that managers just don't want to fork over higher salaries and engineering is looked at as a cost center to be minimized.

tiffanyh 4y ago
Unpopular view here ... if it took 19 engineers to rebuild your software - that seems like a failure on your part (not theirs).
- jraph 4y ago
  Can you develop? It seems to me the need to rewrite the project at all, depending on the reasons, could be the failure, not that it took one year and 19 engineers to do it.
  - fendy3002 4y ago
    Yes, we're lacking context here. Most of the time developers will want to build things from scratch given the opportunity. It's simply easier (from one's opinion) and the time gap may provide with better tooling and frameworks. That applies whether the new lead developer is good or bad. And longer time is not a good indicator too, since previously op may cutting corners to make development faster. However 19 engineers handling one project that can be handled by one person previously is imo, a sign of not optimized work. That is, granted if the scope of work is the same for both.
    - heretogetout 4y ago
      IME it's a sign of one developer doing their best to get a system up and running well enough for business to get by (basically a MVP) and business not providing the staff necessary to improve upon it until it is too late. Maybe it needed 19 engineers all along. At least, that has been my experience in the past.

fefe23 4y ago

BTW: The linked article is from 2009. My experience differs from the article. Where I have been and worked, if someone just copies together stuff they found on stackoverflow, that's not considered productive programming. That's usually a sign of incompetence. Also, pulling in huge frameworks to solve some simple acute problem is also not considered productive programming. It may solve the problem at hand (poorly, usually) but it will create huge future costs for maintaining the dependencies, applying patches, and following changes. In my world, productive programming means solving an actual problem quickly and effectively, and in a way that minimized legacy costs in the following years. The code you leave behind is easy to follow, has few side effects or even none, is not just correct but obviously correct. And where it is not correct, it is easy to fix. You leave behind code that has documentation and good unit test coverage. Code that you needn't worry about. THAT is productive programming in my world. That said, I have personally witnessed 10x productivity differences under these definitions, too. My observation is that poor programmers get stymied by frameworks and environments they hardly grasp, and are either deathly afraid to touch anything or they try something and it breaks in horrendous unanticipated ways so they get paralyzed. A 10x programmer will not be paralyzed by fear but they will approach systematically. First you write unit tests for the existing code, so you understand the problem domain. Then you can start changing things and you'll know if you broke something because your unit tests will fail. Then you can start ripping out chunks of legacy code that is not actually needed anymore or was there to solve some hypothetical future problem that never materialized. To me the most important skill set in programming is time management and following a systematic approach to problems, as opposed to viewing programming as an art form and then feeling the oppressive weight of existing obstacles limiting your free spirit. The measure of good programming is not whether you solve that problem (that is a given) but by how much future headache your solution causes. Leave the world better than you found it.

chrisweekly 4y ago
>"To me the most important skill set in programming is time management and following a systematic approach to problems, as opposed to viewing programming as an art form and then feeling the oppressive weight of existing obstacles limiting your free spirit." THIS. Well said.
4y ago

ictebres 4y ago

Besides this being an extremely utilitarian way to view of humans that obfuscates inherent value of human beings, it is a general problem with wage labour under capitalism, where only capital earns proportional to its “value”. I think we should focus our energy more on the question how we can provide everyone according to their needs than how utilizable they are, if we want to live in a more healthy and thriving society than we currently do! At the end there is really no need to give some people 10 times more just because they are productive in a certain way. And this calculation already fails as soon as we add more dimension to it, e.g. someone might not be producing 10 times more productive code but maybe they do offer a lot of social skills that make everyone in the team have a better time during work hours.

mensetmanusman 4y ago

It’s because productivity is a function of the environment wherein one is practicing. E.g. if someone really believes they can make 10x more they should quit and start their own company to do that. I’m in an organization where I am considered super productive, but I know that is a quirk of how I interface efficiently with this particular organizational structure. If I was off on my own, I wouldn’t be nearly as productive.

jpindar 4y ago
Knowing how to write software is not the same thing as knowing how to market and monetize it.

reedf1 4y ago

The nature of labour and productivity has been understood by classical economists for hundreds of years now. You are not paid in proportion to the excess value you produce, or else you would be an owner of the company.

cuteboy19 4y ago
Many programmers are owners in their companies. Unfortunately for them, this is not always a good thing
nequo 4y ago
Then what are you paid in proportion to?
- reedf1 4y ago
  There are entire schools of economic thought about that question. In the classical view, it's your labour power. In the neoclassical view, it's the scarcity of the labour you produce.
  - nequo 4y ago
    I am asking because in a simple model of perfect competition, you are paid your marginal product of labor, i.e., your productivity. Spence's signalling model of education is also based on the idea that people are compensated for their productivity. Even in efficiency-wage models, the equilibrium wage is set at the marginal product of labor.

twawaaay 4y ago

Developer productivity specifically and knowledge work in general is extremely hard to measure. Not only that, it is also very subjective. What is valuable to one person might be a liability to another. Just the other day I looked at results from a developer who spun a huge mess of AWS infrastructure, microservices, lambdas and so on all to solve a very simple problem. He probably congratulated himself for a job well done. So the success of this person would largely depend on the manager he has. For example, how much the manager values simplicity.

ripper1138 4y ago
There are certainly managers and directors that would be mesmerized by the architecture diagram in your example, and immediately put that dev up for promo.
- twawaaay 4y ago
  Of course, and that is the point. How can we pay in proportion to the value a developer is creating if we can't even agree on what is valuable?

avelis 4y ago

> Programmers are most effective when they avoid writing code. They may realize the problem they’re being asked to solve doesn’t need to be solved, that the client doesn’t actually want what they’re asking for. They may know where to find reusable or re-editable code that solves their problem. This snippet is at the heart of it for me. The best analogy I give is a drawing of Pablo Picasso's horse. After many years of understanding your craft, a developer knows how to provide the most value with the least complexity required. It's not because the developer doesn't want to write code. It's more that they understand how to maximize the tools available for the system they work in. Reduction of complexity is better than the addition of it over the long term.

cryptica 4y ago

I'm so glad to see this article on the HN front page. It's spot on and it's what makes coding such a difficult career and why it feels so non-meritocratic. It's happened to me a couple of times that I had to work under the leadership of someone who was far less skilled than me. It's a painful experience and it can take over a year for non-technical directors to figure it out; also, by the time they start to suspect something is wrong, they may have become friends and don't want to admit to themselves that their chief engineer is simply not good. It's easy to say "Well, just quit and join a different company" but this trivializes how incredibly widespread this problem is across all companies including very financially successful ones. They have a huge amount of money; they can throw thousands of engineers at any problem; they don't need to be efficient to stay afloat and they usually aren't... And usually companies which are already earning a lot of money don't care about anything other than merely staying afloat - Everyone is just coasting along thanks to their market monopolies. In my last role, I was presented with what could have been a once-in-a-lifetime opportunity. It could have worked out really well but it worked out terribly because the top engineer was not qualified for the job and neither were the founders. It's not like I can just turn around an find another opportunity like that the next day; it took 10 years and a lot of things had to line up exactly right to get that opportunity. This was the best financial opportunity I had come across in over a decade. I still think it could have worked out very differently. Talent and skills don't attract such financial opportunities in this industry; it's all about luck. It's not even about social connections because people in this industry have an obsession with 'warm introduction' and this creates a huge amount of friction - It's literally impossible to socially network your way to a good opportunity; if you don't try hard enough, you won't get any opportunities. If you try too hard, investors or founders will feel threatened by you - It will make them uncomfortable. This industry is full of sheep; they're terrified to do anything differently than their peers, it doesn't matter how rich they are. They have FU money but they're terrified to say FU. It makes 0 sense to me. For the average person who is or aspires to be above average, the tech industry is a kafkaesque nightmare. You have to be content with being average and rolling the dice. This means you have to content yourself with mediocrity and work on your people skills instead.

fxtentacle 4y ago

"salaries usually fall within a fairly small range in any company" I don't think so? I've heard that some top-tier talent makes $500k annually while most beginners make $50k annually. Isn't that a 10x difference which would be in line with 1x beginners vs. 10x pros?

NineStarPoint 4y ago
The important bit is the “in any company.” Generally speaking the 500k developers are going to different companies than the 50k developers. The range at the 500k person’s company is lets say 300k-600k, while the range at the 50k company is lets say 40k-70k. The sorting of skill happens in line with a company’s ability to pay talent.

throwaway0asd 4y ago

https://en.wikipedia.org/wiki/Pareto_principle https://en.wikipedia.org/wiki/Pareto_principle If programmers were paid in proportion to their productivity most (maybe 80%) would starve to death. They would be better off providing data entry for minimum wage. On the other hand, those that are productive (aren't afraid to write original software) would be lavishly rewarded beyond most of our imaginations. Their output doesn't even have to be high quality. This would resoundingly benefit everybody. People doing a job just to put an unqualified body in a seat are an economic drag. Their contributions are often a net negative purely existing to qualify their own existence. For example, does the user actually want 10mb of JS executing for 10 seconds on every page load just to put a few lines of text on the screen? Does the user care that it took a large team of software engineers to pull that off and waste their time without which those software engineers would have to do something else? No, the user won't shed a tear. Yes, there are 10x developers. Yes, most software developers have no idea what a 10x developer is and are absolutely incapable of recognizing one even when working adjacent to one. The only valid question is why the industry tolerates, and even infantilizes, hiring people not qualified to do this work at their own expense. The simple answer, also economically valid, is because it takes them less effort to make a knowingly bad decision than confront the risk of defining what comprises valid selection criteria.

dayvid 4y ago
Programming work is also maintenance. You need people around to put out fires or keep things up to date. If you’re only paying based on performance, the high performers will do a big project and immediately leave to somewhere else. The lower performers (at least impact-wise) won’t be there to fix a mess or make incremental upgrades. This approach already happens. This is actually why a lot of software at larger companies aren’t user friendly. There are obvious small bugs or quality of life improvements that could be made for the customer, but it’s hard to tie to measured revenue impact so the SWE team does nothing to fix it.
jstummbillig 4y ago
If I understand you correctly (and please, if I don't, do tell) you are advancing that most employees would agree that 80% of their hires are individually a net negative to the company, and they (the employees) know that, and they are okay with that and don't change anything, because facing this predicament (I assume we are in agreement this sounds like a pretty big predicament?) seems daunting. If that is in fact what you think is going on, I think you are most likely insane and I am very interested to hear more.

pimpampum 4y ago

Cause no one is, that would be called participating employees into company's profit.

danbruc 4y ago

Because compensation should be proportional to investment and both the 1X and 10X programmers invest the same thing, eight hours of their time each working day. In practice things are more complicated as this creates undesirable incentives but I think the general point stands.

coffeeblack 4y ago
You go ahead and do that, pay your employees based on the hours they are “there“. Your competitor pays its employees based on each employee’s results. Then let’s see which company survives in the market.
- NineStarPoint 4y ago
  It’s complicated to know, because identifying which of your employees is providing the results is a hard problem. In practice it often devolves into people spending at least as much time marketing themselves to management as they do actually being productive, and optimizes for people who are good at that marketing being in high positions instead of people who are most productive. The larger the company the more pronounced this issue is, which is why so many large companies aren’t kicked out of the market despite their lack of ability/willingness to pay according to results.
  - coffeeblack 4y ago
    That doesn’t matter either. If you have an average employee who complains a lot and he may leave, but that would be a hassle for you, then it makes sense to pay him a bit more so he shuts up and you don’t have to look for a new person. Otoh, if your underpaid star developer sits quietly in his corner and all you have to do is to pat him on the back once in a while to keep him happy, why would you pay him more?
- danbruc 4y ago
  That is why I mentioned incentives. To make it more precise, assuming everyone works to the best of their abilities, people should be compensated in proportion to the time they work, not the output of their work.

serial_dev 4y ago

> Programmers are most effective when they avoid writing code. They may realize the problem they’re being asked to solve doesn’t need to be solved, that the client doesn’t actually want what they’re asking for. And how do you balance your urge to say "this feature is not what brings us the most value" in a team setting where the business/ product decisions should be evaluated by the product owners? I've only worked with one product owner who actually appreciated the engineers challenging product decisions and was capable of actually changing priorities based on our feedback. He didn't always change his mind, but I know that he was always listening and never made me feel like insubordinate little child. Most business and product people may let you share your thoughts, they smile and nod, and ignore everything you said. Do it a couple of times, you will be labelled as "not a team player". Do you want to know how our similar features performed in the past? You want to challenge whether some SAFe ceremony actually works for your "autonomous" team? You want to recommend hiring an analyst because the whole product flies blind without proper data? Want to take a step back and think about whether a project that takes many man-years to complete is bringing the business or the users any value? Too bad, shut up and code. I had to work too many times on a "super urgent, hundred million dollar feature" and "non-negotiable legal requirements" that still hide behind a feature toggle. In practice, you can figure out in a couple of months whether the person in charge of product vision is capable of listening or not. If they are not, you'll either learn how to keep your skepticism to yourself and do as you are told, or you start looking for a new position (or going solo).

kuharich 4y ago

Past comments: https://news.ycombinator.com/item?id=1012381 https://news.ycombinator.com/item?id=1012381, https://news.ycombinator.com/item?id=2485098 https://news.ycombinator.com/item?id=2485098

jrm4 4y ago

This touches on the very very obvious tension here that I think needs to be understood and stated more clearly: Software, in theory, is frictionlessly infinitely reproducible. We now know that there are quite a few 10x, 100x, 1000x programmers out there, and yet a lot of people still getting paid to write code, which is probably a massive waste of time. I'm not sure how we get to collectively recognizing this inefficiency, but something to try would be "more liability (some liability? like any liability at all?) for bad/harmful software.

e63f67dd-065b 4y ago

I have given the problem of how to correctly compensate according to productivity some thought, and one idea I keep revisiting are auctions. Assuming that you have a fairly good idea of what needs to be done and how to divide it up into reasonable chunks, I could imagine an auction where you just create a list of things and programmers in your company freely bid on them with how much money they’ll be paid for completing each task. The system doesn’t have to be complete. Imagine auctioning off the top x% most urgent bugs to be fixed every sprint, reviewing PRs, etc as extra work. There are some very big flaws with this approach, namely that requirement specifications are basically impossible to get right and review and that incentive structures are not well aligned: - If I bid $5000 to fix a bug, but introduce $10,000 of technical debt into the codebase, then I just made money by externalising the cost. - It makes you compete with your colleagues for buds and that creates a really hostile work environment that probably drastically decreases workout pace efficiency So it’s just been an idea that’s been floating around my head, but maybe an econ grad student can work something out from this.

simne 4y ago
Nice try. From history of aviation known, in USSR in 1920s tried to increase productivity of all production in similar way. They accepted ANY suggestion and pay for them average few pennies (for more economy effect paid more money). And said, documents shown thousands suggestions and payments, some people made hundreds suggestions per month, and this was significant increase to their salary. But this lasts only few months, because people for these pennies suggest mostly useless things and in some cases even harmful. For example, in planes construction used oval aluminum tubes, to save weight and to make slightly less air drag. One suggests to use cheap steel round tubes. Aluminum was expensive, so this was extremely economy effective, but plane load decrease about 20% and speed decreased also about 20%, and this was not acceptable.

ac50hz 4y ago

I have found that the most effective programmers are diplomats, they consider consequences and don’t dive into making unconsidered fixes. They understand that the code they write is not only for themselves and that nothing, especially not people, works in isolation. My preference is for clarity and comprehension over breakneck, manic late-night cola-fueled, pizza-box programming sessions. This isn’t The Matrix…

commandlinefan 4y ago
> My preference is for clarity and comprehension over breakneck, manic late-night cola-fueled, pizza-box programming Mine, too - but we're not the ones making the decisions and writing the paychecks... and our preference for "good" over "right now" is why we're not the ones making the decisions and writing the paychecks.

deepsquirrelnet 4y ago

There is little semblance of meritocracy, especially in larger companies where salaries are not even determined on an individual basis, but more as a function of years worked and meeting the minimum bar to sustain good yearly ratings. The structure itself is preset, and no matter how effective you are in your role, companies generally recognize that competing for talent has a narrow value range. Companies are hurting for sound product ideas and good business plans more than they are for talented people to implement them. As long as all of their corporate peers are generally in the same boat, turnover is merely a statistic. Talent comes and goes, and you only need to acquire at equal rates to your talent losses. Hiring is just as hit or miss, and article after article here demonstrates that corporate America has given up trying to innovate on that process. If companies could bureaucratically recognize talent internally, then maybe they could hire better candidates. But that’s expensive, and like I said before, the value proposition is limited. If they hire a 10x person, it’s a risky investment anyway, because they’ll leave a 10x hole to fill. It’s just easier to hire 10x people, which has better statistical stability in turnover.

larsrc 4y ago

The most productive programmers are the ones that make other programmers more productive. Making a tool or library or other piece of reusable infrastructure that increases the productivity of 100 engineers by 10% is 10x productivity.

mring33621 4y ago
I view helping others as a force multiplier. I prioritize that over my own stuff and have actually been rewarded for it sometimes.
thunkshift1 4y ago
Manager spotted
- Apocryphon 4y ago
  Are there a lot of managers prioritizing internal dev tools and infra over flashy product release announcement bullet point features?
  - justin_oaks 4y ago
    Of course not. They're all skunkworks projects. Just like refactoring has to be. I've developed internal tools that help me a lot and help others too. None of the managers of any of my jobs has ever asked "When did you find time to build that?" I'm sure it's partly because management doesn't have a good idea of how long things take to build. The internal tool could have taken you a week but management probably thinks it took a couple hours.
    - Apocryphon 4y ago
      Then the parent comment makes no sense since the grandparent comment is espousing a view that managers would allegedly not.

kemiller 4y ago

I find a lot of my productivity boils down to knowing what work not to bother with. This can be hard to value.

declnz 4y ago

Oh God, are we still discussing 10x programmers? Please let's not.

ziddoap 4y ago
Not just 10x, there's even a 19x programmer in our midst! Seriously though, reading through this thread (and similar ones) is exhausting. Somehow everyone who programs and visits HN is the most efficient/10x/whatever programmer and simultaneously every mid+ manager somehow fell upwards into their current position by pure luck with no knowledge of anything at all.

efficax 4y ago

10x engineers don't exist, or if they do, they are less than .1% of engineers. 2x engineers, sure, 2.5-3x even, but 10x? A fantasy, a pure invention with no data to back it up. Factor that into your analysis.

bufordtwain 4y ago

Here's what I've noticed in my career so far. It's difficult if not impossible to assign an actual concrete value to programmer productivity. This makes it difficult to compare programmers side by side and assign a true value to each of them. Some companies rank developers but it's done subjectively. This fuzziness allows businesses to not pay fairly for extreme productivity (and conversely, forces them to pay too much for crappy productivity). Usually at any company there are one or more 10x programmers who do most of the work and a ton of mediocre developers.

Supermancho 4y ago
While I don't agree that it's impossible to assign concrete value, any value suffers from network effects. Gaps in people's skillsets can be made up with someone strong in a gap and another person for another gap and now you have 2 less productive people individually, but they make the group better overall. When you replace 1 guy with 19 (as per another thread), the management is easier as there is less need for focus and more flexibility in hiring/firing, which is worth a lot.

kozikow 4y ago

Sometimes to make a project work you need all types of work, not only high visibility, high impact work that gets management attention and raises. Good example is promo process at a particular large tech company - you win promo by picking a project that is high visiblity, appears difficult, standalone piece with "ownership". Maybe 25% of work that needs to be done meets this criteria. It's hard to get promoted for "product excellence". They tried to do a push a few years ago, when I was there. You won't get promoted for fixing an issue that annoys millions of users or maintaining a succesfull product, unless you really build a case around that with data, case studies, etc. You would spend more than half of your effort on proving that your work is valuable.

alooPotato 4y ago
> You would spend half of your effort on proving that your work is valuable. That seems.... reasonable?
atwood22 4y ago
If the product was successful even with the bug that annoyed millions of users, then have you really contributed anything by fixing it? Sometimes, the answer is yes, but I think it makes sense to require data to back that up. Similarly, data should be required for new products as well. Like great, you built this new system, but no one used it so you actually just wasted a bunch of time.
mirceal 4y ago
That's the tragedy of software development. Nobody wants to do work that isn't super visible (usually in the form of new features). Simplicity and robustness are not appreciated nor rewarded.

Supermancho 4y ago

> Programmers are most effective when they avoid writing code. I understand the sentiment, but there's weak evidence to measure effectiveness by offloading work to others. Not writing code for non-core purposes is not the same as avoiding it. Nor is avoiding policy-mandated code (things like tests and build scripts) making someone more effective, when it's shifting the load to others.

dbrueck 4y ago

The incentive structure for an above average programmer is usually somewhat broken, though stock options can theoretically patch this up some. The way to get maximum return on your above-average output is to go into business for yourself.

hn_throwaway_99 4y ago

I think the other thing that goes on these days is that, for better or for worse, DEI initiatives have flattened pay bands for everyone. I'm not making any comment about whether certain subgroups are over or under paid, but it should be quite obvious that the incentives mean that hiring managers are now terrified of overpaying certain groups and equally terrified of underpaying others. When, as this article points out, outcomes are extremely difficult to measure for any individual programmer, this results in less variation of pay yet still with wide variation in real underlying productivity.

TrackerFF 4y ago

If compensation was simply measured by productivity relative to your co-workers - and let us assume this is not a zero-sum game, and that your compensation independent from company revenue - wouldn't the most proficient and productive programmers seek to work with much less productive co-workers? Simply because they'd come out at the top, and get most compensation. Compare that to joining a "all-star" team, where there's much less variance. You'd get paid less - because the distance between best and worst programmer is much smaller?

globalreset 4y ago

The actual real reason is that most management is just bunch of morons busy optimizing for their own success, and no one worrying about any common sense good of the company. The company downfall is always hiring the first "manager". After that managers will just keep inventing excuses to expand their dominion, until the company is 50% management, there's more people than actual work that needs being done, yet all work grinds to almost complete halt. Even if a given individual is not a self-serving moron, they are overpowered by the dynamics of the group and they either comply and play the game, or they are out. The bigger the group, the easier it is to hide in a corner with incompetence, stupidity, politics, optimize for your personal gain, and the harder it is to actually competently judge the performance and contributions of each member. Hierarchies make people optimize for raising in the hierarchy, and accumulating power, at the expense of actually doing what the group needs. The way human groups organize in practice is pretty much always complete dysfunction without motivated, benevolent and competent leaders at the very top. Our own self-interest combined with natural bias and blind spots in aggregate always win. And the dysfunction grows more than linear with the size of the group. At the corporate size there is practically no actual owner/leader overseeing things (even the board is just bunch of self-serving assholes), so you effectively get a smaller and private replica of a communist state. If you read anything about communist state politics and management you're going to see 1:1 with every corporation you've ever worked in.

Nextgrid 4y ago
> most management is just bunch of morons busy optimizing for their own success, and no one worrying about any common sense good of the company That might be true but unless you're the owner of the company or have a significant stake I don't see why you wouldn't do the same as an individual contributor? The "company" is not some sentient being you owe some compassion to. It's a legal structure with profit as its sole goal. It won't shed a tear if it makes more profit at your expense, so you shouldn't either if you manage to turn it upside down.
- 3a2d29 4y ago
  +1 to this I ageee managers optimize for their own success, at the expense of the company, but how does that make them morons? Sure the company is hurt and work grinds to a halt, but are you saying the rational thing to do is take actions that don’t optimize for your own success?

beepbooptheory 4y ago

I don't understand, how is a company supposed to make money at all if the worker is paid proportionally to their productivity?

dbrueck 4y ago
"proportionally to" != "strictly equal to"

einpoklum 4y ago

I am (among other things) a programmer, I absolutely do not management to have yet another string to pull me by, routinely adjusting my pay according to whatever social-engineering game they choose to decide "productivity" by. Plus, for some of my work - it might seem even to a "fair" lay-person that I'm doing practically nothing except wasting my time for a year, then do a year's work in a couple of weeks. At other times, my contribution might be _preventing_ the introduction of poorly-designed or faulty code; so, in a sense, negative productivity...

zackmorris 4y ago

I feel that programming ability rises by roughly an order of magnitude every decade, as one learns more approaches to problem solving. I've been programming over 30 years, so my daily productivity may be something like 1/1000 of what I'd be capable of if I had something like JARVIS in the Iron Man movies. That's a total humblebrag and I'm no Tony Stark, I'm not saying that. Just that I'm concerned that if we view programmer aptitude through the lens of productivity instead of the complexity of problem that can be solved, then programmers will eventually find themselves underemployed. For my mental health, I had to let my ego die and begin to look beyond my personal contribution (which will always pale in comparison to my dreams). I view programmers now as enabling larger groups of people to work and support their families. In a very real sense, we sacrifice our human potential on minutia so that others don't have to. Like how doctors move to small towns to help people instead of landing large salaries at major hospitals. I'm sad that people who win the internet lottery are often spared ego death, so hoard their wealth and never wake up to a greater understanding of how they could pay it forward outside of models built on the profit motive.

simne 4y ago

Because programmer usually is not businessman. That is, first you bet, then you could win, or lose. This is totally different lifestyle and different style of thinking. And that's not all. In reality typical win means, you just got much more than typical bank deposit give. For example bank give 10%, but you got 20%. And this also consider much different knowledge set and skillset, than typical programmer think. For real business much more important than abstract loc, how good you know business (and/or lifestyle) of your client, and how good your code fill his needs. Separate important problem, what people say they need, does not really equals to what they really need. And one also very important part of this puzzle, sometimes you must become salesman and convince your client to buy your solution, which client don't understand, but you sure, it is what he need, and may be more important to you, to what you invested your time and money. And for salesman it is very typical, to have ZERO permanent part of compensation, live only from percents of sales. And to be honest, sales are not 100% depend on salesman skills, but have few peaks on few famous parts of year, and also have huge known decline periods. So, if programmer want to be paid in proportion to his VALUE, he will deal with all things I mentioned. And yes, in many cases, this means, to become much more salesman and much less programmer. To be honest, in usual developed country it's worth it. In developing country, successful programmers paid comparable to big bosses and to media stars.

bennysomething 4y ago

Programmers are paid the market rate for their field, level, geographic area. It's just supply and demand.

steveBK123 4y ago
Only on entry to new firm. After that its the lowest raise they can get away with and not lose you.

focusgroup0 4y ago

In short, Programmers are not great Negotiators. Thus, they get "the business" from The Business.

Trias11 4y ago

Because engineering is considered as "liability" while sales are "assets". Investment in more sales gives almost immediate gratification while investment in engineering takes longer and carrying bigger risk. Thus majority of senior execs never like conversation about more investment into engineering

pcurve 4y ago

In most cases, end customers don't eat or use code. Code is a vehicle for delivering value to customers. Developers are not the only one contributing to creation of product. In cases where you 'can' establish direct correlation between more/better code = more margin, then you can flex your leverage.

ppeetteerr 4y ago

Um, they are paid in terms of their productivity. However, it's not how productive they are as a programmer, but how their work translates into business value. While measuring programmer productivity is not trivial, measuring the value of the average programmer on the revenue generated is much easier. For this reason, an average programmer at Facebook will be earning a lot more money than a great programmer at a small regional bank.

lamontcg 4y ago

How do you measure the productivity of someone that can wade into a horribly buggy 10 year old piece of code that has terrible edge conditions and is integrated with other 10 year old pieces of code that you can't break, and you need to work out how to fix it and test it? I often feel like I'm pretty slow in terms of my output, but I generally wade into really tough problems after other devs/teams have flailed at them for weeks and I manage to solve the problem. Does that make me a "10x programmer"? I don't tend to greenfield anywhere near as fast as that so I can't claim to have written some 40,000 line program from scratch in a month. I can write some 100 line patch in 2 weeks that nobody else could come up with though and keep some 10 year old 40,000 line production critical codebase still running.

justin_oaks 4y ago
Productivity is hard to define in cases like you've mentioned. If a normal developer is 1x but can't solve a particularly difficult problem, and a million others just like that one can't solve it either, how do we measure the productivity of the better developer who can solve the problem? Are they infinitely more productive?

AzzieElbab 4y ago

no one gets paid on proportion to their productivity. artists do not, actors do not, managers do not, politicians certainly do not. you get paid according to your perceived market value unless you contract per well defined project(not per hr)

SamvitJ 4y ago

"Programmers are most effective when they avoid writing code" is the crux of this article, and stated like a fact. IMO this is not as obvious as the author believes, and needs a solid defense.

mvidal01 4y ago

For some reason this thread makes me think of this Steve Balmer on KLOCs rant. https://www.youtube.com/watch?v=kHI7RTKhlz0 https://www.youtube.com/watch?v=kHI7RTKhlz0

stakkur 4y ago

Because that would be a stupid, factory floor mentality?

kwatsonafter 4y ago

It's because they're milking inventions they didn't invent for salaries that don't reflect their intrinsic value.

kwatsonafter 4y ago
If you disagree go talk to Alan Kay or Christina Engelbart.

collyw 4y ago

Define productivity. A previous colleague at my company rushed out a load of new code in 3 months, then left the company. What a steaming pile of crap he left us. After nearly a year and a half we have had our first week without support requests related to this. This guy wrote order of magnitude more code than the others on the team, but we have spent many more hours cleaning up the crap he left.