Mastery is a Trap

A few years ago at Code School, we did a 3-day long hack event where we formed into small teams and tackled whatever we were most passionate about working on. During this event, I was pairing (programming together) with a coworker and they asked a question that I’ve heard a number of times before (paraphrased):

How long will it take for me to be able to program like that?

This is a question that mentors, teachers and anyone who is sharing knowledge get from time to time and it is always tough to answer. It felt great to know that my coworker respected my experience and was asking for advice — but when it came to answering the question, I had no good response. Do I mention how long it took me to get there? Do I try to find and suggest a shortcut based on what I’ve learned? What is a good answer to this question?

The Piano Teacher

A few days later, I was listening to an audiobook, The Practicing Mind, when a very similar conversation came up — but this time between a piano student (the “I” in the following quote) and a piano teacher (Don).

After one of my lessons, Don started playing around on the piano as I was packing up my music. I had never met anyone who played the piano as well as he did. He had earned his ability with years of a solid practice ethic, working at the piano sometimes seven to eight hours a day.

While he was playing, Don told me that he felt that if he didn’t start working harder, he would never get really good on the piano. I was shocked by his casual remark.

I commented that if I could play the piano as well as he could, I would be content to do nothing all day long but listen to myself play. He looked at me and smiled. “You know, Tom, that is exactly what I said to my teacher years ago when I first heard him play.

Don had studied with a world-renowned classical and jazz pianist. I had heard recordings of his teacher, who was extremely accomplished. Still, it occurred to me that if someone could reach Don’s level of playing ability and still feel unfulfilled, I was going to have to rethink both my motivations for studying the instrument and my need to reach some level of “perfection” in order to become fulfilled.

This short exchange hit me on many levels. In some areas of life I’m the teacher, but in many more, I’m the student — testing the waters to gauge how much effort will be required to make it to a destination.

This destination driven approach to learning (as well as travel, writing, and most anything) puts the mind into the wrong place for making the most of an opportunity. Rather than being in the moment and learning, I know I can get caught in the trap of having a destination. It’s something that once conscious of can be corrected. When I am aware, it helps me step back and instead try to figure out a way to enjoy what I’m doing.

When it comes to programming, what is the difference between the student, the teacher and the master? At each level, there are similarities — they learn by experience, deliberate practice and challenging themselves to be better.

Beginners Mind

The concept of shoshin (beginners mind) is nothing new and is a part of Zen Buddhism.

It [shoshin] refers to having an attitude of openness, eagerness, and lack of preconceptions when studying a subject, even when studying at an advanced level, just as a beginner in that subject would.

How do you get into this mindset when programming or doing work you want to be a master at? If you only work on projects you already know how to do everything, you’ll quickly become bored. What steps can you take to practice programming with a beginners mind?

Practice and Habit

Practice is just as important in programming as in learning Piano. How you practice and how often will have more of an effect on your productivity than anything else. Practice could be watching Pluralsight videos, taking Code School Courses, reading books, working on side projects, doing programming exercises — or anything you enjoy and that challenges you.

The goal of practice is discovery through enjoyment — not mastery.

For me, practice has always been working on side projects. I’ve created numerous failed websites, blogs, tools and the occasional comic. Each of which had a short-term goal in mind (often creating the site) as well as an immediate goal (maybe a specific page in the site). To accomplish each immediate goal, I might jump over and watch videos to help me learn about something I’m having an issue with.

The times when I have learned the most in life are when I have a side project.

I get stuck a lot. I’ll Google, search Stack Overflow, and if I’m lucky I’ll find a quick answer. There is value in diving into the source code to uncover things, but more often than not if a quick search will help solve your issue, don’t feel bad about it.

When interviewing developers, the number one thing I always look for is a curiosity that leads them to learn and accomplish their goals. It shows that they have learned how to perform deliberate practice, which is a very difficult skill to acquire. It also shows they know to accomplish their goals.

Habit

Getting into a habit of practice is tough. The Practicing Mind and The Power of Habit (as you might guess) touch on this topic a lot. Both books mention the importance of using practice as a habit, as well as finding a way to make it an enjoyable process. I was lucky enough to stumble into a way of practicing programming that I enjoy (side projects), but in other areas of my life, I haven’t always been that lucky.

A few years ago, I gave up on practicing piano. It was something I’ve always wanted to do — and may yet go back to. Unfortunately, I wasn’t able to find a way to enjoy practicing piano. At the time I didn’t realize that was the issue — I just felt I wasn’t having fun or getting better. What I hadn’t done was find a way for myself to enjoy each aspect of it. I was focused more on the end result than enjoying the moment, and it showed in how I felt when I practiced.

Video Games

Unless you’re a major league gamer, when you play video games you wouldn’t count it as practice. Video games make for the perfect definition of focus. Even glancing at your score in a video game might be enough to have a negative impact on your final result.

This practice and this focus are something I try to remember when I’m having trouble programming. The goal is for it to help me shut out all other external factors and commit to the task at hand.

Time Commitment

Developing mastery of anything takes an exceedingly long time. Becoming proficient in something, however, can usually be done with far less commitment. I’ve found that I enjoy this early learning and exploration much more, and for a wider set of skills than developing mastery. It’s the difference between becoming proficient enough to teach a topic and becoming the main source of knowledge that every teacher in the world wants to go to.

I’d much rather be the piano teacher, able to spend time playing whenever I want, rather than the concert pianist, saddled with perfection and an audience.

The Last Few Levels

The same is true for CrossFit. Being “good” in your own eyes, or at your gym, might be sometime you could accomplish by casually practicing for a year or two. Trying to make it on ESPN for the CrossFit games requires an entirely different level of commitment.

In some games, getting to level 99 might only be 50% of the journey.

A good comparison again is video games. Many games skew their leveling in a way that matches that of traditional practice. The first levels are easier, but eventually, it becomes a grind to level.

So, No One Should Be a Master?

If you want to be the concert pianist, then go for it! For just about everything else, I believe you’ll get more mileage by becoming proficient in a number of things rather than being a master in one.

Take web development. Let’s say you’re a master in Ruby/Rails. Even if you could do that better and faster than anyone in the world, you’re cornered in a very small space. What about the front-end of the site (HTML/CSS)? Is there a JavaScript component (React/Angular/Ember)? What about the design, the UI, and the UX? Have you flushed out your sites idea with real users, or found out how to market or sell it? Are you a good enough writer to do the copy? What about server hosting? Company incorporation? Taxes? Hiring? Legal Advice? Marketing?

Ok, this is a bit extreme. More than likely, you’re going to be on a team of people, each with some combination of the above skills. Some skills you’ll be able to pay for, and you definitely should. The more of these skills any single person has, the smaller the team you’ll need.

Jack of All Trades, Master of None

The term Jack of all trades, master of none is meant to be an insult, but should it be? How many people are a master of anything? The “Jack of all trades” part was first used to dismissively refer to William Shakespeare — not bad company.

Just about every language has a similar saying — some are more positive, some negative. Here are a few of my favorites:

• Najdi Arabic: The one who knows two trades is a liar
• Mandarin Chinese: All trades known, all trades dull
• Esperanto: Who chases two jackrabbits catches none
• Polish: Seven trades, the eighth one — poverty
• Italian: Expert of everything, master of none
• Russian: Good at everything and at nothing
• Spanish (Mexican): You aim for everything, but you hit nothing
• Vietnamese: Being master in one job is better than being average in nine jobs

These quotes, and this mindset are from a time when being the best at what you did was a huge competitive advantage overs with the same skill. The Vietnamese quote is the most telling for me. For many people today, “being [a] master in one job” may include nine sub-jobs. Knowing only one job may now be cause for concern.

The Craftsman Mindset

The whole software craftsman thing has taken off in the programming world a lot in the last decade. I owe a lot of my own growth as a developer to adopting this approach to creating software. There’s something about believing in something bigger than you that has an impact on you perceive your own abilities, strengths, and limits. I could feel the tug of the software community which drew me see my profession as something more than a person who makes websites.

If you’re interested in learning more, I’d recommend The Pragmatic Programmer, The Mythical Man Month, Joel on Software and Peopleware — all beautiful books focused on software craftsmanship in some way. The Mythical Man Month contains one of my favorite quotes about programming:

There is a delight in working in such a tractable medium. The programmer, like the poet, works only slightly removed from pure thought-stuff. He builds his castles in the air, from air, creating by exertion of the imagination. Few media of creation are so flexible, so easy to polish and rework, so readily capable of realizing grand conceptual structures.

Doesn’t that make you feel in awe of what you can do as a programmer? I know it did for me. Even in these works though, there is a heavy focus on creation, imagination, and shipping a product. The craftsman mindset to me is much more associated with creation, with a focus on completing a product. A woodworker who learns how to carve a specific shape perfectly, but never puts that skill to use building something is the same to me as a programmer master who doesn’t use those skills to do something they want to do.

Being skilled is one thing, using that skill to create something is another.

Know Where You’re Going

When you read the piano teacher story, who did you identify with? Is there something in your life where you would qualify as a different person in the story? For me, I’m the piano teacher in the programming world, but the student in just about everything else. In nothing in life am I the master, and I am perfectly happy with that.