Why programmers are not paid in proportion to their productivity

Good point. Having never seen one of those people I have forgot about their existence when writing this post.

To the point consider this - if you are my employer and you pay me performance bonus, do you have some money left for yourself? I imagine some of the value I generate as an employee gets captured by the company, otherwise they wouldn't keep me around, right? Therefore, self-employment is the only way to keep all the value you have created.

As someone who's been on both sides of the fence, this is untrue. You pay people more or less what is sufficient to keep them happy (within reason). When you're hiring a new employee, you tend to pay them their current salary + some percentage raise. So the biggest determining factor of your salary will be how much you made at your last job.

This does mean that you end up with employees who are clearly superior getting paid less than some of their inferior peers. Certainly when I was a mere employee the idea that I was working harder and better than someone who got paid twice my salary was galling. But there are plenty of employees who aren't as concerned about what their peers are getting paid. Most of the time, assuming your salaries are relatively generous, I've learned that employees feel they are personally being rewarded sufficiently, and that's what matters to them. For those who make it more of an issue, you try to accommodate them if they're worth it.

That said, it is really important to reward superstars to keep them really happy. Often, this means salary / bonuses, but sometimes it means type of work and the role they get to play on the project.

I think it may be more that there are certain mental blocks that can hold you back completely, but once you get over them, your skills improve rapidly. Some people are fortunate enough to start with the "right" way of thinking about those, and so they just sail over the blocks with ease. Others need a mental shift in perspective before they can understand the fundamentals, and so they're "stuck" for a long time with virtually no progress.

I sailed through math and physics and chemistry in high school. I suspect this is because my dad was a nuclear chemist. I didn't have to learn how to think scientifically, because it was ingrained in me from the age of 3, and it never occurred to me to think any other way. But I'm now in my late 20s, and it's the other kids in my high school class, the ones who struggled through everything, that are now finishing their chem Ph.Ds. Because they decided consciously that chemistry was something they wanted to be good at, while I decided my interests lay elsewhere and didn't bother breaking through all the other mental blocks that crop up when you do college-level hard sciences.

I think a lot of skills have this same pattern - hard skills that can take forever to learn, followed by a bunch of easy and flashy tricks that come easily once you master the basics. My violin tone improved markedly and rapidly once I learned to use "arm weight" instead of simply pressing hard on the string. When I was doing whitewater kayaking, the experienced kayakers would say "Once you learn to roll, your skills just shoot up, because you aren't afraid of trying things any more." Last Olympics, there was a video interview with the U.S. women's gymnastics team where they asked each of them "What was the hardest skill to learn?" Shawn Johnson replied, "The hardest skill for me was my kip." (For non gymnastics fans, the kip is basically a prerequisite for all bars moves, and is usually learned around age 7.) There's an Olympic champion, but if you looked at her gymnastics in elementary school, she spent well over a year on a really basic, fundamental skill that some people get in three tries!

I think this may be why a lot of software engineers ask about pointers and recursion as interview questions. Those skills themselves are rarely useful. But they are hard mental blocks that often weed out a lot of prospective programmers. And once you've got them, a bunch of other algorithms and data structures open up for you. If you understand pointers and recursion, you can learn about linked lists, balanced trees, dynamic programming, hashtables, and all those other fundamentals in short order. If you don't, you might forever be stuck using frameworks that other people put together for you.

I used Gnutella too. It was horribly buggy and slow. However, remember that they wrote it in a weekend, and what it was attempting to do really was pretty revolutionary.

Even brilliant programmers can only accomplish so much in a weekend.

If you own the business, why would any rational market participant buy your product or service without expecting it to create more value for them than they paid? Same thing, really.

The issue posed by the original post was that great programmers are not paid proportionally to their output, not whether their employer makes a spread on them.

You're correct though that the closer you get to the money the more value you'll capture. You also take more risk. How many startups have folded where junior engineers made $100k/yr and investors and founders left the endeavor with nothing or a net loss? Depending on your life situation, being more risk-averse and taking the guaranteed paycheck isn't such a bad thing.