Grand Master Programmer
Grand Master ProgrammerProgrammers of equal experience and education differ drastically in productivity - see studies summarized in RapidDevelopment. The ratio of best to worst programmer in an organization is near 10:1.
A GrandMasterProgrammer is on the '10' side of this ratio. Five percent of all programmers are GrandMasterProgrammers, according to estimates. Even GrandMasterProgrammers vary widely in productivity.
I was asked if a system had a certain behavior.
I tested for the behavior and did not see it.
I reported this.
I was then told that the system did have the behavior but the behavior was configurable and was not turned on.
Thus, my report was in error.
Truly, I was in the presence of a GrandMasterProgrammer.
Try asking him about another behavior: It might be he who is in error next time.
Are we talking about programming here?
Or just a GrandMasterProgrammer with the ability to develop such behavior and quickly push it from staging to production?
In RapidDevelopment, SteveMcConnell cites among others :
The research is summarized in RapidDevelopment, which I don't have handy. I can't access the original sources, but I trust the authors and SteveMcConnell enough not to care to look it up.
I'd love to see a more recent study of programmers using current tools. I'd bet the ratio has increased to more like 20:1. I have personally seen a single programmer (it was not me) produce the exact same product as a team of nearly 40 so-so programmers and managers, in the same amount of time, and with higher quality.
However, in ProfessionalSoftwareDevelopment, June 2003, SteveMcConnell states:
"... study after study has found that individual motivation is by far the largest single contributor to productivity (2)." [Page 24].
"2. Boehm, Barry W., Software Engineering Economics, Englewood Cliffs, NJ: Prentice-Hall, Inc., 1981." [Page 27]
In the same group, or between groups? I could see this being true in the same group, but not in between groups. The context of the McConnell? quote is between groups. I haven't seen the Boehm article he references, though.
So a group of five highly motivated CommodityProgrammers can out-code five moderately motivated KentBecks and UncleBobs. I don't buy it. There must be more detail in this reference. Of course, anyone with zero motivation will have zero productivity. Maybe that's what he meant?
It is not the instantaneous motivation that differentiates Commodity and Grand Master programmers - it is the long term motivation levels - of which individual motivation is the main component (financial incentives cannot create sustained motivation). A competition between highly motivated CommodityProgrammers and unmotivated GrandMasterProgrammers is meaningless because neither of the two competitors exist. -- DanielSheppard
Having just finished reading ProfessionalSoftwareDevelopment, I do not think it would be fair to use this reference to argue either in favor or against "Grandmaster Programmers." That is simply not covered by the book and one can only make inferences based on what Mr. McConnell has written. -- WayneMack
From The Mythical Man-Month by Fred Brooks
Page 29: "These studies revealed large individual differences between high and low performers, often by an order of magnitude. Sackman, Erikson, and Grant [1]"
Page 30: "In one of their studies, Sackman, Erikson, and Grant were measuring performances of a group of experienced programmers. Within just this group the ratios between best and worst performances averaged about 10:1 on productivity measurements and an amazing 5:1 on program speed and space measurements! ... The data showed no correlation whatsoever between experience and performance."
Page 180: 1. Sackman, H., W. J. Erikson, and E. E. Grant, "Exploratory experimental studies comparing online and offline programming performance," CACM, 11, 1 (January, 1968), pp.3-11. [Ed. Note, I assume that CACM is "Communications of the ACM"]
Comments: This probably highlights the need to go to the original studies more than anything else. Mr. Brooks summary can be interpreted in a wide number of contradictory ways.
Sackman, H., W. J. Erikson, and E. E. Grant, "Exploratory experimental studies comparing online and offline programming performance," CACM, 11, 1 (January, 1968), pp.3-11.
This article is available for paid (not free) download from http://portal.acm.org To find the article, open the link, then select Go to The ACM Digital Library, then Magazines (under Browse ...), then Communications of the ACM, then Archive, then Volume 11 Issue 1 January 1968, then the Article "Experimental ..." listed on pages 3 - 11.
Comments
Last year in Boston I met a GrandMasterProgrammer in self-exile from IBM Research. One day he was bitching about a bogus project at Research that had 6+ PhD's on it and had been going for several months and had produced a barely-working version of a certain debugging tool. The GrandMasterProgrammer tried to actually use the tool and discovered that it was unusable. This pissed him off so much that about 5 days later he had written his own version of their tool from scratch. His version worked, of course. :) In this case the GrandMasterProgrammer could see at a glance that the Research team's design was flawed and overcomplicated. He followed his instinct to a good design that the 6+ PhD's would never have thought of. --WylieGarvin
I'd be wary of what's meant by "productive". If the unit, for instance, is "function points per period", and the measure discounts the cost of quality, we might see high variability where in fact there is little.
The actual measurement of GrandMasterProgrammer is intuitively different than strictly productivity. However, the research which supports the existence of GrandMasterProgrammers may have to approximate by using crude measurements. Still, the fact that the results have been verified by several researchers using different estimation techniques lends support to the categorization.
Worth remembering that some people's, er, "productivity level", is not constant. I'd estimate that when I'm having fun and pouring code out my ears, I'm about 10 times as productive as when I'm bored and discontent. Sometimes I'll spend ages talking about something and making the occasional false start, and other times I'll just hack it up in a weekend. I think that a lot of other people are the same. -- LukeGorrie
So when are companies going to figure this out?
You have to PlayHurt. Part of being a professional is having the discipline to produce even when we don't want to. Anything else is basically StealingFromTheCompany. (This comment was cloned to "PlayHurt", since it is interesting on its own.)
Stealing? And what do you call paying a GrandMasterProgrammer the same order of magnitude salary as the people who are 10 times less productive? When GrandMasterProgrammer makes 10 times the salary of those at the bottom end, then we can talk of work ethic. Even running at one-quarter speed, GrandMasterProgrammer is still well worth the highest programmer salaries. Factor in other benefits like mentoring and the improvement in *other* programmers' code due to GrandMasterProgrammer's influence, and the weak salary differential is an even bigger crime.
As TomDeMarco says: "Star performers deserve star salaries". But a company's failure to appreciate this, whilst certainly shortsighted and possibly negligent, is hardly criminal or even unethical. It's simply capitalism.
The accusation of StealingFromTheCompany is provocative and inappropriate. For one, it presumes a sizable amount of value judgment, context, culture, etc. Nowhere does Luke say that he is working for someone else, so from whom is he supposedly stealing?
For another, it seems to equate software development with unskilled labor. If you are washing cars, then eight hours of car washing can be treated as such regardless of who is doing it or when. If I come to work and don't feel like washing cars, then my standing around can perhaps be considered stealing.
But software development is far more like oil painting - progress is based significantly on the artist's mood and other intangibles. At least, it is more like that than many people are willing to admit. When it is all said and done, it is impossible for anyone to measure our productivity over time or between people in a manner that makes such accusations appropriate (unless one is obviously and simply not trying to be productive at all, e.g. asleep). ProgrammingIsInTheMind.
When are companies going to figure this out? My productivity rates start high at jobs and generally drop linearly as companies throw one productivity obstacle in my way after another. I work 9 hours per day the first month, 8.5 the 2nd, 8 the 3rd, 7.5 the 4th etc. until after about 11 months I'm down to about 3.5 hours per day and they fire me, and I can't say what one thing was the problem because there were ten of them.
I agree with Rob and would like to add something one of my programming friends said. "I've learned that programming is 100% about understanding. Typing is trivial." Just because you're sitting around, doesn't mean you're not doing anything. Understanding can come from doing completely unrelated tasks. However ridiculous it sounds, I do some of my best work sitting on the toilet because it gives me a unique environment to think in. I go to the washroom way more often than I need to, just to figure out a tough problem. Is it weird? Sure. Is it slacking? No way! I'd feel unprofessional if I didn't.
It's not so weird. I get revelations on the toilet too; also in the shower in the morning, or in the pool after work. Since there are now two, I must assume that infinitely many programmers have the same experiences.
On several occasions, I have had dreams where I am stepping through the debugger and find a bug that had been eluding me for several days. I wake up and go to the computer and voila - there's the bug just like in the dream (or nightmare?). - ChuckMcCullough
Recent studies have shown that chess grand masters use different part of their brain for move planning compared with normal players. It might be interesting to put guru vs normal programmers under an MRI machine and see if they use fundamentally different brain areas to visualize/create their code.
That's an interesting idea. It reminds me of several instances of LearnedPerception.
This reminds me of UnconsciousCompetence and its associated problems
There is an extensive discussion of these thought differences (novice versus master) in Daniel Kahneman's book: "Thinking, fast and slow". He presents an extremely strong case that masters' thought is both qualitatively and quantitatively different from novice programming. Here's a description, and some thoughts on how it relates to programming. http://www.agilekiwi.com/peopleskills/understanding-ourselves/becoming-an-expert/
The equivalent would be an experienced programmer being able to memorize a specific programming solution more easily, because he recognizes it as an instance of the (say) composite pattern. The novice, on the other hand, would have to memorize all the elements making up the composite. --FalkBruegmann
However, the analogy breaks down when it comes to "random placement". Experienced programmers have usually worked on lots of projects where the code is apparently randomly placed. :)
Very little code is truly randomly placed - placement is significantly constrained by the fact that the resulting code is still motivated by the desire to perform some task (as the pieces on a chess board are constrained by the desire to avoid getting mated and/or mate the other guy first). Completely random production code, such as the output of a genetic algorithm, is somewhat rare.
Comparing master players and novice players is interesting, although not necessarily useful. Master players will realize right away when a novice makes a mistake that could cost the game. Novice players don't. Two novices playing against each other may make several fatal mistakes each in a single game, but the mistakes do not actually end the game because the opponent is not sophisticated enough to exploit them.
Regarding "novices haven't developed this skill yet" I would not call it a skill. Ability is probably closer to the mark. Most people could never learn these things.
Something I debate with my friends about work ethics. Companies say, "you have to log 9 hours a day. You cannot browse internet sites while at office. You can use email only for official mails". A retort that comes to my mind goes like this. " Well, all right. If I ever learn something outside (say, an algorithm) and it is going to save a few millions for my project, would I use it at work? Hell, no. Company resources will be used for company purposes. Outside resources will stay outside." With Software and Knowledge work, the walls between company and outside world is highly permeable and it must be so. Companies must learn to manage the chaos and workers must learn more integrity and professionalism.
This sounds like a good argument to make the issue clear to management. However, it's better for the worker to change his organization (or change his organization) as soon as practical, rather than actually perform such actions.
The GrandMasterProgrammer (GMP) also has a grasp of laws or rules that are more senior than other laws or rules. Just as in chess, there are basic laws that make it a good idea to control the center of the board early on, so there are rules in programming that make it clear to the enlightened that (say) factoring is vital and monolithic code loses.
Some of this comes with experience. Some of it seems to be a native "control of spaces" ability which can sometimes be acquired, other times not.
I agree that the GMP is usually undercompensated. Occasionally, I've seen an organization that realizes it's got gold and does everything possible to keep the GMP happy. More often I've seen it figured in terms of the cost of replacing the GMP with (n) fresh grads at some fraction of his salary. Especially when someone in management notices that the GMP seems to be "less industrious" than his "peers".
A (perhaps) natural question is, how can I become a GrandMasterProgrammer? I know how I became a programmer: by programming. Does the same apply to becoming a (much) better programmer?
Work, EsotericProgrammingLanguages, play, curiousness, and hard math.
[I am reminded of the scene in "Searching for Bobby Fisher" when Ben Kingsley's character begins to teach the future prodigy (not Fisher) chess and sweeps off all the pieces, telling him to contemplate the empty board. ThreeFingerSalute?]
Master Painter and Sculptor Degas said something to the effect that if one wants to be good at painting hands one must "render fingertips all day long"
Find a grand master and become their apprentice.
Always two there are, a master and an apprentice
See ApprenticeshipInEducation for some more ideas.
This is also a case IMO that PairProgramming lowers productivity. Saddle the GrandMasterProgrammer with an apprentice and he slows down for the short and medium term. Since grandmasters have very high turnover in companies (because they are always underpaid relative to their work), a long term plan for them is often useless. The key is to let them do as much as possible without burning them out, while not saddling them with apprentices, meetings or paperwork.
This is just the way management argues, and although it looks farsighted, it isn't. It assumes that the only benefit of a GrandMasterProgrammer is the code they produce. You may use the GrandMasterProgrammer more effectively as a single element, but you lose all the long term effects of training your own future GrandMasterProgrammers, passing on knowledge that will be very expensive to recover or recreate later. Also, it has all the drawbacks of EliteCulture? (there is some backlink for this). EBesides, even the GrandMasterProgrammer can learn something from the unfiltered view of the apprentice. And the master is truly great if the ApprenticeSurpassesMaster.
A true GrandMasterProgrammer HAS the time to take on an apprentice, attend meetings, do paperwork, and still clock off early.
No he doesn't. At least not at a company I used to work for. Several projects required the same component being adapted/tweaked for their purposes. This meant that you as a coordinator were assumed to attend all status meetings. You figure: each project has a daily 1/2 hour meeting plus one full afternoon per week. You have three projects in need of the same component. Question: How much time have you left for actual work? ---AnonymousDeveloper?
See also: PlugCompatibleInterchangeableEngineers
EditText of this page
(last edited November 23, 2014)
or FindPage with title or text search