"Come be a frankly mediocre programmer writing pedestrian code to solve unimportant problems"?
A job, like any other product, has to be sold. Beer ads don't say "makes you stupid and fat; occasionally ruins lives; it's going to kill some of you; no, really, you will not have beautiful women drape themselves over you, that virtually never to men sitting at home playing Xbox and drinking beer does not make it substantially more likely." For a reason. Similarly, there's the intimation of a cultural/status/etc component to the product offering for working as an engineer at one of these places. (n.b. Not unique to working at them, incidentally. i-bankers, Japanese salarymen, nurses, and PhD candidates in English all get a sales pitch -- in no case is it totally 100% representative of the actual job because, hey, sales pitch.)
They view 99% of web startups as glorified TODO apps with the biggest challenge being playing around doing A/B on front page headlines. Hardly an engineering challenge.
They want to build stuff like Terabite-size de-duplicated storage infrastructure, or embedded devices.
And they are the majority of the brilliant people I know who all started as "programmers" (java/c/c#/etc)
There's much more to actual technical talent when it comes to building software than what you get from year or two of experience, let alone 3 months. Though, in this era when you can actually build usable software products in weeks, if not days(as there have been many interesting "weekend projects" mentioned here in HN) this doesn't matter as much than it did in the past. For example game development has never been as easy it is today, there are thousands if not millions of young people creating games for mobile devices. Some of them succeed in making money but that is most certainly not due to technical talent, as many may easily think.
Back in 90's kids(under 20 yo) literally wrote their own 3D renderers in software because there was no hardware acceleration available. Now 20 years later, how many teens would be able to write their own 3D rendering engine even when using graphics APIs, let alone when doing it all in software? Although the amount of programmers has gone up, I think amount of competence has gone down simply because technical competence is far less needed these days.
These days there's far less need for technical talent when it comes to "building web apps" than what one would've needed say 10 years ago to create a simple client-side desktop program. Yet, now more than ever there's talk about technical talent. Strange.
Simply the barrier of entry is much lower, which in turn reduces the programming talent. I'd be interested to see what the quality of software would be when average 65 yo granny would be reading API documentation of some "web app" because it's just so easy and it just works. :)
I think the difference between "average programmer" 20 years ago and now is the fact that back 20 years ago you had nothing fancy. A text-based editor, command line and a compiler. You were perhaps able to set graphics mode with some obscure commands and get some pixels on the screen. And that was just so fascinating. You really had to me one-in-a-hundred kind of person to be proficient with that stuff. If you put an average programmer of 2012 to such situation, I really bet a huge percentage will just drop the hobby and do something else. Though, on the other hand, things were so simple back then. What does it take these days to have access to the screen pixels as an array? Libraries, frameworks, documentation, APIs and whatnot. Back then you just moved a value to CPU register and called a certain interrupt and voila, 320x200x256 graphics mode with framebuffer starting from a well-known address. Then it's just a matter of writing to memory addresses, very simple. Couldn't be any simpler really!
Just about every startup will tell you they have A-players, rockstars, etc etc - its called marketing.
As basic and important as salting + hashing passwords is, it is the sort of task that ends up on the technical debt list or scrum back-log, never to be looked at until it becomes a problem.
Sure, once they've been on the wrong end of a high-profile identifying information leak, they'll never forget to do it right. But the best of the best? They're building air traffic control systems, or embedded missile guidance, or airbag controllers, or F1 ECUs, or million-simultaneous-call telecoms payment processors, or any one of a thousand other systems where you don't get a second chance to get it right.
1.- How do those companies get the best of the best?
2.- Are you sure it's talent and not process? Where you can't fail, you usually have even the smallest change specified in thousands of pages and reviewed by many people.
2. I think, at it's best, the process is the safety net. At it's worse, it's a substitute for talented people - but I don't think that's sustainable for long. Perhaps it's just a different talent, for working in an extremely tightly controlled way without going crazy.
Here's a few tenative conclusions:
1. The best coders are not necessarily interested in the same things as people who start "Web 2.0" companies.
2. Many of these coders who never get involved with "Web 2.0" and probably never will. (The good news, if you could call it that, is you can still benefit from their skills. They often like to share code freely. They are generous.)
To find the evidence for these conclusion you need to venture off the beaten path. To be receptive to this evidence you have to take respite the herd mentality and buzzconcepts like "Web 2.0".
3. This is the one that's continually obvious and the cause for a blog post on the topic: There are some very sub-par coders heavily involved with things like "Web 2.0". And they are very vocal. Much more so than excellent coders who not involved in things like "Web 2.0".
I'm always open to evidence that counters these conclusions. But the more bad coding I see the more skeptical I get. And it just keeps coming. The bar is set very low. Who cares if some Web 2.0 site is a horrible privacy risk if they can still manage to IPO for a few billion dollars? The best coders care very little, it seems. They are more interested writing smart code than in a multi-billion dollar IPO.
Please, please go into details on this because it is actually a code base that we can all look at and review.
> So is it really the case that these silicon valley/web 2.0 companies have the best developers, or they are just regular companies that have average developers doing stupid things?
Third option: silicon valley has (many) of the best developers, but great developers do stupid things al the time.
I've worked with genius level people in environments varying from Welfare departments to IBM to industrial companies. Their genius is a big deal to steel production or food stamp printing, which are important things, but not sexy & important.
As an anecdote, I once worked on an application where we had to store passwords in plain text, because the password should also be used in a piece of hardware and to provision that hardware, we needed to send the password to said hardware. There's just no good and easy way to solve that and when you're constrained by real world limitations, sometimes you just have to accept a suboptimal solution.
Anyway - Just an anecdote to show that things aren't always that simple.
What they DO have is a lot of energy and creativity. The talented developers usually come in to those companies a little down the road when things start to take off, or are there in the rare case of a veteran founding team.
Security and clean code are not sexy parts of the job, so a lot of startups make them secondary concerns. Young programmers don't understand technical debt because they simply haven't dealt with it, so things start off with a poor structure and need to be refactored down the road.
I think experience does matter though. Even a talented young programmer can get into big trouble by trying to do cute and clever things. They may not have the experience to know that generic database design is generally a really horrible idea, etc.
Most startup engineers couldn't build design and build something like hadoop, but I doubt many database authors would perform well at a startup.
In addition, quick and dirty hacks can be a virtue in a startup (Say leading up to an important product demo). Some engineers have a good sense of what it takes to meet a tough deadline. A language designer does not face that challenge.
In general, wanting to make as much money as you can get is not, per se, evil or immoral.
I'd also say that having the best technical talent is not a prerequisite for building the coolest or most popular stuff. The author assumes it is, which is a major flaw. There are a ton of other factors that leave you with a successful product.
That being said, leaving passwords in plain text is just plain stupid.
I have a feeling the best technical talent still goes to big blue for the "impress mom" rep and R&D, or NSA for the spook factor