Most software that has been or will be written is boring CRUD mixed with specific use case business rules, but that doesn't mean that talent is inapplicable to "technically simple" problems. Even the simplest application can devolve into a mess of complexity. True talent is managing that complexity. That skill has a place in any non-trivial enterprise that uses software, not just those that solve NP-hard problems.
The core problem is that there's little incentive to build complicated, high-effort startups and hire appropriately-skilled people for them because venture capitalists are giving tens of millions of dollars to people who build quick-and-dirty apps that follow trends which will die within a month.
On one hand, absolutely. The current wash of investment means that there's plenty of CRUD startups that get funded that wouldn't otherwise. They'll get acquihired at best and the cycle continues.
On the other hand I don't think that founders will say "Oh, I won't pursue that technical passion project - I'll just build another Twitter!" The incentives to plunge into hard technical problems are not (at their core) based on money. That's just a plus. And lots of investor money means that those with the skills are more likely to found a company instead of letting a side project languish on a hard drive somewhere.
So those who can build amazing things will continue to do so. The current funding environment isn't stopping them. Having more CRUD apps than you can shake a RAM stick at is a small price to pay for enabling the next Stripe or Heroku.
bitcoin doesn't belong on that list, as the primary thing about bitcoin is the database, not the interface.
You could certainly call pinterest, facebook, mint and instagram CRUD apps at their core, though obviously, the CRUD nature is not what makes them special or interesting; but yes, the core facebook app Creates, Reads, Updates (though maybe doesn't delete) from a database; same with twitter and facebook and mint (though, of course, the technically hard part of facebook is getting the equivalent of a tremendously massive join to scale, not writing an app to display the data. Not figuring that problem out, I'm given to understand, is what killed friendster)
Of course, all of those apps, well, it's more about marketing than about the technical stuff. You have to come up with something people want, and coming up with something people want is a very different thing from solving technical problems. Now, of course, if it doesn't work nobody is gonna want it, so you have to have a minimum level of technical competency for your scale; friendster showed that.
But the truth of the matter is that 95% of what you build is stuff that nobody is going to want. And there is no way of knowing ahead of time if you are working on that 95% or on the 5%; So most people build version one cheap. They cut corners. They take on technical debt. Because they only need to build it to work long enough to make it obvious that it's something people want. After it is shown that this is a thing people might actually like, you can dump a bunch of money into rewriting it properly and/or propping up the crap you have.
I mean... look at how much effort facebook has put into... PHP.
The danger here, of course, is demonstrated by friendster. If you have enough interest to make your cheap demo fall over, you need to move fast in propping the goddamn thing up and then hiring some real engineers to build something that can actually scale.
BTC: No, there's an astounding amount of cryptography there. You can build CRUD stuff on top of it.
Mint: (assuming the financial tracker) No, ask anyone who's worked with bank software before - it ain't pretty.
Pinterest/FB/Instagram: Possibly. At the start? Absolutely. What makes those companies valuable is their network effect - everyone you know is already there. Supporting users at that scale takes a lot more than just reading up on the latest APIs. FB invented a (sorta) new language to tackle their scaling problems.
I've seen an alternate anecdote developing, one in which talent is growing weary of delivery, social, and data startups. It appears to result from both a financially stable base (engineers having made money from prev mentioned startups) and a desire to have a larger impact.
Additionally, something I haven't seen mentioned elsewhere, but the API availability is unfathomably vast now. I was checking out Google's developer console and there are over 100 incredibly robust APIs just a GET request away. In the real world, you can order drone images, turn off your lights at home, monitor your health levels all from url endpoints. These computational implementations are encouraging talent to work on projects that are beyond the scope of a laptop and a dorm room.
I for one am optimistic in Valley Talent, and can't wait for the next few years.
I now use a quick test whenever I hear about a new startup: I ask myself what's the "trick" they are proposing. If the trick is sufficiently clever, then I raise the odds of the startup getting initial traction.
Here are a few examples:
1) rent out cars that people leave at airport parking (i.e. flightcar, etc.)
2) group people together for a buying discount (i.e. groupon, etc.)
3) a middleman service that uses middlemen (i.e. magic, etc.)
Most of the hot new startups aren't delivering on a basic need (like food or shelter), but seem to be like one-off computer hacks. And that's not a bad thing. These are smart people bringing out clever solutions that deserve talented valley employees.
The returns that these startups will generate are much more attractive for short-term investors and will have clear advantages over the long-term mentality needed for building a hard new technology.
I think talent, at least in engineering, has very little to do with the success of startups. The "Absolutely" and "Absolutely not" engineers are the same. There are good ones and bad ones everywhere. It's hardly ever the fault of engineers that the company they are working at doesn't make it. Likewise, very few companies make it because of engineering talent.
Talent does not exclusively create success - there's still some elements of luck and market in there. It's still a huge part of success. Look at the absolutely insane amounts of effort companies are putting in to attract talent.
The companies put a lot of effort into finding people who are 1) sufficiently competent and 2) cheap. That's quite a bit different than trying to find the best of the best although it can be plenty hard if you're not willing to pay the market clearing rate.
I think this is in line with what someone once called "fetishizing complexity".
If I work on a project that is complex, I am a good engineer because I solve hard problems. If I work on a simple problem, I'm just another code monkey.
I think a good engineer can take a complex problem and frame it in a simple light. I think a less great engineer can take the same complex problem and come up with a complex solution. From many perspectives, the second engineer is the one innovating.
Note: I'm talking about complexity in a business sense. There are many problems that are mathematically difficult and don't fall under this umbrella.
As an industry, we do a poor job of distinguishing the good engineer coming up with an elegant solution and the lesser engineer coming up with the complex solution to the same problem.
Thinking that the 'talent' necessary to make a successful startup or product is just 'coding talent' is as naive and ill-informed as thinking that the only talent needed to play in the NBA is being tall. Coding is just one of the important aspects of starting a company, there are many others.
Reads like someone who has immersed themselves in the SV bubble for a year or two and now thinks they know it all. Hint: talent is orthogonal to whatever trends are happening in SV (or elsewhere).
>> One common refrain from experienced engineers outside of Silicon Valley is that 'nothing SV cranks out requires any talent'.
This is a common refrain? I'm an experienced engineer about as far outside Silicon Valley as you can get in the U.S., and in more than twenty years I have never heard this sentiment expressed. Perhaps the author needs to make some new acquaintances.
I found this article to be contradicting itself. Correct me if I'm wrong, but if you read code line-by-line, you're just obtaining more knowledge, not talent. How does this suggestion lead to more talent?
Knowledge nurses talent, but it is not in and of itself knowledge. The knowledge of how to solve a problem that has been solved before is incredibly useful, but the real talent in our industry is the talent to solve new problems in new ways, and most people develop that talent but not just looking at how a problem was solved but deconstructing the process of how the designer of that solution came to the conclusion they did.
Randall, I have a suggestion for your site: add the article title as the HTML title, so the tab shows up as "Valley Talent" instead of "Randall Koutnik."
