One example is the way top tennis players execute a forehand drive. A key part of the action is (or was) to use the wrist to roll the racket over the top of the ball on impact, so as to impart topspin. Gladwell quotes top tennis coach, Vic Braden,
"Almost every pro in the world says that he uses his wrist to roll the racket over the ball when he hits a forehand."The trouble is, although high speed filming of a tennis pro's stroke shows that he or she does indeed do the wrist roll, it happens long after the ball has left the face of the racket. There really is a correlation between the wrist roll and an effective forehand, but it is not a direct causal correlation in the direction of roll-to-performance. It seems that being good at tennis tends leads you to roll your wrist for the forehand; but it is not at all clear that rolling your wrist for the forehand will make you good at tennis. Clearly something is making Andre Agassi a better tennis player than you or me; but rolling the racket over the ball isn't it. I think we can learn from that in the field of computer programming.
Take for example coding standards. Most places have them. In chip design, a well-known source is Keating's and Bricaud's "Reuse Methodology Manual for System-On-A-Chip Designs". On page 87 of the third edition we find:
5.2.7 Line LengthNow it's not clear there's anything fundamentally bad about that. OK, perhaps the 72 should be increased in the face of ever larger screen widths. But apart from that, surely making your code readable -- since it makes it less bug-prone, more maintainable, and more reusable -- does make you a better coder, no?
Guideline -- Keep the line length to 72 characters or less.
Lines that exceed 80 characters are difficult to read in print and on standard terminal width computer screens. The 72 character limit provides a margin that enhances the readability of the code and allows space for line numbers.
Well, I'm not so sure. What if neat and readable code is like the tennis pro's wrist roll? What if it is merely a marker or indicator of goodness, but not a cause? If that's the case, then telling people to
keep their line lengths under 72 characters, or to use CamelCase for variables, is not going to make them better at programming. Clearly something is making Linus Torvalds, or Richard Stallman, or Jamie Zawinski a better programmer than, oh I dunno, you or me. But I have my doubts that it's because they keep their line lengths to under 72 characters (even if they actually do!)
But so what? Is there any harm in trying to teach excellence with advice that is superficially sensible? There are two dangers.
First, such advice can actually be harmful. According to coach Braden, not only did explicitly teaching the wrist roll not improve players' forehands, the number of wrist injuries grew dramatically. But second, and more important in the programming field, is the problem of the false sense of security. By teaching the wrist roll, tennis coaches were distracted from continuing to try to understand what it really was that made for a great forehand. The danger in programming is we think by handing every new hire a copy of our "How To Do It" book -- be it the "Reuse Methodology Manual", the "Motorola Semiconductor Reuse Standards" (MSRS), or any of a host of documents from the now-dissolved VSIA -- that we have done our job in terms of creating coding superstars.