No they are not. One would think it's easy to find smart people who can learn new things, but I've dealt with both young and senior developers (by senior I mean writing code 15+ years) and was amazed how most of them feel comfortable being completely ignorant of new technologies/libraries/frameworks/best practices/whatever.

I've met a rockstar the other day, and could feel him being the one I'd hire immediately. It happens once or twice a year for me.

You might not call them rockstars, but in my book, they are.

I don't know how to judge that comment.

It is true that if you take anyone who is competent and ask them to teach you something that they learned in the last year, they should be able to come up with something. If not, then you've likely got "1 year of experience, 15 times". However my experience of people who think that they can judge people in the way you are judging them will judge by asking random questions about random technologies. Which is basically rolling the dice - if the person is exploring the same things that you are, then they get the gold star, otherwise you are convinced that they don't.

Let me give you a concrete example. You ask me what my primary language is. Perl, but right now I'm doing a bit of work in C++. Now you know that I'm a dinosaur because I'm using archaic languages. But don't notice that I have actually programmed in a host of other languages, and at this point learning the latest language is not going to help me be better at what I do. If I need it, I'll learn it then.

You ask me something about promises and jQuery and I draw a blank. I never liked front end work, and I've been working on back end stuff for the last decade. Boom, I'm a dinosaur in your books. But ask me what I'm reading, and you'll find out that I'm working through a book on hierarchical Bayesian modeling. I've also been doing some thinking about how people fail to understand the statistics behind A/B tests, and have been working on a series of articles that a lot of people seem to like.

In short, it is likely that you would quickly judge me poorly. Yet I believe that this reflects more on your judgement than my abilities.

Coders have misconstrued fizzbuzz into a whiteboard pissing contest because they want a binary yes/no interview framework... But that causes them to miss the forest for all the trees.

So at the end of the day, it's not really about experience, it's the attitude.

I only know "Promises" because I saw that on HN recently. However the concept behind JavaScript promises is one that I've seen before (I first saw it buried in a sideways way inside of http://search.cpan.org/~karasik/IO-Lambda/) and the name "promises" already has a spot reserved in my brain for their use in infinite streams. Therefore if someone mentions JavaScript promises to me again in 6 months I'll draw a blank.

There are some code samples linked in the articles in http://elem.com/~btilly/ab-testing-multiple-looks/index.html if you want to look. I wasn't writing that code for anyone except myself, so it isn't particularly pretty. (It did get the job done though.)

They are probably equally amazed that you are not able to discriminate between fads and/or half-assed rehashes of decade-old technologies and actual new technologies.

You should hire someone if they will create more value than it costs to employ them. That's it. It is irrational to do anything otherwise.

So many SV companies seem obsessed with creating islands of purity.

I've spent the last 3 weeks reading documentation around qt 5 in preparation for some 5.1 mobile development I plan on doing, for example.

(In case you thought these issues didn't affect you: http://bugs.python.org/issue13703)

First and foremost, it's fun for anyone interested in engineering to begin with. Second, for programmers, it gives you a tactile experience of programming, and a real respect for what Assembly language really is and what it does, why a compiler is important, how interpreted languages are run differently, and why optimizing your code is important.

You will never know the direct effect that this secondary understanding will have, but the unknowable effects here will be wholly positive, I guarantee it.

I remember one semester in college where it clicked for me... I was taking CS61C, machine structures (basically learning C and how it translates to Assembly) and EE40 (basically learning electronics and how silicon works, and how processors work at an electronic level) and suddenly I understood at least on a basic level how everything worked. The code you type in gets compiled to ASM which gets loaded into memory which the processor loads instruction-by-instruction into registers which are represented by the states of transistors which are loaded each clock cycle by the switching of voltages on a germanium-doped silicon plate which causes the voltage to swing at a certain predictable speed at a given frequency which is controllable and engineered to tolerances which put the whole thing in sync. Holy shit. And each part can be understood in isolation, combined, and it makes sense. It's engineering at its best—break down the problem, understand the tolerances, rinse (with a HF acid wash) and repeat. No single part of it is beyond the realm of understanding, but together they build a system of such complexity, and it's amazing and beautiful that it all works as well as it does.

Knowing this—yes, it makes me think about programming differently.

Because, yes, I'm relatively comfortable not caring about technologies that will return to complete obscurity within 6-18 months.

That seems like a pretty low bar.

I consider it a low bar to have repositories on GitHub or answers on StackOverflow yet the fact is that in London this group numbers in the thousands. This isn't all of the talented people but it gives you an idea of the rarity.

The answer makes that into a complex statement, and if your company can solve that problem, then it has solved a great many problems.

A lot of this coming from being able to expect/plan for future enhancements/changes than the one-off output. My own personal reference with this comes from managing several projects with local and overseas teams with varying degrees of experience.

Exponential effectiveness can only come from improving maintainability, readability and reducing code size. Fact that minimalistic approach also diminishes original development time is only a minor side effect. By the way, a true rockstar developer most of the time reduces code size and improves readability while adding features.

So when you see next time a commit, that adds features and reduces code size, - you know who you are dealing width.

My manager is very similar--his mind works about twice as fast as mine, and he's very productive. He'd never, ever call himself a "rock star" though.