There are no 10x developers, but there are 1/10 ones

The fizzbuzz syndrome is real alright. But someone failing fizzbuzz is not an indicator that they will always be incapable of development. It just means they are very junior and require training. Frighteningly for the West, Indian and Chinese companies appear to grok this and actually develop their employees. US and UK companies throw their hands up in empty self-satisfaction that their work is so intellectually difficult that people up to the challenge are impossible to find. The reality is probably that the corporate business model is flawed meaning they cannot afford the seniority of guy they need.

I think you're spot on.

There are some _really_ bad programmers out there. Many are stuck in IT departments in non-technical companies, pounding out RPG, COBOL, BASIC, and other "maintenance" work that consists of writing reports. They take weeks doing it. It's a 9-5 job that they don't have to think about when they go home.

I sat in a kickoff meeting with a client's development staff. The staff had an average of eleven years of employment in the department. They were starting to define an SDLC for their organization and the topic of code reviews came up. One of the major points of contention for the day was the use of GOSUB over GOTO. (The pro-GOTO people were talking about a bug that smashed the stack, but didn't know it.)

It's safe to say these people are not reading "Hacker News", even in its current form, at 10pm. They read ESPN.com at work.

Even within this sort of environment, individual effectiveness follows the 1/10 to 10x distribution. There are developers who change one line of code, with a clear specification, and take entire facilities out of production for days. Others get in at 7am, leave at 7pm, and work on ripping out as much code as possible to create reusable modules of...BASIC. Most plod along in the middle.

For those who work inside Google, it's well worth it to look at Jeff & Sanjay's commit history and code review dashboard. They aren't actually all that much more productive in terms of code written than a decent SWE3 who knows his codebase.

The reason they have a reputation as rockstars is that they can apply this productivity to things that really matter; they're able to pick out the really important parts of the problem and then focus their efforts there, so that the end result ends up being much more impactful than what the SWE3 wrote. The SWE3 may spend his time writing a bunch of unit tests that catch bugs that wouldn't really have happened anyway, or migrating from one system to another that isn't really a large improvement, or going down an architectural dead end that'll just have to be rewritten later. Jeff or Sanjay (or any of the other folks operating at that level) will spend their time running a proposed API by clients to ensure it meets their needs, or measuring the performance of subsystems so they fully understand their building blocks, or mentally simulating the operation of the system before building it so they rapidly test out alternatives. They don't actually write more code than a junior developer (oftentimes, they write less), but the code they do write gives them more information, which makes them ensure that they write the right code.

I feel like this point needs to be stressed a whole lot more than it is, as there's a whole mythology that's grown up around 10x developers that's not all that helpful. In particular, people need to realize that these developers rapidly become 1x developers (or worse) if you don't let them make their own architectural choices - the reason they're excellent in the first place is because they know how to determine if certain work is going to be useless and avoid doing it in the first place. If you dictate that they do it anyway, they're going to be just as slow as any other developer.

Not sure what to make of this post.

I'm a 10x guy when it comes to Java/Python/Perl. And I'm also 1/5 guy when it comes to something like a executing a large C project[Which I'm currently working on in my spare time in the nights, totally apart from my day job]. Actually I was 1/10 guy a while back. I'm now at 1/5. I give it another 6 months while I be the 1x guy. And it will take some years when I will hit 10x mark when it comes to C.

However this 1/10, 1 or 10x metric is bull crap. There a lot of people who work slowly and steadily and then come to speed. There are a lot of people who learn by making mistakes, there are people people who take time figure out things and go at their own speed.

My metric of measuring is how to check how much committed the person is, are they deeply into it, are they serious about it, how much effort do they put in. To they persist on their effort despite problems? If they do, you have a winner. Doesn't matter if he can't understand the C syntax or takes a while.

Its worth while to give such candidate some time. Because sooner or later they turn out of be awesome.

> Agile is the current day water fall model. I mean in spirit on in factual procedures.

I think the problem is people sticking to a particular process, thinking it's the definition of "Agile". Rather than responding to change and the individuals in the team.

As our team was growing to the point where planning sessions were taking several hours we switched to just in time planning. A couple of developers could give a lightweight estimate of work at any point. Planning became just a 30min discussion with stakeholders to prioritise work, and we'd dig into implementation details as a team when we actually started working on something.

This would obviously not work for everyone. My point is that we responded to the problem and adapted our process to change in the team and environment. It's the 4th point on the agile manifesto http://agilemanifesto.org/

Retrospectives should give an opportunity for teams to do this if done right.