Developers With High Productivity Tenx Hundredx Thousandx
Developers With High Productivity Tenx Hundredx ThousandxWho 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
Nominations for 1000X
Nominations for 100X Nominations for 10X
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:
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.
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.
CPInst* cp_open_file( FILE * ); void cp_process( CPInst* ); CPFList* cp_get_functions( CPInst* ); void cp_cleanup( CPInst );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
[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?]
Yes! HaHaOnlySerious!
This is based on his claims that he writes 100x less code solving a problem in ForthLanguage than he finds in solutions to similar problems written in C [http://www.colorforth.com/1percent.html]. Notable:
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:
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?
Moved to HomeopathicPotency
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.
DaveWest has launched an undergraduate program at NewMexicoHighlandsUniversity that aims specifically at this 10x ability. His approach would not surprise any reader of this site.
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?
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.
``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?]
:-) 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. :)
And what about those who do EditorMetaProgramming?
And what about those who realize that an entire project is a stupid senseless waste of time and talk management into cancelling it, thus avoiding 1,000,000 lines of negatively productive code?
Shhh!!! If it keeps programmers employed, it's not entirely negatively productive. :) (ducking)
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.
The bottleneck is often trying to figure out what the hell the customer wants, not makeing code.
I suggest another topic QuantumLeapsInProductivity.
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.
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.
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.
EditText of this page
(last edited December 17, 2013)
or FindPage with title or text search