The “10,000-hour rule” was coined by psychologist Anders Ericsson in reference to violinists, but popularized by author Malcom Gladwell to be more inclusive.  The rule states, essentially, that mastery of a given field requires about 10,000 hours of dedicated practice.  For musicians, this is certainly true, given the time it takes to understand the nuances of one’s finely tuned instrument, plus commit difficult passages to muscle memory and to correctly interpret the composer’s auditory vision of the score.

But, what of other professions and activities?  What constitutes dedicated practice in other fields?  The 10,000-hour goal in the world of work is about five years of 8-hour workdays.  In most professions, five years is the entry-level experience for a “senior-level” position, what I would call “journeyman-level” in a skilled trade: someone who can handle routine tasks without supervision or guidance.  The next level of performance is measured at the eight or ten-year experience level, given that probably a third to half of the average work-day is given over to socialization and the business of doing business, during which we are not practicing the skills of our trade.

For the profession of system administration and similar technology pursuits, the 10,000-hour rule is even harder to judge, since mastery of the art is a moving target.  I personally have almost 30,000 hours of paid work as a systems administrator, of which we can apply about half, or 15,000 hours, to “practice,”  plus a few thousand hours of actual practice and study specific to the skill, prior to and outside of “on-the-job” time.  Any muscle memory part of the skill set is in keyboarding, which carries through, and the Unix philosophy set down by Thompson and Ritchie in the early 1970s remains to be thoroughly understood and practiced.  The analogy to music further maps the idea of mastering a composer’s body of work to mastering the various “flavors” of Unix: Solaris, BSD, SVR4, AIX, HP-UX, and, of course, the varied Linux distros.

This analogy breaks down when we consider that the body of work refuses to stay static: Unix is a constant sequence of variations in the form of upgrades, after which the original is never performed again.  Software and hardware are intertwined, where older editions of systems software can only be performed on obsolete and non-repairable hardware (though emulation can eliminate that obstacle), as if a particular work of music could only be performed on a single, fragile instrument.  So, mastery of systems administration is a dynamic process: virtuosity requires constantly learning new works (software) played on new instruments (hardware systems).  I don’t think 15,000 hours constitutes mastery of the art, divided as it is between several major versions, and with time split between straight system administration and programming, in an ever-changing environment.

Yet, mastery requires practice, meaning exercises in the fundamentals: in music, scales and fingering exercises; in systems administration, scripting, building kernels and applications from source, and testing.  These activities are the muscle memory of system administration, the automatic responses that facilitate solving difficult problems that require planning and reading the manual–the ability to apply resolution promptly and with skill.

Which comes to  the other side of expertise: in order to master a given skill requires physical stamina and flexibility, as well as a clear mind.  For the past 33 years or so, my outlet to balance the rather sedentary computing life has been bicycling.  Now, masters of the art like professional bike racers and world-class bike tourists accumulate 10,000 hours of practice within five to ten years.  As a bike commuter and accidental bike tourist, a mere 50,000 miles–my estimated lifetime accumulation at present–at perhaps an average speed of 14 miles per hour,  constitutes only about 3500 hours of practice, far short of mastery of the skill.  Worse yet, the past year has seen the end of bike commuting, since I now run my professional practice from home.  Now, I should be able to take my former commute time and recreational biking time and use it for practice, but the incentive just isn’t there.  Until one realizes that, like system administration or music, regular practice is essential not only to achieving mastery, but to maintaining a reasonable level of competence.

A bit over six years ago, I was inspired by a true master of the sport, Shirley Braxton, who, with her late husband Sam, had owned a bike shop in Missoula, Montana, and, in the 1970s, did much to start the bicycle touring industry by building bikes designed for loaded touring.  Shirley, then in her late 70s,  made a practice of capping the bicycling season with a “birthday ride,” of length in miles equal to her age in years.  For a few years, this was motivation enough to get out and train through the summer, building up to an early fall 60-odd-mile ride, even to the point of participating, as a training ride, in three MS Tours, a fund-raising ride to benefit Multiple Sclerosis–originally a 150-mile ride in two 75-mile stages, but, because of popular support from relatively new cyclists, has for a number of years offered 50-mile stages, which course we prudently chose.  As with any pursuit of mastery of a skill, the tools and instruments are also important to achieving the goal.  In our case [meaning, of course, the Nice Person and the Unix Curmudgeon], we ride a mountain-style tandem, which, like it’s single-seat relative, has a heavy frame and oversized tires, intended for trail riding rather than racing or touring, though we have toured with the tandem (see the other blog articles in our bicycling category). In any case, swift passage and high mileage are not the strong suits of such machines, though they generally come with very low gearing that compensates on hills.  Or so we tell ourselves.

So, with advancing age, both myself and my ride–a 1996 Specialized Hard Rock, entry-level commuter/mountain bike, with fat tires, steel frame, and no suspension–together we’ve tackled the “birthday ride” solo for the past three years, the Nice Person having come to her senses about the effects of inadequate training, leaving the Unix Curmudgeon to huff and puff his way alone through what became the longest rides of the seasons by double.  Without benefit of daily sprints across town to work, and with the last ride a month ago, setting out into the foothills of the Olympic Peninsula on a nearly 70-mile course was less a demonstration of ability and skill than a simple grueling test of endurance.  But, some of the lessons of nearly 35 years of all-weather commuting and touring held forth:  keep hydrated, keep fueled, put on rain gear when it starts raining, stow it when it stops to avoid overheating, don’t push too hard early on, and get off the bike for at least a few minutes every hour to eat, drink, and rest the legs a bit.  Oh, yes, the thought of aborting the mission did occur, once or twice, but we can report mission accomplished: 69 miles in 7 hours 52 minutes, an average speed of 8 and 3/4 miles per hour, including pit stops.  That’s just about the daily limit for a mountain bike, and one of the reasons we declined the 75-mile route on the MS Tours–there was an 8-hour time limit on that course, and it is important to finish.  Reasonable goal-setting is also a part of developing mastery of a skill.

Next year, the goal is to ride often and ride long, work on a more balanced fitness regimen, lose a bit of weight, and get a lighter, faster bike.  The rest of this year, the goal is to work more with server virtualization, hierarchical storage management, and keep up with the latest systems releases, on the work side.  Practice, practice, practice.  No matter how old you get, there is still more to learn, and roads to explore, perhaps at a more leisurely pace.