The hard problems in software are not adding features or coming up with crafty efficient solutions. That is actually quite easy and I am constantly surprised how mediocre to poor developers can consistently come up with workable solutions.
The hard problem in software is writing code others can use. Everyone can write a solution that makes sense to themselves. Few can write one that makes sense to other developers. People who write code professionally will know what I mean. When you get someone else's work and realize it is better than anything you could have come up with. Not because it is extremely complex, but because it is perfectly simple.
I completely agree that people do not think the same. Where you went wrong is in believing an individuals thought process takes precedence over a teams. That is exactly the opposite of what is required and what software development spends a lot of time battling against.
I disagree... the highest-value problems are often VERY hard.
Think of things like natural language recognition, predictive analytics, statistical analysis, and so on. Things that seem like magic to the end user, that they've never seen before, are very hard before they're abstracted into something that B/C players can re-use. Woz, for example, worked some magic and packaged a computer circuit board into something that tons of less-talented people could build on. I would not even want to attempt what he did.
Yes, creating a feature like adding a Like button does not take complex thinking, but moving the needle forward significantly often does. I believe this is what Jobs was alluding to.
I feel like we are discussing this from very different perspectives. You raise hard computer science problems and a Woz example that is hardware related. The article was about software, not people who push the envelope of what is possible with computers.
If you are tackling problems like natural language recognition you don't need a superstar programmer. You need someone with a background in Computational linguistics.
Assuming we are discussing software. Hard computer science problems are, unfortunately, very infrequently brought up in a business setting. The biggest challenge in software is building the right thing. Change is inevitable and solutions are often large. This means you need to have teams of people working together building solutions that are very malleable.
Here is another way to consider it from my perspective. The article is about teams of 'A' players. I am guessing Linus meets your criteria, but you don't hire Linus. You don't have teams of Linus'. Linus is something else...
Absolutely, but also bear in mind Next and Apple worked on some of the hardest problems in the industry. OS kernel design, languages and compilers, development frameworks. Now you can be an ace developer, absolutely A-grade, and be working on a web app in PHP but maybe in that case your leverage over an average dev might be say 10x. Whereas if the problem domain you're working on is something really critical like kernel scheduler design then an A-player might come up with a solution an average dev might never come up with. Not in 100x as long or even 1000x as long.
I don't think he (or steve) is wrong at all: a large part of the 50x comes from the fact that a smart individual can avoid the need for team work.
Although writing software in a way such that others can use it is certainly important, the network effect is the prevalent mechanism at work here (3 programmers need 3 times as much communication as 2 programmers; 4 programmers need 6 times as much communication; etc)
Individuals, or small groups of them, do take precedence because they directly or indirectly make the major decisions. Teams of mostly C's usually don't know where they're going. Whether the team succeeds or not is dependent on if those few thinkers were really A's or just Type A.
The hard problem in software is writing code others can use. Everyone can write a solution that makes sense to themselves. Few can write one that makes sense to other developers. People who write code professionally will know what I mean. When you get someone else's work and realize it is better than anything you could have come up with. Not because it is extremely complex, but because it is perfectly simple.
I completely agree that people do not think the same. Where you went wrong is in believing an individuals thought process takes precedence over a teams. That is exactly the opposite of what is required and what software development spends a lot of time battling against.