I think we need to move away from all the nonsense of "A-level engineers" or superstar developers and so and so and so.

Carl Henderson of Flickr fame looked like an A-level engineer back then (especially with his O'reilly book) yet some of the Flickr engineers baffled when they saw the Flickr codebase.

Sometime it's all smoke and marketing hype.

A few years ago I met a 'superstar' type developer who was considered hot shit amongst the usual crowd. I met him with a view of hiring him (or, trying to) mostly because of his reputation.

I think i must have been the first person who really drilled into his knowledge, because he was more interested in talking about who he knew, projects he had been associated with etc.

I got a funny feeling about him, and asked that he do a simple code project. A week overdue later, he asks for our FTP credentials to upload it. I say that we don't run ftp anywhere, and that he needs to scp to the box. He said he had no idea that ssh can 'copy files'. urgh. He later worked out that his GUI FTP client supported SSH and got so excited about it that he messaged me to tell me about it.

I have never judged the capabilities of a developer based on reputation since.

It's kind of hard to judge this superstar developer you mentioned based on his knowledge of some of those UNIX tools.

Josh Bloch admitted himself that he's kind of not really "up"-ing his knowledge/skill when it comes to tools (git, eclipse, intellij, etc) but he writes damn good code with just Emacs.

He knows his Math & Stats to debunk benchmark and stuff like that and he knows the pitfalls of complexity.

ye but the mistake I made was to take his reputation and have a pre-conception about his abilities to the point where I almost didn't test him on anything.

he also fell apart in the code test, which was pretty simple (using a library I had written, which he made a copy of and edited). I have no idea how this guy got his reputation, but it seemed to be more amongst non-tech tech people, if you know what I mean (who are easier to bullshit, I guess)

when I started my career I worked with a bunch of old IBM mainframe guys who had no idea about modern web stuff but were some of the best programmers I have ever met. I could take a problem to them in a language they didn't know (so for eg. VB.NET) and they would talk me through it.

Flickr was a bonafide cultural phenomenon before Yahoo let it die on the vine. That doesn't happen with crappy engineering. Less-than-optimal engineering, yes. That's the tradeoff between getting a product out the door and never delivering.

Netscape's code was pretty crappy too.

I never refer to a perfect utopia where the code is superbly indented, nicely commented, looks great, etc.

But hacks will always be hacks regardless the discussion of "getting product out of the door" vs "never delivering".

agreed. ooh.. a recommendation engine backed by semantic cloud-based peer to peer infrastructure... for all we know, it could just be aggregating data from twitter and seeing whether the word "good" or bad appeared more often to decide whether to aggregate it.

Have you used Hunch? Have you ever written a recommender system? Have you even read the source of one??

This isn't some naive Bayes spam filter from 1992. Hunch is really, really accurate.

Actually yes, I have written a recommender system.But if there's 1 thing I've learned over the years is that you don't go overestimating the complexity/intelligence of any system unless you take a peak underneath. For all you know, Hutch could be just hiring curators with good taste rather than write some complex system that would need to be constantly changed and updated. But people have all the incentive in the world to "over fluff" and overcomplicate their work to make it sound valuable. It's smart, but you gotta be skeptical.

In what universe is starting a company with no clear revenue stream a good thing?