I think a better summary of the article would be, "Cool technology can give you an edge, but doesn't mean anything if you aren't providing profound value to a paying customer."
So often as geeks we look for a problem to solve with the latest technology/language we're fascinated with, rather than looking at our own lives and professional experience and at problems we need solved that might have broad applicability to identifiable, verifiable others regardless of how sexy the guts of that solution are.
Its the classic trap to fall into, and despite all the resources out there telling you not to, more technology startups make this mistake than don't. As geeks, we are drawn to technology, not attuned to market needs. Must learn difference.
Thats how it is for me, anyway, and I think its what the author meant :)
This kind of generalizations aren't entirely correct, because they don't take into account levels of abstractions that exist in our industry.
If you are into OS kernels or compilers, for example, you are at one of the highest levels of abstraction, and you are least dependent of what customers think they might need or are willing to pay. At this level you decide what customers need more often than the other way around.
As opposed to writing a document management system where you are simply enslaved by your customers' immediate needs and of course things like performance or elegance don't matter any more.
(Been in both worlds already. Should I say how much I miss the more abstract world? Sigh.)
I really don't follow this line of thinking. Unless you are independently wealthy you always need someone to pay. If you are working on more abstract levels like kernels or libraries then you just have more technical customers is all. It doesn't matter how many downstream entities could potentially use your abstract product if you don't have someone to pay for it up front. Of course you could just do the open source thing and eventually hope to get sponsorship (eg. Linus), but really that's just another type of sale that is contingent on value you are providing.
I tried to point out areas where performance and elegance still matter and where customers more often don't know what they need, that is, areas where developers are kind of ahead of customers' immediate needs, contrary to the point of the original post. So my comment wasn't really about the business side of things, i.e. who pays, when and how.
I think these generalizations are more or less correct. It's also that at the highest levels of abstraction, your customers are an entirely different set of people with different expectations, and what it means to "pay" is radically different.
Most internet startup wannabes don't realize that "consumer internet" is actually a pretty small little niche which is disproportionally well represented in the media and very vocal/annoying with its self-promoting blogs, rock stars, ninjas and all that childish crap. However, it's only a niche.
There are many more industries where you're selling to other engineers, where technical elegance and performance matters more than you'd think: industrial automation/test, real time data acquisition, finance and banking, aerospace, specialized scientific libraries, specialized compilers (for chips you've never heard of), heavily customized Linux kernels for embedded systems, custom file systems, the list goes on forever. Companies like Sun, Apple, Microsoft, IBM, Texas Instruments, Oracle and even Dell - all of them do a lot of this highly technical, lower level work, often in C/C++ and each of these companies has an ecosystem of startups revolving around them.
Your responses are the best illustration of SV echo-chamber effect. Keep on thinking that becoming an AJAXified CRUD htmlizator of MySQL tables is your only way to make money with a CS degree.
I can barely see out of my pigeonhole, but I'll try to reply anyway :)
Neither I nor the article ever suggested that performance is not important, or that low-level work is not important. The parent gave two examples - language development (almost entirely not a commercial activity anymore), and the development of the Linux kernel (GPL). Neither was supported his point, which was that performance for its own sake is the key in those markets, and I was responding to that with generalities about the 'commodity nature' of those examples.
You're outlining markets where performance is an important feature - to products sold to well defined paying (and massive) customers. Thus you are supporting the article, my summary of it, and disagreeing with parent, even as you lament the 'social media rockstar' phenomenon.
Being able to build something cool is not good enough. Neither is fast performance. Both are important, but the human commitment and real ability to make actual individuals happy at firms that are potential customers is more important than either. Doing what you say you will do--promising delivery dates and consistently meeting or beating them, for example--wins big. Convincing potential customers that you will work ten times as hard as the nearest competitor to please the customers wins sales. Version management, customer support, and documentation quickly become vitally important.
to summarize this article, delivering and committing to your customer/client. common sense business etiquette IMO, but strangely enough — an easy and strong differentiator, so many people fail at this concept.
on the flip side, I'm also known to support the notion of rejecting your customer. there is a good read about it in the book, Mavericks at Work.
To paraphrase Sun Tsu, therefore one hundred successes in one hundred complex projects are not the most skillful, creating lasting and profitable business with little or no effort is the most skillful.
So often as geeks we look for a problem to solve with the latest technology/language we're fascinated with, rather than looking at our own lives and professional experience and at problems we need solved that might have broad applicability to identifiable, verifiable others regardless of how sexy the guts of that solution are.
Its the classic trap to fall into, and despite all the resources out there telling you not to, more technology startups make this mistake than don't. As geeks, we are drawn to technology, not attuned to market needs. Must learn difference.
Thats how it is for me, anyway, and I think its what the author meant :)