Sunday, May 8, 2011

Mastering programming and the role of deliberate practice

If you want to master programming and become the best that you can be, then it requires a lot of practice. However, writing lots of code or following lots of tutorials is not going to do it. You need to be deliberate. Being deliberate in your practices means you do the following four steps
  • Set a goal
  • Work
  • Reflect honestly
  • Pivot
and then you repeat...

Setting goals

If you don't have goals (and many don't), then you are going to fail. This is why I would say curiosity is a precondition to mastering programming. "How do I do ___ ?" Once you have a whole bag of those questions. Answering these questions and scratching the itch is how you set goals.

Setting effective goals

I think this is the hardest aspect of developing skills, and I think this is where getting a mentor makes the most sense. If you are fortunate, then you can set your own goals and figure out a strategy on achieving them.

Goals are recursive, and your ultimate task is to turn your goal into a series of actionable steps.

My general strategy is to pick the most ambitious goal you can think of that interests you and then start breaking it down. For instance, I wanted to build a computer algebra system. That's a daunting goal.

Daunting goals are good because they provide an end-game and generate many goals which you can iterate and improve on. You'll learn more from trying something big than trying a number of small exercises out of a book (This is my thesis statement for the future project I'm toying around with).

Let's say you've picked your daunting goal and you have no idea how to begin? This is the role of a mentor to look at your goal and say "first you need to do ___"?


After you have your first goal, the next step is work hard. I'd like to say work smart, but that probably isn't going to happen. I say pick a time period and commit to working on it until that time period is up (or finish if it is going to be a success).

A combination of study, design, coding, testing will eventually pay off in either a failure or a success.


Why did you fail/succeed? What was a complete waste of time? What felt like the most productive? What are you missing? Are those resolvable? A mentor can help you through these questions, but you need to first be ready to hear the results.

The more honest reflection you can give to your work, the better. Everything I do, I write postmortems for (both successes and failures). Some are one-lines and some are multi-page reports. I do this because I fuck up (a lot).


Integrate your reflection and thoughts to help pick your next goal. Do you need to try something else? Do you need to try again after a refreshing bubble bath? Should you move onto to a different project? Did you get inspired to work on something else?

As long as you continue to practice something related to programming, then you will be successful.

Becoming a Master?

We often like to conflate being a master with being a monk like god where we have 1000 steps to reach our hut on top of the mountain. The reality is: being a master is more like being a self-aware student. You can look at a goal and then plan out how to tackle it. Being a master doesn't mean you can do it or accomplish it.

I think computing is becoming a lot like medicine where the things we build and study are escaping our grasp to fully comprehend. Instead, after some schooling and some resident program, we become practitioners.

No comments:

Post a Comment