This summer is a major milestone for my software development career. As you read this editorial, I'll celebrate my 20th year as a “code slinger.” 20 years ago, I was a green-behind-the-ears software developer straight out of two years of community college and an “expert” in FoxBase/dBASE development. Wow, how wrong I was about being an expert.
I started my illustrious career as a software developer for a small property management company writing business applications with titles like “The Hot Tub Management Program.” After the property management company, I went to work writing customer management software for a resort and then a couple of years later I moved to the big city (Seattle) to work for “The Juiceman” writing order fulfillment software. THAT is when I began to master my craft. It took me about five years to really “grok” the craft of software development. It took me 10,000 hours to find Graceland. Where does 10,000 hours come from?
A normal employee works approximately 2,000 hours a year (40 hours * 50 weeks). When you factor in five years of work, that comes out to 10,000 hours. I think that is the minimum amount of time it takes to master a craft. Wow, what a concept. It takes 10,000 hours to master something.
This epiphany didn't come straight from my gray matter. It came from a book I picked up earlier this month called Outliers written by Malcolm Gladwell. In general, I am not a big fan of overhyped books like Outliers. I couldn't have been more wrong about this book. In some ways, it shared characteristics with Freakonomics (by Steven D. Levitt and Stephen J. Dubner, HarperCollins), which challenged basic assumptions we have as a society.
Gladwell starts Outliers with an analysis of a championship team of young Canadian hockey players. People were attempting to figure out why some hockey players seem to excel while others do not. When analyzed, a startling conclusion was made: Kids with birth dates falling in a specific range seemed to play better than the others did. As Mars Blackmon would say, “Gotta be the stars!” People born under a specific sign are better hockey players, right? Nope. Basically it boiled down to this: The kids falling in a certain birthday range were allowed to start playing hockey earlier than the other kids. They got a head start by six months to a year. Now these kids did have talent, but talent nurtured earlier has a better chance of success, right?
That makes sense. Concepts like this were made more clear as the book progressed. Gladwell wrote about two of the most regarded software developers of our day. The two Bills: Bill Gates (co-founder of Microsoft) and Bill Joy (co-founder of Sun Microsystems). One thing that Bill Gates and Bill Joy share was the fact that they had access to computers at a very early age and spent countless waking hours working on these machines. By the time real opportunities presented themselves in their 20s, both of these men had the requisite 10,000 hours under their belts and were able to apply their craft to great advantage. It was not just the amount of time they spent with their computers, they did have talent by the truckload, but that talent was nurtured from an early age to yield some real talent.
With all the talk of software craftsmanship these days, we must never forget that it takes a lot of time to master new skills. When I moved from Visual FoxPro to Visual Studio .NET in 2001, it took me a few years to really master a new way of development. It didn't take me quite 10,000 hours, as I had a lot of experience in object-oriented code and frameworks, but it did take a certain amount of time in the trenches to master .NET's new set of concepts.
What is true in software craftsmanship is true in life's other endeavors as well. Consider this old saying in poker:
"It takes 15 minutes to learn the game and a lifetime to master."
I completely relate to this statement. Around ten years ago, I sat down for my first real poker game in a casino. I was scared out of my wits but I held my own. I lost, of course, but I had caught the poker bug. I spent literally hundreds of hours grinding to learn how to play this game effectively. Do I consider myself a master? Heck, I am no Daniel Negreanu. However, I can definitely hold my own with the best of them in the casinos in Vegas. I feel this way now when it comes to Agile and Extreme Programming development processes.
In 2000, I found a book called Extreme Programming Explained (Kent Beck, Addison-Wesley Professional). This book seemed to be what I had been looking for when it came to developing software. At its core, it talked about working directly with customers to develop exactly what they wanted correctly the first time. Over the ensuing years, I spent time attempting to develop my programming skills with customers and in my own practices. It seemed to me like I had started over once again as a wet-behind-the-ears programmer. I didn't have a lot of luck getting clients to adopt these principles but I did keep growing my own personal knowledge. Flash forward to October 2007 in Austin Texas. I attended my first ALT NET Conference. There I spent time learning more about implementing agile practices in my company and with my clients. I was going to master these practices if it killed me. Over the last year and a half, I have been putting in my time towards my 10,000 hours to Graceland. Fortunately, I've had the opportunity to be mentored by, speak with and become friends with a number of agile developers I respect. This dialog has been most important to my mastery of agile development. Like my efforts to become proficient at poker, I am not a master but I am beginning to “hold my own” with these folks. I am glad they have spent the time sharing their 10,000 hours to Graceland with me.
This journey has given me another level of perspective when dealing with people new to agile development practices. I am an agile teacher (and definitely a learner) and need to take into account that it takes a number of hours practicing thus stuff before you can see the real benefit. Many developers will take a surface glance at a subject like Test Driven Design and rule it out as a waste of time. You've no doubt heard the question, “Why do I need to waste my time with this?” We need to address these questions with patience and understanding. Think back to your early self as a wet-behind-the-ears developer. It took you 10,000 hours to get here. I hope your journey was equally cool.
