4 ms·

https://en.wikipedia.org/wiki/Pareto_principle https://en.wikipedia.org/wiki/Pareto_principle If programmers were paid in proportion to their productivity most

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.
- stagger87 4y ago
  Not only that, he seems to be OK with these 80% making <= minimum wage. Fun!
anothernewdude 4y ago
The same is true of businesses. There are plenty that make money while being unproductive and selling subpar software.
myownpetard 4y ago
The 10mb of JS is an interesting but misplaced example. There are situations where it's worth the effort to write something with a smaller footprint from scratch but it always comes down to individual incentives. Will it ship faster if we just import this overpowered library? Will additional bloat to our webapp effect the bottom line in any discernible way? The answer to those questions is so frequently yes and no respectively that the emergent result is what you see in your browser's network tab. The user won't shed a tear if it's removed, but they won't leave and spend their money elsewhere in all but the most pathological cases. I think the state of webdev is the result of a common and general problem, micro optimal decisions result in frustrating macro structural issues. But then again if you've found cases where you can build a business off of serving users 10 fewer mb of JS than a competitor, more power to you. Be the change.
- throwaway0asd 4y ago
  > But then again if you've found cases where you can build a business off of serving users 10 fewer mb of JS than a competitor, more power to you. Be the change. That depends upon the product. If the primary revenue engine is advertising the product is the end user, not the software. As such, track the shit out of them. If the revenue engine is something else or the goal is merely disruption then, more than likely, the product is the application. The primary driver empowering retention is don't give your users a compelling reason to consider the competition.
ausbah 4y ago
what does citing the pareto principle here even mean? say 80% of programmers are "unproductive" isn't even what the principle even states. a generous interpretation in line with the line of though you've presented would be that 80% of programmers contribute 20% of overall productivity. this perhaps isn't wrong, but defining "unproductivity" from the assumed contribution proportions of an entire industry would require even more heinous assumptions that a any single developer isn't able to do perhaps you're more productive than your fellow co-workers, congratulations, but extrapolating your programming skills into economic commentary or hiring is a bit egregious

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.

stagger87 4y ago
Not only that, he seems to be OK with these 80% making <= minimum wage. Fun!

anothernewdude 4y ago

The same is true of businesses. There are plenty that make money while being unproductive and selling subpar software.

myownpetard 4y ago

The 10mb of JS is an interesting but misplaced example. There are situations where it's worth the effort to write something with a smaller footprint from scratch but it always comes down to individual incentives. Will it ship faster if we just import this overpowered library? Will additional bloat to our webapp effect the bottom line in any discernible way? The answer to those questions is so frequently yes and no respectively that the emergent result is what you see in your browser's network tab. The user won't shed a tear if it's removed, but they won't leave and spend their money elsewhere in all but the most pathological cases. I think the state of webdev is the result of a common and general problem, micro optimal decisions result in frustrating macro structural issues. But then again if you've found cases where you can build a business off of serving users 10 fewer mb of JS than a competitor, more power to you. Be the change.

throwaway0asd 4y ago
> But then again if you've found cases where you can build a business off of serving users 10 fewer mb of JS than a competitor, more power to you. Be the change. That depends upon the product. If the primary revenue engine is advertising the product is the end user, not the software. As such, track the shit out of them. If the revenue engine is something else or the goal is merely disruption then, more than likely, the product is the application. The primary driver empowering retention is don't give your users a compelling reason to consider the competition.

ausbah 4y ago

what does citing the pareto principle here even mean? say 80% of programmers are "unproductive" isn't even what the principle even states. a generous interpretation in line with the line of though you've presented would be that 80% of programmers contribute 20% of overall productivity. this perhaps isn't wrong, but defining "unproductivity" from the assumed contribution proportions of an entire industry would require even more heinous assumptions that a any single developer isn't able to do perhaps you're more productive than your fellow co-workers, congratulations, but extrapolating your programming skills into economic commentary or hiring is a bit egregious