Who are the developers with the famous "10X productivity", and what strategies, patterns, and habits make them so productive? I keep hearing that some developers are "10X, 100X, or even 1000X more productive" than others. I'd like to meet some of these people, and ask them what strategies, patterns, and habits make them so productive. Who are some of these people? Who would be on your dream team? Does productivity need to be objectively measured for this subject, or can peer intuition suffice? What about a person with relatively average programming skills but occasional blasts of good judgment that saves a team tons of time? What can us mere mortals do to enhance our productivity the most? Has this information already been collected somewhere? If not, would this topic make for an interesting workshop/article/book? - KelleyHarris

Certainly. All too little has been written on the subject. I believe a number of the old MIT AI Lisp gods were in this category. It might even apply to Stallman; prying info of this sort out of Stallman would be an interesting process. You could sell tickets. (I'm kidding. Don't interview him on that topic.)

I've known a number over the years, and I can personally attest that e.g. BillJoy is/was such a person. People seem unclear on why he was famous before Sun Microsystems. "So he wrote a shell and an editor, thousands of people have done that, what's the big deal? And they're not my favorite shell or editor, anyway." But no, it goes far beyond that; Berkeley Unix wouldn't exist without him. He cranked out code like a machine, as fast as he could type, and contributed to just about everything, not just the projects that have his name attached. He came up with ideas that inspired other people, rapid fire, nonstop. 1000x beyond the average programmer, easily.

Sorry to say he wouldn't join your team as a coder these days. Some of the qualities that he had seem to represent such people in general:

very high intelligence (this may seem obvious, but it often is not mentioned, apparently because it's not P.C. to notice that not all programmers are geniuses),

ability to touch type (there are exceptions, but they are unusually fast with the two fingers they do use),

a deep consuming passion for software, such they think about it and dream about it 24 hours a day 7 days a week, not just 9 to 5. This often leads to programming nights and weekends, but that's a side-effect, not a cause.

a burning desire to learn the best of what everyone else in the field is doing (i.e. they keep learning beyond what may be required for the job/degree, and they find others' work of interest, so they don't have so extreme an NIH attitude as to be uninterested in finding out what others are doing),

enough self-confidence, probably even arrogance, so as to be unafraid to experiment and make mistakes, and to try things that no one has ever done, even if it contradicts established wisdom,

a flexible attitude/personal philosophy, allowing them to pursue what pragmatically works beyond the boundaries of rigid ideology (people at the other extreme will spend years finding ways to instead work within those boundaries, which may yield a bigger eventual payoff, but hinders average productivity dramatically over both the short and long term)

Reducing any of that to strategies/patterns/habits seems problematic, beyond telling people "if you don't love it, you'll never be the best", which obviously applies to any field -- and is not sufficient.

There probably *are* strategies/patterns/habits that would be of use. Word of warning about that in researching this: people mostly do not know why they are effective. This has been researched in itself (don't have a citation, sorry).

Different brain systems are involved in doing things versus understanding how they are done, whether the topic is sports, business, or programming. This part any neuro guy can tell you about in detail.

The citation I'd like to give you is specifically on why business success how-to books (a) don't work and (b) proliferate. People write about their success, or of a successful person they know/interviewed, and it doesn't help, because the things that the person thinks were the key to their success, actually were not. They were incidental, and other factors instead were the critical ones.

So interviewing the most productive programmers in the world, although a great idea, and no doubt would give you lots of material and advice along the lines of "this is how you do it", and you could publish academic papers based on that, and lecture about it, and base a book on that, and it might sell well and be highly regarded -- but it wouldn't actually reflect the truth, because those people did not know themselves.

What would be really interesting would be to design a process that would somehow delve deeper than that, and find the true reasons they are so productive.

The former would pay the bills, the latter might guarantee you a place in history. The world needs this.

I met a programmer with 10x productivity once. He was a senior person and required 10 programmers to clean up his brilliant changes. Strange thing was that management did not seem able to see this. (Yes, I am pretty cynical about the 10x proposition; I just don't see it in real life).

You just see 1x, 0.1x and .001x... hmm, what's the difference?

The point is that programmers who view themselves as 10x usually degrade their own abilities by trying to pretend to be supermen. Programmers who are willing to view themselves as average (1x) tend to maximize their own capabilities. Nothing takes up as much of a manager's time as overseeing a programmer who views himself as "clearly superior to the others."

What is the value of x? If the reference constant is oneself, and you are the most productive programmer on the team, then everyone else is fractional. Must be how BillJoy sees the world. Make x the "median programmer productivity", which seems an unlikely value to ever be defined, would seem to lead to both fractional and multiple. Any other stories of .1x and .001x programmers?
Automating frequent tasks

10x programmers are the ones who figure out "all" repetitive things are best left to the computer, including writing code. 10x programmers figure out ways to make the computer do their work for them, thus 10x or even 100x is entirely possible. 1x programmers write programs, 10x programmers write programs that write programs.

While MetaProgramming can help; it certainly is fallacious to claim that all 10x programmers engage in metaprogramming, and that metaprogramming is the only thing that makes the difference. There are numerous 10x programmers in C/C++ (10x compared to other C/C++ programmers with similar experience and doing similar work), an environment not conducive to metaprogramming.

Often, C programmers who want to do metaprogramming do it in another language (e.g. Perl).

Actually, now that you mention it, it is in fact quite common to write C programs that generate C programs, that generate C header include files that are included in a C source file that is then immediately compiled, that generate Makefiles that are then used in the same compilation process, etc. This sort of thing tends to arise only with unusual problems or in large projects -- and often create whole new classes of problems, but is nonetheless a sometimes indispensable approach.

One of my first major C programs in college was a system that checked what common C functions were invoked and automatically added headers to files for them. I used that program for quite a long time. Since we were freshmen at the time, we were given the parsing library and we just called it on a source file, compared the results to a database and decided what to pick. Later, I extended it to help me track dependencies within a project and generate those includes. I hear this is a very common project. -- DaveFayram

In other languages, yes -- but what's this C parsing library you used so casually???

A custom thing a grad student wrote for us to use explicitly for that purpose. Sadly, that program died with my account on the labs, and I didn't think to archive it until it was far too late. The interface was very simple though, I can sorta quote it from memory, but I think I might be remembering the types wrong.

The CPFList was a linked list. We never got the source, just a header file and binary. It was specifically made to do the heavy lifting or parsing for us. I suspect i used flex and bison, since that instructor was really happy with those tools. It's actually pretty easy to point to all functions invoked in a C file without resorting to fully parsing the file, if you're willing to allow for a margin of error. -- DaveFayram

This sounds pretty useful, maybe someone else archived it? What was it called?

The magin of error includes that a loose approach (one that does not actually parse with a complete accurate formal grammar) will break 100% on code that doesn't follow expected coding styles. The loose approach was used with ctags tools, for instance.

My point stands, programmers who use programming to make programming easier for themselves are more productive. Many if not most programmers don't do that in my experience. These things range from MetaProgramming, to CodeGeneration, to UnitTests, to CodeMacros?, to IDE macros, to batch files and shell scripts. 10x programmers automate everything they possibly can, just to get out of doing it by hand, even if it doesn't apply to their current project. 10x programmers know how to take advantage of a computers strengths, 1x programmers don't, at least not to the same degree.

I think you're right, but you're talking about a lot more than just the things that are most frequently meant by "metaprogramming". This gets into "automating frequent tasks".

This kind of reasoning is why I am such a pulpit-pounding advocate of Scheme and Lisp. These macros save you mountains of work and let you approach problems in ways that just boggle a more conventional programmer's mind.

[That's true, but not all Lisp programmers avail themselves of automation as much as they could, so the point stands regardless of language.]

Indeed. Check out the LispShowOffExamples page for examples of using macros and whatnot to make automation that goes AboveAndBeyond?.

[It occurs to me that I missed a point: people using powerful languages/tools/environments (including Lisp) automate much more often than people in bare bones C environments, without question, so I shouldn't have implied otherwise. A really productive C programmer might write programs to generate programs, but this is pretty common in the Lisp world without it saying anything unusual about the programmer who did it.]

I disagree, since a Lisp programmer "is" unusual to begin with. Anyone who's gravitated to Lisp, is already well above and beyond the average programmer, and I'd venture to say that is why they gravitated to Lisp in the first place, because they were looking for something better.

Err, what exactly are you disagreeing with? And as for your statement, I'm sure we can dredge up some pretty stupid Lisp programmers if push came to shove. I think in general you find more people that are "on their game" in these off-language communities because they represent an interested minority. While I love Lisp, I don't think that knowing it makes me more deserving of oxygen than the next programmer."

Well I do, I'd take a below average lisper over an average Java/C/ect. programmer any day, the lisper would likely still be better. And I'm not a SmugLispWeenie, but I'm working on it.

[diff voice: And anyway he meant unusual to other lisp programmers. Or did you just want to throw in a little SmugLispWeenie humor?]

Chuck not only touch types, but creates his own custom chording and DvorakKeyboards and otherwise customizes his programming environment (ColorForth).

Extremely self-confident and willing to experiment. It is unclear whether his distance from the CS mainstream has been a boon or a hindrance.

OTOH, Chuck is a hopeless optimizer, often going way beyond the call to squeeze a few more bytes or cycles out of his code. And because Forth is so isolated, he often reinvents the wheel (he has estimated that he has written two-dozen multiply/divide routines for various processors).

His penchant for reducing code size by 99% is cool, but productivity usually would take other factors into account other than just code size. Does he finish the whole process fast than the people who don't do the 99% reduction? Does he reinvent the wheel faster than other people who borrow an existing wheel? Or is it at least a sharply better wheel?

From forth.com: "By knowing exactly how Forth would use these resources, by omitting hooks and generalities, and by sheer skill and experience (he speculated that most multiply/divide subroutines were written by someone who had never done one before and never would again), his versions were invariably smaller and faster, usually significantly so." It's probably worth pointing out that Chuck has some pretty unconventional ideas about SoftwareReuse.
Don't forget that there are many programmers with negative productivity.
I was joking when I claimed 60X productivity above, but since Doug responded, I want to elaborate, even though he was joking too. :)

The project in question actually was finished, and maintained and tested for an extended period of time. It was to convert both sides of a proprietary protocol over to XML. I finished my side (in Java) in 2 days. After 4 months, when the project was canceled, my counterpart (working in C++) still had not completed the project. I spent about 30 minutes a week keeping my branch in sync with the mainline (which I also had to maintain) and testing it to make sure everything still worked, while waiting for him to finally integrate his code (which never happened).

This is probably not a fair comparison - I certainly don't average 60 times more productive than the average developer, or even 10X. It's comparing BurstProductivity? with SustainedProductivity?, when there's probably a 10X difference within an individual programmer between the two. And my counterpart was a significantly LessAbleProgrammer - in his year and a half at the company, he produced essentially zero. The C++ code base he was working with was also a mess. It had network options popping up dialog boxes, application logic mingled in with message processing, and the same line of code repeated 110 times (when that line had a bug, it was the closest I've ever seen a senior architect come to crying). I took some flak from other programmers for insisting on separating the messaging code from the UI, which was what let me convert it and maintain the conversion in so little time.

But there are some lessons for high productivity here:

OnceAndOnlyOnce. Someone who has to change only 1 line is going to be 100 times more productive than someone who has to change 100 lines. More actually, because of reduced debugging and testing time.

Don't waste time getting stuck. In my experience, programming is usually knowledge-limited, not time-limited. Most time is wasted getting answers to questions. If you can cut that down significantly - either by holding a lot of information in your head, knowing the right sources to look, or asking the right questions - it cuts a huge chunk out of the time wasted.

Finish projects, and ContinuousIntegration. Integration costs big-time, because every change needs to be made in multiple places. You also lose time by context-switching between the various activities you have on your plate. Also, projects typically begin in BurstProductivity? mode, and then settle down to SustainedProductivity? as the novelty wears off. If you can finish while still in BurstProductivity?, that'll become your sustained productivity.

I think you may be onto something, in that "high productivity" may not necessarily equal results. And if you define it to equal results, then how do you quantify "10X", "20X", and so on? It's easy to crank out function points, it's harder to ensure that the function points are actually useful. Is the methodical developer who implements one feature that makes all the 99% of the users happy more productive than the GrandMasterProgrammer who implements 99 features that together make 1% of the users happy?

There are in fact other issues than productivity alone. BillJoy for instance was severely criticized for his commenting style; he said that the code itself served as the comments. This doesn't go over too well with people in general. He later decided that his previous stance was too extreme, and made a point of writing a thorough explanation of each function, but to still have essentially no comments within functions. This style has its defenders, but also detractors.

The point being that BillJoy was highly productive in the sense of cranking out a lot of working code really fast, but a typical PointyHairedBoss would predictably assign 20 people to work over that code later, adding comments in the regulation style (++i; /* increment integer variable i before going on to the next step */), rewriting any code that they didn't understand (typically breaking it in the process, but at least then they understand the broken code, and it's on the list of future low priority feature requests to fix it), etc.

There are other programmers who write far fewer lines of code per day, so the project takes quite a while to finish, but when they are done, all marvel at the gemlike perfection of the result -- albeit wistfully, because the total number of lines of code is too large to really grasp everything in its entirety -- but still, each line of code seems clear and unassailable.

These programmers are widely appreciated, but not for "productivity".

Different measures seem mutually exclusive. Is it really possible to crank out 5,000 lines of code per day on a sustained basis, and still have the resulting code be considered elegant, clear, easy to read and maintain, beyond reproach in its style, etc?

At minimum there seems to be a difference between programmers who write code that would be admired by grandmasters versus code that would be admired by the vast ArmyOfProgrammers. Or at least, this seems to be widely claimed by those who claim to understand and speak for the ArmyOfProgrammers.

Don't be coy, step right up and say what you mean. A quick glance at that site doesn't reveal anything except a software "apprenticeship" program, which does not at all explain aiming at 10x.

It's also far from clear that anyone claims 10x as a result of using any methodology whatsoever; this page was started to discuss such things. So speak up.But What is X?

Given a lack of definition of "productivity," claims to have more or less productivity are meaningless. I probably would not be able to recognize a 10x or 100x programmer if I saw him (a 10x or 100x ego, on the other hand, is far too common).

Let's put some numbers on this. As a baseline, a 1 year/12 month project with 10 1x programmers would take 12 months to complete. If we use 9 1x programmers, and a 10x programmer, the project should complete in 6.3 months. If we use 9 1x programmers and a 100x programmer, the project should complete in 1.1 months. If we use 9 1x programmers and a 1000x programmer, the project should complete in 2.6 days. Anyone seen a single programmer who could be put on a project and cut the delivery time in half? I don't think people adequately understand how large an order of magnitude change would be. Yes, some programmers may be consistently better than others, but not by 1 or more orders of magnitude. -- AnonymousDonor

I've seen single programmers who could be put on a project and cut the delivery time in tenth - if you took all the other programmers off of it.

It wasn't so much being highly productive as not being unproductive. Human beings waste the vast amount of their time. I suspect that a majority of programmers are negatively productive. That's why I'm not sure the productivity numbers mean all that much. -- JonathanTang

[Please note the above is describing around a 100x performance difference, reducing staffing by 10x, reducing schedule by 10x. To put it another way, the 100x programmer accomplishes as much in 4.8 minutes as the 1x programmer does in 8 hours. This range of difference is something a little bit difficult to accept based on mere assertions.]

It shouldn't be. Some people have never seen such a phenomenon, but that doesn't mean it doesn't exist. Studies over and over again say that the average output in debugged lines per day is 4. That's 1/2 line per hour. A really fast typist who didn't suffer from the other unproductive problems could type a lot more than that in 4.8 minutes. It's clearly physically possible.

Of course, what does "debugged" mean? Containing zero defects, having survived oodles of UnitTests, expert user testing, and any other software testing you can think of? That it compiles?

Your final sentence makes all this sound a bit sarcastic, but it's a good question. In the case of the studies of what constitutes average, however, this was addressed one way or another. The question is more about what it means in BillJoy's case. "All" code has bugs (except in the case of Knuth -- who also had bugs). BillJoy had less than average, and held contests to see who could find the most bugs, which he then fixed. People who disliked the early c shell and vi editor and Unix VM subsystem etc didn't dislike them because they were buggy; his code shipped and was widely used and widely considered usable, which is in some sense the ultimate metric for software -- and one that we all know is violated by a lot of commercial software.

Come to think of it, surely every experienced programmer (who is also a fast typist) can't be sure that they themselves never cranked out 10 lines of code in 5 minutes, which is around 200x. The question then is what's going on with burst versus sustained.

I do so regularly... and it is even of decent quality. And I would never consider myself in the same class as a BillJoy when it comes to cranking out code.

Well then, there you go; the question is about sustainability.

In some shops, management practices and processes may be an impediment to code development. The crack above about CMM 5 was offered somewhat in jest (and CMM5 shops may well have a reason for being so), but programmers frequently engage in activities other than programming. Some of them are useful towards the task of developing software; others debatable; still others clearly not useful. Depending on the policies and procedures you have to deal with, the amount of time doing actual programming (or design, or test development, or testing) may be a small portion of the total work day.

Exactly. Company policies can, and demonstrably do, drag down the productivity of the otherwise peak performers.

[Again, look at the numbers to see if this appears reasonable. Per the proposed productivity measure above, the 100x programmer have to complete 400 debugged lines per day for 1.2 months straight (1.2 months * 4.3 months/year * 5 days/week = 26 days) for a total of 10,320 debugged lines of code. This is a sustained pace of 1 debugged line of code every 1 minute and 12 seconds for 26 days.]

``I've seen 10k lines of tested debugged c in a month.''

10k lines in a month? I think I could do that, if I understood the problem domain well to not make severe mistakes.

[Remember, we are talking about sustained effort. Can you continue that pace for 20 years, or is this a one shot deal?]

That's a good question, but on the other hand, someone who could "only" sustain that pace for a month would still be very useful on short term projects compared with the average person.

You're using the wrong measure of productivity though. I know a freshman Intro CS student who wrote a 10k line program for a 1-week project. Then she discovered function calls. ;) -- JonathanTang

:-) Which now leads us naturally into a discussion of which factors should be considered when we talk about "productivity".

One of the ones that's been mentioned on this page is how to measure it when someone writes something in 100 lines of code to do the same thing that someone else needs 1,000 lines of code to accomplish. If they do it in an equal amount of time, surely one is 10x more productive than the other?

And if someone does MetaProgramming, do they get credit for lines of "source" code, or lines of "generated" code. Many early C++ compilers were infamous for, ahem, assisting programmers who used templates with improving their effective code counts. :)

I think that the programmers who are being kept employed by really stupidly-conceived projects are increasingly those in India.

Anyway, careful studies need careful metrics, and some of these things are really hard to measure in a well-founded way. Less formally, however, it seems clear that productivity ideally should be about final results: picking a problem that needs to be solved, and then solving it well quickly.

Cranking out lines of code fast contributes. Decreasing the number of lines of code that need to be typed contributes. Using meta techniques contributes. Selecting elegant approaches instead of brute force approach can contribute -- but sometimes it's the other way around. "When in doubt, use brute force", but if the brute force approach is huge and kludgey, one shouldn't be in doubt.

But do any of these things provide 10x, 100x, or 1000x improvement? I feel as if the case is vastly overstated.

The possibility of someone using 1/10 as much code to produce the same result has already been brought up, so yes, that particular thing does provide 10x, obviously. ("Could", I should say, since on this page that's a hypothetical.)
Isn't it ironic to debate about the productivity of GrandMasterProgrammers? using lines of code ? SubtractLinesOfCode.

Apparently it's ironic to someone who didn't read the whole page, nor even just the discussion immediately above.

I'd rather propose a different classification. Let's take ICFP competition (or other suitable programming competition. There are programmers who:

the winners and top performers of the competition

those who participate to it and solve the task even if their programs are not at the same level as those in the first category

those who are able to same task within one week.

those who are able to solve it within one month.

those who are able to solve it within 6 months.

those who stand no chance of solving such a task withoput being retrained/going back to school, etc. This may comprise the vast majority of the workforce.

It's clear that between the first category and the last the difference in productivity is in orders of magnitudes for any programming task that has some level of algorithmic difficulty. It is also true that for tasks like slapping together fields from the database onto a screen the difference is attenuated if it is not entirely reversed because of the boredom factor.

The bottleneck is often trying to figure out what the hell the customer wants, not makeing code.

The real trick to being more productive is to do less. No one is writing (writing, debugging and delivering) 100,000 lines of code in a month (assuming a typical 1000/lines/month per person). The only way to do better is to do less - that means leveraging on known good stuff. That "stuff" includes patterns and code libraries.

The other productivity killer is ill conceived projects. This usually is some code that was written for some specific purpose that now needs to be "upgraded" to do something more. If work assignment is stated something like "use this library - but don't change it" and the library wasn't built to be extensible in the first place, you've been put in a box which has no exit - its an in escapable maze. In fact, lots of projects conceived by the marketing department and or managment are really not doable in a systematic/clean way - at least without a rethinking/refactoring of existing code.

The single best advice to being productive is to avoid getting assigned such projects or working in such environments.

The lendendary accomplishments cited are more less stand-alone projects where one can make his own rules.

Its a metaphore for real life - he who makes the rules wins the game.

Robert Ramey

Sometimes it makes more sense to do the right thing slow rather than the wrong thing fast. Should one strive to be a fast runner or a motorcycle builder? See "Factor Soup" under WarStories.
I think the high productivity factors come from an effect, that JamesCrook told me about:
''There are some programmers, that can solve problems of a complexity, that others simply cannot comprehend or handle at all (for whatever reason, intelligence or experience, whatever). And every project has its complicated corners. If you put an AverageProgrammer on the task he may be unable to solve the problem and burn huge amounts of working hours getting up to required skill level, whereas one already skilled programmer may solve the problem in a moderate time. These productivity factors result from incorrectly assuming, that all tasks are equally hard. -- GunnarZarncke

Why not study productive teams instead of individuals?

I don't think there are any.

That itself is a more important research issue than fast individuals, in my opinion.

Further, maintenance is often the resource bottleneck, not the original app. It may be a moot skill to crank out an app quickly if it's WriteOnlyCode, and the original coder moved to Timbuktu when you discover you need some changes.

On the individual level, I believe I could be a much faster individual coder if I built a language and libraries and perhaps a database language/style tuned for TableOrientedProgramming that match the way I think, and create a smart editor with Intellisense-like feature so I don't have to remember exact object, parameter, and library names (but not intrusive, like MS's editors). But few else would like such a stack such that it's essentially a WalledGarden in terms of sharing maintenance. The key is matching tools to WetWare. Maybe existing fast coders find existing languages/tools a good fit for their WetWare, coincidentally.
FederationDevelopment
Many large software companies demonstrate that 1000 average programmers do not in fact equal even one 10x programmer. Solving problems is not like lifing rocks; more hands does not guarantee the ability to lift bigger rocks, just more of them, and if your project includes even one big rock, you're stuck. This is where the 10x/100x/1000x coders come in, I think - their value is not just that they are fast coders (which they usually are), but that they can cleanly solve the problems that a normal team simply can not.
CategoryProductivity