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

These discussions are worse than useless. People with made-up numbers confront people with unreliable anecdotes. Productivity means, very simply, an average of X widgets per hour. Does such a measure even exist for developers? The discussion can apply to such varied situations as:<p>- how fast can a developer add new features to a system they built themselves<p>- how fast can they add features to a system designed by somebody else<p>- how fast do they fix simple bugs<p>- how fast do they find horribly complicated bugs<p>- how fast can they architect a reliable, multithreaded backend<p>- how fast can they work with program management to design a good UI<p>etc. etc. etc.<p>These are often conflicting requirements. People who develop a very elaborate personal coding style will be fast on single projects, but slow to work with other people's code. Those who are methodical and question all assumptions will find hard bugs much sooner, but waste time on simple bugs. Those who can construct elaborate systems in their head often have trouble tweaking hundreds of little CSS details for a single ticket. So I would venture that, for any pair of moderately experienced developers, it's almost always possible to find a pair of tasks such that one of them is twice (or even ten times) as fast as the other. Let's not even bring up how much the incentive structure can vary, even among people in the same department.<p>The example that the article brings is terribly vague and uninstructive. Is that guy, for his whole life, going to be a "1/10 developer"? We never get an idea why he was slow in the first place. Was he lazy? incompetent? concentrating on his studies instead? not motivated by the incentive structure? risk averse because breaking the system carried harsher personal consequences than developing it excruciatingly slowly? The author doesn't even figure out the roots of the problem in the one case he's familiar with, and purports to give advice to everyone else based on it...

For well-defined programming tasks, I could agree that there's a standard "professional" baseline, and that, at most, other developers could be twice as good/fast, at most. (And of course, there are the 1/10 developers too, and even the "negative" developers that do more harm than good.)<p>But the 10x factor is real. But it comes into play, I think, more for architecture roles, or incredibly key algorithms, etc. It's a whole different beast from "proficient developers, who are experienced with their stack and problem domain."<p>These are the developers who have the intelligence, experience, and organizational understand to make the kinds of decisions that keep a team or product running smoothly along, as opposed to getting mired in spaghetti code, rewrites, refactoring, etc. And the larger and more complex projects are, the harder this is, and the more valuable it is. And the more of an art it is, than a science.<p>The idea of 10x developers isn't that a single developer performs simple tasks 10x better/faster, but rather that they bring such insight into complex tasks, that they can wind up achieving 10x as much, possibly for the whole team, because they make other developers more productive as well. Or, they see a well-defined task, and see a different, better way of doing it, that only takes 1/10th the time. But the 10x is the gain they bring to the company -- and sometimes it is far greater than 10x.

I find this a challenging read. If the guy isn't cutting it in the position he is in, then its reasonable to ask him to move on, but I like to believe that everyone <i>can</i> improve, just as I believe not everyone <i>wants</i> to improve.<p>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.<p>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.<p>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.<p>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.

Well, if the author kindof hasn't seen it, I guess I should ignore this stuff:<p>Boehm, Barry W., and Philip N. Papaccio. 1988. "Understanding and Controlling Software Costs." IEEE Transactions on Software Engineering SE-14, no. 10 (October): 1462-77.<p>Boehm, Barry, 1981. Software Engineering Economics, Boston, Mass.: Addison Wesley, 1981.<p>Boehm, Barry, et al, 2000. Software Cost Estimation with Cocomo II, Boston, Mass.: Addison Wesley, 2000.<p>Boehm, Barry W., T. E. Gray, and T. Seewaldt. 1984. "Prototyping Versus Specifying: A Multiproject Experiment." IEEE Transactions on Software Engineering SE-10, no. 3 (May): 290-303. Also in Jones 1986b.<p>Card, David N. 1987. "A Software Technology Evaluation Program." Information and Software Technology 29, no. 6 (July/August): 291-300.<p>Curtis, Bill. 1981. "Substantiating Programmer Variability." Proceedings of the IEEE 69, no. 7: 846.<p>Curtis, Bill, et al. 1986. "Software Psychology: The Need for an Interdisciplinary Program." Proceedings of the IEEE 74, no. 8: 1092-1106.<p>DeMarco, Tom, and Timothy Lister. 1985. "Programmer Performance and the Effects of the Workplace." Proceedings of the 8th International Conference on Software Engineering. Washington, D.C.: IEEE Computer Society Press, 268-72.<p>DeMarco, Tom and Timothy Lister, 1999. Peopleware: Productive Projects and Teams, 2d Ed. New York: Dorset House, 1999.<p>Mills, Harlan D. 1983. Software Productivity. Boston, Mass.: Little, Brown.<p>Sackman, H., W.J. Erikson, and E. E. Grant. 1968. "Exploratory Experimental Studies Comparing Online and Offline Programming Performance." Communications of the ACM 11, no. 1 (January): 3-11.<p>Sheil, B. A. 1981. “The Psychological Study of Programming,” Computing Surveys, Vol. 13. No. 1, March 1981.<p>Valett, J., and F. E. McGarry. 1989. "A Summary of Software Measurement Experiences in the Software Engineering Laboratory." Journal of Systems and Software 9, no. 2 (February): 137-48.<p>(References from <a href="http://www.construx.com/10x_Software_Development/Origins_of_10X_%E2%80%93_How_Valid_is_the_Underlying_Research_/" rel="nofollow">http://www.construx.com/10x_Software_Development/Origins_of_...</a>)

There is no offer of proof for the claim that there are no 10x developers past claiming "they've not seen it in practice"<p>I have seen them with my own eyes. They are in fact, able to do things 10x faster than others. There are not a huge number of them, but they exist. At Google, folks like Jeff Dean and Sanjay Ghemawat are easily 10x more productive than "the baseline proficient engineer". Any proficient engineer who has worked with them can tell you the same.<p>Again, i won't claim there are many of these kinds of folks, but they definitely exist.<p>(This also doesn't mean 1/10th developers don't exist, and aren't common, but ...)

If you ask me to design a programming language, I'm a 0 and van Rossum and Kernighan and Ritchie are some finite number, so they are infinity-x me.<p>There are levels where people hit a wall. Some hit it at hello.c, some hit it at writing professional business logic with proper data structures, some hit it at assembly language or programming language design or operating systems.<p>Anyone in over their head at any level is a 1/10 or a 0.<p>The superstars of language design, if they had to dive into Java business logic, might be at 2x the productivity of a competent pro...or they might shoot themselves.<p>But if you create a Python or Linux...what's your productivity compared to that Java programmer? In terms of the market value of those ecosystems, increased efficiency by the developers and users in those ecosystems, it's not 10x, it's gigantic, millions of times the value-add.<p>The weird thing is, people don't get paid much more when they move from one level to another, unless they start the next Google or get shares/royalties...it's more on a log scale.

There are a small few very gifted people who are prolific coders, and there are a small few very terrible coders who manage to get a job but can't produce decent work.<p>But FAR more often than spotting either category "in the wild", in my own experience, I have watched poor management turn a productive developer into an unproductive one, or watched circumstance and luck turn someone who's not natually great into a central and productive team member.<p>I would say, blanket generalization, that at any company that has more than 5-10 developers, team dynamics and management are 10x more important than whether individual programmers are rock stars or duds.

In my experience there are both. There are certainly a fair number of 1/10ers that manage to progress through seemingly normal career paths as programmers despite not being very good. I've worked with some, and most of you who are also developers probably have as well. But there are also for-real 10xers on top of the baseline. John Carmack, Jeff Dean, Fabrice Bellard, et al. If you define hyper-productive programmers like those guys as your baseline then like 99.9999% of working programmers need to quit in shame.

I'm rather tired of this, "developer productivity," rhetoric. It places software developers on a scale that allows micro-managers to perceive people as cogs in a machine. And I don't think that is fair given that we are all capable people. Each one of us will experience times when we are very productive and deeply inspired while other times we will struggle with completing trivial and meaningless tasks. To put ourselves in such absolute figures is disingenuous.

Of course there are developers that are vastly more productive and effective than others, this is true of every industry, not just developing. Consider two different developers. One designs and implements a highly useful feature which gives their product a key competitive edge in the market and does so in a way which is elegant, efficient, and robust. The other implements a poorly thought out feature that is a borderline bug even if implemented to spec, takes a long time implementing it, and eventually produces code that is hard to understand and full of defects, sucking up tons of developer time and slowing down development velocity as it soaks up resources every time it needs to be fixed.<p>The difference is not merely one of a 10x productivity imbalance, it's a huge effectiveness difference on the scale of thousands or even millions of times.<p>Looking for "10x productivity" developers is a side-show, it's treating software like factory work. Look for developers who can work more <i>effectively</i>. Developers who you can rely on to deliver a product that is absolutely better along every axis than the competition. Developers who won't just pump lines of code into the repo but who will actively work to improve the quality of the code base over time and increase the total development velocity of the company. Developers who will take the time to look at the internal processes and tools that the company uses and seek to improve them when necessary. Developers that will serve as strong mentors to other developers on the team, and improve their quality as well. And too developers who will be looked up to and admired and will serve as a reason for why other developers enjoy working at the company.

Developers is one thing, but how about sysadmin work? I think I've seen it there, too. I looked at the tickets worked by a group of people from June 1 to December 15 of a year far in the past. The counts looked like this:<p>119 348 353 409 515 559 572 634 722 779 830 1004 1029 1169 1345 1487 2096<p>That's a total of 13970 tickets closed by 17 techs. If you split it evenly, that's 821 each, or about 5.8%. The lowest tech only handled 0.85% of the load. The highest tech handled 15%! If you use the extremes, that's a 17x difference. It also means the top tech did almost 2.5x the "fair share" load of 5.8%.<p>Now, to be clear, tickets are not fungible. One ticket may be simple and another might take days to finish. Still, when there's that much of a difference, odds are the person at the top is doing all of them regardless of the complexity. That's the only way to find enough things to do.

All the articles about "10x" developers, "1/10" developers, or "super" developers have not taught me anything about how to improve my skills, or a team's skills. Even the articles that promote the "10,000 hours" or "Just F'ing Do It" mantra feel like proselytizing without practical, or proven, methodologies.

I'm reminded of a paper [1] that "discovered a test which divides programming sheep from non-programming goats." The claim is that there are two distinct populations of people (those who can programming and those who inherently cannot). Each population has its own variance, e.g. as the OP mentions, the best programmer in each population might be 30-40% better than a lower-tier programmer in the same population. But the average programmer in the "can program" population is a magnitude better than the average progammer in the "can't program" population. This seems to closely match what the OP is describing.<p>[1] <a href="http://www.eis.mdx.ac.uk/research/PhDArea/saeed/" rel="nofollow">http://www.eis.mdx.ac.uk/research/PhDArea/saeed/</a>

I think the author was just plain wrong in his decision assigning that transition task to that developer:<p><pre><code> """ They were just in the middle of a transition from a homebrewed framework into a popular open-source one, which I was intimately familiar with. </code></pre> The author should have been transitioning the application to the new PHP framework himself. He is intimately familiar with it (and only it?), after all. And that other guy probably should have been assigned some other task, that he could be efficient at. Or let go.<p>Instead, it looks like this other guy was assigned a task in which he would be very inefficient, and then micromanaged by newly hired CTO. So no surprise that it ended in that huge time waste.

<i>"x10 developers" are, in fact, proficient developers, who are experienced with their stack and problem domain.</i><p>Well, I'd say this is only true for your typical corporate entity, where their products are basically just web applications that represent a state machine using some sort of database store for persistence (which is... basically everything). By the time the company has achieved some size, there's enough process and bureaucracy and projects mostly consist of what the OP described -- migrating from one framework to another, or some other incremental enhancement that's hardly pushing any sort of business of technology threshold. At previous employers that fit this description, I could have easily been 10x more productive if I didn't have to endure four hour sprint planning meetings or be required by an understaffed QA/DBA/sysadmin team to approve my code before release, all to do completely routine development changes that required no serious problem-solving.<p>This doesn't mean I'm a 10x developer. It probably means I'm a 1x developer, so a 'true' 10x developer would have been 100x more productive without the aforementioned bureaucratic crap. At these companies that would dogmatically follow Agile and had two week sprints, I might spend four hours, across two days, actually developing -- with the rest of the days filled with various meetings, interviews, waiting for QA/DBA/sysadmins, fucking around, etc. I could easily see how someone could spend only 15 minutes on what took me four hours, and his solutions would likely be more elegant. It doesn't matter -- the limiting factor isn't the development time, or even the development quality. In that environment, there is literally no difference in productive gains between a proficient developer and a 10x developer.<p>Given a "10x developer" is literally defined by his productivity/quality, if you think they're effectively overhyped/nonexistent, ask yourself this: are you in an environment where a 10x developer could actually demonstrate 10x productivity? At most companies, the answer is no, because a 10x engineer is doing in hours what takes people days, and nobody notices. But in the right environment, the 10x engineer will do in weeks what would take proficient engineers months, or do in months what would take <i>years.</i> They're the people that Steve Yegge calls "Done and Gets Things Smart"[0] or that Rands calls "Free Electrons"[1].<p>And if you work at a company that can't think in terms of months because it's always concerned about quarterly earnings, then they have no use for 10x developer, and chances are you couldn't even tell if one was even there.<p>[0] <a href="http://steve-yegge.blogspot.com/2008/06/done-and-gets-things-smart.html" rel="nofollow">http://steve-yegge.blogspot.com/2008/06/done-and-gets-things...</a><p>[1] <a href="http://www.randsinrepose.com/archives/2005/03/20/free_electron.html" rel="nofollow">http://www.randsinrepose.com/archives/2005/03/20/free_electr...</a>

I think that any model that bifurcates coders based on skill is absurd; but this description was uniquely outrageous. It assumes that skill is binary, and that there is never any room to improve beyond being a competent developer. If the maximum "level" a developer can attain is 1x, than there is no differentiation between competent and amazing coders.<p>In all honesty, these scales and the terminology which makes reference to them are absurd. There are average developers, there are mediocre developers, and there are excellent developers. People operate within a massive range of skill levels and have both talents and shortcomings. Trying to express ability as a binary determination made against an arbitrary baseline simply doesn't work.

I think its important to note that if we didn't have ten fingers and created a decimal numbering system, we probably wouldn't be using the 10x factor

You can't give 10x or 1/10 labels without context. If you ask a smart developer to code in a brand new language, he'll look like a 1/10 developer for a while; and an average developer can look like a 10x developer if he's working with technology that he's been using for the past 10 years.

Because <i>nobody</i> wants to be called or to call himself a 1/10 developer! It's goddamn demeaning!<p>And we're all at different points on the learning curves for different technologies, so we are all "1/10 developers" for some techs! But if you get the "1/10 developer" label for a technology that you end up working with but you've never touched before so you're running in the "learn on the job" mode, some will tend to mindlessly generalize this and you'll end up with a "1/10" label on your head, and <i>you never want that, especially if you're also freelancing or doing independent consulting and your "fame" has financial consequences!</i>. You just label the pro/experienced/uberproductive guys as 10x and leave the others to learn and perfect, it has the same "positive" effect that having a "like" button and not a "dislike" one (or both) has on social networking sites. (Now , having "learn on the job" guys working at 1/10 productivity is <i>horrible</i> for the customer, but this is how it works and how you <i>get paid for learning</i> instead of <i>paying for learning</i> by going to a top notch university and/or crawling through badly paid internships - as wise men said, "paying customers get shafted every now and then", but this is how we keep learning and keep our jobs fun :))

How to tell whether I'm a 1/10x developer or not? Often it took me 3 months just to get a asp.net web application, as I'm unable to cope with the frequent requirement changes.

I guess I don't get it. This Ph.D candidate was recommended by the previous CTO and was the one spearheading the framework transition...and then was fired after 2 weeks? But junior devs at the previous firm were given months to get up to speed?

Not sure what to make of this post.<p>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.<p>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.<p>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.<p>Its worth while to give such candidate some time. Because sooner or later they turn out of be awesome.

Something seems a bit off about that anecdote to me--exaggerated perhaps?<p>There's a "highly recommended", "smart", Ph.D candidate developer and he can't do in 6 weeks what the author could do do in 30 minutes, even with the author holding his hand? That's not a 10x difference, that's a 500x difference.

A lot of this comes down to the company itself.<p>Let's just put it out there. If you are working for a consulting company (let's just name the big ones - Accenture, IBM Global Services, Fujitsu Consulting, etc..) it is NOT in the best interests of the company for their developers to be a "10x developer" or even a "1x developer".<p>Usually these companies have set an expectation on how fast development will go. If its big government projects, icebergs might move at a faster pace than development.<p>Working as an employee or even on contract on some of these projects, you learn pretty quick what the "pace" needs to be. These companies don't make their money by doing the speediest development.

Let's say we redefine the definition of a developer to baseline at what's currently stated as 10x. What if the demand for programming far exceeds the supply of 10x devs? Fact: the above sentence isn't actually a hypothetical, it's the current state of the world.<p>You know what? At the end of the day, it IS harder to teach someone to fish than to fish for them. This is a known fact. This is why developing talent is an investment. You don't just get to reap the rewards from the get go. You invest and hope for a high yield. The person you let go sounded like they had great potential (wrote decent and working code, but just a little slow).<p>Stop being so damn arrogant.

I'd in no way claim I'm a 10x developer. Hell I question whether I am a 1x developer, but it's not really as simple as that.<p>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.<p>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.<p>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.<p>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.<p>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.

I think the problem is that the author has normalized his development standard to proficient coders in the tech industry. I used to do enterprise software in the midwest and there are legions of 1/10th developers out there. Its easy move your baseline far away from the average when you are in the echo-chamber of high-tech startups. Compared to the true average developer there are definitely 10x developers.

I'm not a 10x programmer. Probably will never be. I do know of programmers who not only are slower in shipping, but are very bad at designing coherent programs and data structures. That's my main observation. It's not that I'm X times better, its that they are X times slower and make poor design choices. Why? My experience has shown that this <i>tends</i> to happen with people who stop keeping up to date and stop learning.<p>Let's take my current job, for example. I'm working with a Python program designed to interact with 2 other programs. It is a middleman. The input comes in as text files, and the output goes out as text from a SQL query. The two programmers who built the system I'm working with (one from IBM, another from NASA, believe or not) had never heard of XML, or JSON. Every data structure inside the system is handled by reading and slicing around the contents of the text files. Slow, error prone, and tedious. My first step was to clean this up. I now have a small script that takes the input data text file and turns it into JSON. Since this data comes from an outside vendor, I don't get to pick the format (though I'm developing an API to handle this). After cleaning the data and saving it as JSON, I then simply load up the JSON file into memory and go through the program flow without issues. I removed the size of the program to about 25% of its original size. Plus its way, way faster. I also removed a bunch of database queries that simply did nothing. Was even able to add logging to the program.<p>Anyhow, the crazy part about it is that the actual code was worse. For those who know Python, using global variables for everything is considered pretty bad form. Here is an example that mimics the code base I inherited:<p><pre><code> #they called lists arrays an_array = [] def foo(array): global bar, global hello, global hi if bar &#60;&#62; 1: print "something" array[0] = hi </code></pre> Yeah. But wait, there's more. There is a web app written in (what else) flat PHP. It handles very critical information, and is plagued with:<p><pre><code> $foo = $_GET['foo']; sql = "INSERT INTO TABLE.NAME VALUE($foo)"; //not actual SQL </code></pre> They never clean, or sanitize the data. They don't even check if the GET array is empty.<p>It is obvious these two programmers stopped learning. They simply fell into what I call a <i>learning slump</i>. Where all new data simply goes out the moment it goes in.<p><pre><code> #Like so def new_data(data): return data #Instead of def new_data(data): #process data #insert data into database </code></pre> Yet, I don't want to call myself better, because most people here are better than me. Yet this leaves me with quite a strange view of everything. I'm not a great programmer, but I'm not as bad as those guys who worked at some big name place. Where does that leave me? Who knows.

If you don't have your existing coding team involved in the interview process for new people, then you are looking for trouble. The net cause is either your own poor processes and resource allocation (ie. bad hire) or weird internal procedures/standards (overwhelmingly difficult for newcomers to grapple with).<p>Anyway, '10x your tier of productivity'-style elitism is pointless. People will always either accept new colleagues or get shirty ... there is no objective metric for the infinite range of potential human foibles.<p>That said, removing someone too early could easily prove a loss ... often people who think differently are a 100x asset. If you can influence an important resource allocation decision with interesting information, then saving both a month's time and the potential alternative productivity for a bunch of fellow developers could easily pay for a hire's first few.<p>Software's complex, mmkay. Humans are even worse. Chill, we are all flawed creatures :)<p>&#60;/first-bottle-of-red&#62;

If there are 1/10 developers, there are, in fact 10x developers.<p>Guys, math and stuff.<p>In all seriousness, there's a lot of things being done in the productivity and quality spaces to try and mine data to measure things. I recently joined tenXer (.com) which is trying to both drive productivity measurements as well as quality indicators.<p>We by no means have any answers, but I think things have evolved a lot in the recent years to where bringing real measurements is becoming a possibility.<p>I think the important thing here is to realize that measuring people is not solely for someone to manage you differently. You can't succeed in something if you don't have a reasonable success metric, and data makes it far easier to capture those.

<p><pre><code> [ ] What separates the 10x devs from the 1x? (what _is_ it? Environment, skill, ...) [X] 10x productivity myths (why you shouldn't believe it) [ ] 10x productivity truths (but, but, it IS true, see?) [ ] Be the 10x developer (aspiring to be one) [ ] Startup perspective (should startups try to acquire 10x devs?) [ ] Why the 10x notion pisses me off (why it shouldn't matter) [ ] If 10x productivity why not 10x salary? (or similar) [X] Some meta discussion on the metrics of "productivity" (solve for x) [ ] Technologies/Languages/Tools/Methodologies that facilitate/impede 10x? [ ] 10x in other professions?</code></pre>

From my recruiting experience and from asking around others who do programming during recruiting, there are 30% programmers that can't program even simple problems (FizzBuzz, String reverse)

"but the difference between developers who are proficient at what they do will never be a x10 multiplier - it will be closer to a variation of 30-40% in productivity"<p>If you look at individual productivity you're right, but the effect of the myhthical 10x developer is not just on their own work but on the work of others in the project. You could in some cases get a 10x at the project level. It's the difference between working smarter versus surface level efficiency such as better time management.

Are we to suppose that Fabrice Bellard, Steve Wozniak, and John Carmack are merely proficient developers, who are experienced with their stack and problem domain?

Isn't it obvious that people who use dual monitors, take time to set up projects, one step builds, thonl before coding, think about their work be more productive then who don't. What I feel is productivoty isn't magical which a programmer has, it is driven by how much obsessed the programmer is in increasing it ( too much obsession wont be great though ).

This is interesting, but I feel the author did not get to the meat of the issue yet. He suggest to relabel the 10x to 1x and 1x to 1/10x. Which to me just leads to a discussion about whether the glass is half empty or half full.<p>I think the interesting question is, why is it that 1x is generally regarded as default while 10xers are regarded as special.

"You can tell when someone 'gets' it and when someone doesn't."<p>Can someone explain this in more detail please?

Irrespective of languages (verbose vs non verbose), I have found that the rate at which I code on a normal 8 hour day is 500 LOC of medium complexity code including testing effort - and it has not changed for a long time.

Why can't both be true? If you actually had some objective measure of programmer skill, wouldn't you expect there to be some kind of bell curve of skilled programmers, with 10x and 0.1x people somewhere at the tails?

Having a hard time buying this theory especially given the article's anecdotal evidence. If someone spent 2 weeks trying to program something that took him 30 minutes that is over a 100x improvement.

I think there are 10x developers because the vast majority are 1x.

It doesn't take much time wasted on Twitter, HN, or chatting up co-workers of the opposite sex to turn into a 1/10x developer

What's the difference so long as it remains true that some developers are 10 times better than other developers?

if progress in software dev is limited by bottleneck problems that stop progress or slow it to a crawl, then large multipliers in productivity are possible and limited by the scale of the problem...

Is a 10x developer the same as a "10 star" developer?

so what do i have to do to shift from 1/10 to 1x ?