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

>>I could have easily been 10x more productive if I didn't have to endure four hour sprint planning meetings

I completely understand this feeling. The problem is so plain and simple. There are teams that win because of heroics, they achieve something big. Those management types who lack the chops to be heroes simply try to turn heroics in a process.

So what they basically do is, watch a team win. Instead of realizing its the interesting/challenging nature of work combined with things like lesser distractions, strong deadlines and well aligned monetary incentives that count, they rater look into common set of patterns that they would do. The net result is they end with a really boring process.

If you think to be successful you have to do X, Y and Z steps you are doing it wrong. X, Y and Z are catalysts, enablers or at most methods to keep you sane while you pursue a higher purpose.

My latest irritation is manager types getting too obsessed with Unit testing, it reminds of XML and the way it was abused.

In my career I've seen developers who were 'average' become way above average after their boss left. This was due to the weird psychological box their manager had managed to get them pinned into.

A friend of mine who is now a VC told me about dogs which were put into a box where anything they did caused the floor to shock them. Eventually they just lay on the floor quivering. This sounds horrible and cruel (and it is) and sadly I've seen managers do the same things to their people. Every time they try to do something they get yelled at, and never with any guidance just a "don't do that again!" sort of shock from the floor. Eventually they can't do anything.

It is hard to rehabilitate those people but it is possible. It takes a bit of patience to get their confidence back up that they can in fact be excellent contributors. But boy is it painful. Both for them and their new manager.

The bottom line for me is that people work at different speeds and different levels. When their tasks are well matched to their strengths they do well. I once characterized two folks I knew as a 'bubble sort' kinda guy and an 'insertion sort' kinda guy. Strangely the bubble sort guy could write code really really quickly, and that was good because he took a long time to arrive at a solid solution. The insertion sort kinda guy worked more slowly and methodically but still got to the solution in about the same amount of time. If you looked at their commit histories you might thing the insertion sort kinda guy was a 1/10th developer but if you look at the milestone delivery rate you'd see he was just as productive as the bubble sort kinda guy. Not a particularly deep insight that people are different I know.

i've noticed the exact same thing. most programmers at the baseline level of proficiency take about the same amount of time to perform any particular, well specified task. its the stuff that isn't well specified where the huge differences come into effect.

First of all the notion that 10x doesn't exist is sorta crap. This may come across as pretty shocking but I don't dedicate every waking moment to development. There is an expectation from many people that being a developer is a 24/7 job and a lot of kids buy into that. If someone spends 10x the effort of me because they honestly feel their career is more important than the rest of their life, then I wouldn't be suprised if they were considerably more productive.

I like to think effort correlates to intelligence and skill but I guess it isn't that simple either. Many people learn certian things, while I choose to focus on others. In the end we may emerge somewhere in the middle but everyone has their strengths and weaknesses. Thus whether you're 10x more productive than me depends on the domain of knowledge which we're utilising.

Folks judge productivity differently. Sadly this often comes from a managment perspective which relates directly to the speed the thing they wanted first appears to them as usable. That's fairly logical from their point of view, but we all know it's folly. Personally I live in a world of duracell bunnies coding up a mess without any thought of security of maintainability. More often than not management tend to believe they're more productive but in reality they just make everyones life harder in the long run.

Finally it comes down to motivation. I'm working a crud app for day rates, I'm in no rush. That's not to say I draw it out longer than it should take but I work my hours at a reasonable pace then I go home. Give me an interesting problem and maybe a vested interesting in completing it and I'll work harder and work on it at home. Suddenly I may be that 10x developer you were talking about afterall, though I'm probably not going to spend my entire life like that.

Personally I think it's pretty silly to propagate the myth that people are useless if they aren't as quick as others. Sure the scale is huge, but the real problem is people aren't rewarded based on their value but based on crappy metrics like "market rates". Next up is even if management were willing to reward based on value, it's actually very difficult for them to do in the vast majority of cases.

This is quite common for mainframe systems, only because many mainframe applications are written in COBOL and that is the file format COBOL prefers.