There has always been a huge range of productivity and quality amongst programmers, and in the old days was estimated at a 20:1 range. In the field of the Arts there is more than 1000:1 range in skill; in fact, it is impractical to compare skill in the arts as it is subjective, but at an objective level there are obvious signs of superhuman capabilities, especially in music composition (which is a different kind of “programming”). Take for example Donizetti’s composition of “Don Pasquale” in around two weeks which is like writing 50,000 lines of code in 2 weeks, an incredible feat one of the greatest artistic achievements of all time. So 10x for programming doesn’t sound unreasonable at all.
An environment where peace and quiet are available is very important for productivity, but putting a lousy programmer in a quiet environment still won't fix their code. Having studied a lot of code, i have determined that great programmers all use the same fundamental technique. The purposed of this technique is to generate fewer errors during authoring and a more regular code structure that also makes it faster to write as the code follows a more regular pattern. Keep in mind that approximately 85% of your time as a programmer is spent fixing your own mistakes. If you learn to write in a way that has near zero errors, you will be 8x faster that you were before, so that is well on your way to 10x.
This technique is not taught in school or even in books. The technique can be roughly described as "complexity reduction". As N. Wirth pointed out in his famous book "Algorithms + Data structures = Programming", all programs break down into these two parts: Algorithms and Data Structures. The fundamental algorithms of most commercial programming tasks are pretty simple. 99% of us programmers are not building vision systems or trying to translate from english to other languages... most of us have pretty simple algorithms to follow, like “sort this table of sales results in descending order and take the top 10”. Also, most of the data structures we use are often fairly simple, like a table of transactions for the month. So given that the majority of business programming tasks have simple data structures and simple algorithms all the programs should be more or less identical when you remove the skin. Programmers build a bridge from the customer problem space to the final API of the operating system or environment that is being used. Some programmers construct a bridge that goes nearly straight between these two endpoints, and others create a more wandering path.
The best programmers minimize the number of variables, the number of layers, and through a gradual reduction process create less code, that is clearer and cleaner in purpose. This reduction process is fairly mechanical, and all the best programmers instinctively do it, while bad programmers don't see the reduction process. In the old days of circuit design, you would use Karnaugh maps to reduce the number of gates to express a truth table, the best programmers are doing the same exact kind of thing in their head to minimize the total amount of logic and layers.
Could we improve the skill of programmers? Can this be taught? Absolutely. But in order to learn you have to be willing to learn first, and a lot of people think that because they got a program working that it is "good enough". Most people feel that however ugly, long-winded, and tortuous the path was, is unimportant.
Imagine in the arts and crafts if execution of the raw task was only considered. So Barbra Streisand and Celine Dion would be underbid by sandpaper-voiced tonal disasters, because "hey, they sing the same words and get through the song ok". Thank goodness in music and art we have a lot of freedom to choose what we listen to, and talented people tend to get a large following.
Because so few people can quickly read the work of other programmers (usually because the code is so long and complex), we live in an era where code quality is invisible, and the sublime skill that exists in some people is completely unrecognized. Without recognition, how can training get anywhere? In bridge building, connoisseurs all admire the work of Robert Maillart. Look him up, that guy was incredible in the early 1900’s; a real fusion between art and science. The engineering fields don't get the recognition they deserve for the elegant, artistic work that exists. How about the Hetch Hetchy water system of San Francisco, that sends water 160 miles away almost completely powered by gravity? That is insanely clever. A modern wonder of the world if you ask me.
It is unfortunate that so few companies have the luxury of having two or more teams working on the same problem so that the best team can be identified. Usually we see only one team, and so objectively speaking one is often in mystery as to how good the team is. Interestingly enough, back in the days of Thomas J. Watson at IBM, when a critical task came up, he would typically put 3 teams on the task, and whichever lab won the contest, got an increase of staff and money. This approach worked very well for IBM, which was basically a monopoly at the time, and kept the internal teams at a very high level of energy. I worked on an IBM project after Watson's retirement, and by then the management of IBM had so deteriorated in integrity and guts that every team had to be a winner.
Another thing we see today is a fake 10x programmer, who copies and pastes large chunks of code from other programmers and stuffs his project with tens of thousands (if not hundreds of thousands) of lines of code that do some mysterious thing. So it is extremely foolish to measure productivity by lines of code, because people can create a monster code base in no time flat by merging modules that they get from other sources. I admire short, clear, concise programs that get the job done and are almost eternal in their purity.