I used to scoff at the idea of the super-developer who is orders of magnitude more productive than anyone else. Mostly it was me protecting my own self-esteem.
Then I met one and actually had to re-assess my ability as a developer, not just as to how good I am now but how good I'm _ever going to be_. I've now come to terms with my fate.
While I will put a lot of hard work into being as technically thorough, well-read and well-practiced as I possibly can, I no longer compare myself to these ultra-productive developers who can walk into a dev team and pick up more domain knowledge than I did in a year in a couple of months.
The other thing is that the "100x" number isn't really applicable. Yes, your super-developer that you met may do the same task 5x faster than somebody else, but the real thing that sets him or her apart and makes them valuable is the set of things that they can do that a mediocre or inexperienced developer simply can't do, at all. It's hard to use the "times better" metric to measure that.
And when you look at it that way, I think it's easier to "see" the super developers out there. There's a lot of people who are faster, but still mediocre. While I can put that to good use, I don't think it's the same thing.
You might surprise yourself. It isn't necessarily all about speed. Continuous deliberative practice can take you a long way. You may never bash out code at warp speed, but you might find you can still step up into the "doing things few other people can even do at all" domain.
> but the real thing that sets him or her apart and makes them valuable is the set of things that they can do that a mediocre or inexperienced developer simply can't do, at all
What are the sort of things that a great developer can do that a mediocre developer simply can't? (Not sarcasm. Just curious)
Take a piece of technology like memcached which has gotten really popular in the last few years. It's an incredibly simple piece of technology really, a server with a simple protocol that allows you to set or get bytearrays by a key, and smart clients that deterministically map a key to a server. Together, you get a lineraly scaling global cache.
I've worked with web technologies for 15 years now, and I've worked with some pretty smart developers, but not smart enough to piece something like memcached together. We've done lots of different cache systems, but not as good.
But once we saw memcached, the great developers I worked with instantly got the brilliance of it, and went "Duh, why didn't I think of that?".
These aren't all equally difficult, but if anybody at work proposed putting a fresh-out-of-college employee on them, I'd scream in terror:
Design a complicated system, mostly correctly, in their head, and create a plan for getting to MVP as quickly as possible, and incrementally advancing to the complete system without ever having to really rip anything out (unless it was part of the plan). You can imagine how this is valuable to a business. It also takes a lot of experience, because even if you can mouth mantras like DRY and "separation of concerns" there's a lot of room left to screw up in exactly how you separate concerns. (And many developers aren't even familiar with those terms.)
Design a non-trivial web site with various user roles, which is actually secure even if you fully control the incoming HTTP requests from top to bottom. Sounds easy. Evidence suggests that the skills to pull this off are not found in every developer, though.
Correctly program a concurrent program with a significant UI, using only the tools readily available in traditional UI environments like Windows or Java. (It shouldn't be rocket science and I believe someday it won't be. But it is today. Arguably, this isn't even something a master developer can do, it's just something it takes a master developer to even come close to getting away with.) Think something like being someone who writes the game engines, like the Unreal engine. There's a kernel down in the core of the engine that you can throw as many mediocre developers at as you like, it will never work.
There's even things like "knowing which paradigm to apply to which part of the problem" which groking knowing several paradigms in the first place. A programmer who has never heard of "logic programming" isn't going to recognize an opportunity to literally replace tens of thousands of terrible lines of code with hundreds of good ones. A programmer who doesn't understand compilers or interpreters isn't going to recognize the place where they can provide a DSL to a user and save unbounded amounts of lower-level code. A programmer who has only gone to school and has no outside experience isn't going to know that memcached even exists, let alone that it is wildly better than anything they could possibly write.
If it sounds like some of these things aren't that rare, well, I'm mostly not trying to describe things that only the top 0.01% of developers could do. I'm looking more in the top 25%-ish on most of these, maybe top 5% at best. But there's definitely a bottom 50% that these things are out of the question. (Many of them, of course, will grow and move up, everyone starts a bottom-1% developer.)
Then I met one and actually had to re-assess my ability as a developer, not just as to how good I am now but how good I'm _ever going to be_. I've now come to terms with my fate.
While I will put a lot of hard work into being as technically thorough, well-read and well-practiced as I possibly can, I no longer compare myself to these ultra-productive developers who can walk into a dev team and pick up more domain knowledge than I did in a year in a couple of months.