A long time ago I promised to talk about HOW to do deliberate practice. There, I DID cover what it meant to me, but just to sum it all up in one place, I’ll repeat myself some.

Deliberate practice is the repetition of specific actions to gain feedback for altering behavior.

I have an IDEER about making a good exercise. You can build one out with the following Parts.

• Identify the skill set you wish to improve
• Devise a task or action that will isolate and expose the skill set.
• Execute the task. Preferably in a manner that will allow you to review your work.
• Examine your work and review it. What do you want to do differently next time?
• Repeat. Once you can do it perfectly on demand, make it harder.

Great. Now for what that looks like in the real word? Well, it kind of depends on you. Here’s my non-exhaustive list.

Kata

This is the obvious example. A code kata is a TDD exercise for an essentially toy problem. A great example is Roy Osherove’s String Calculator example.

Why are Kata interesting? First, if you’re learning TDD, they give you a place to learn the rhythm of Red, Green, Refactor. After that, they can give you a place to explore how test choices effect the implementation and how the implementation can effect the test choices. It’s also a scaffold for other skills such as Keyboard navigation, refactoring tools, autocomplete, and other techniques adjacent to development.

Archetypical Project

This is a project that is simple and well known. The purpose is not to be interesting in the domain, but in the implementation. It’s a blog just like every one has done before but this time in Node, or Rails, Clojure, or using DCI or DDD.

Pet Projects

This is a tool over which you have complete ownership. Also, you aren’t on a time table to ship. If you sell a product, that might not count. Here’s why they are important. With a pet project, you can radically rewrite parts of it to explore new concepts. How does immutable state work with this problem? How can I use Ractive programming in the View Model? Can I migrate some or all of the data storage to a NoSQL system? This would be a maintenance nightmare for production code, but for a pet project, it’s a branch and some spare time learning valuable lessons.

Critical Reading

Writer’s read one another’s work. They look at aspects of characterization, pacing, use of language, and much more. So, why do we want to read other’s source code? To understand all those aspects of design that we should be looking for in our own work. Do the abstraction leak? How effective are the names in quickly communicating understanding of architecture, concerns, and responsibilities? How well does it handle dependencies? How easy is it to change the code? What can you do to improve this?

This is not a code review. A code review should cover these, but also be much more aware of things like correctness and local dialect / idioms.

Reductio Ad Absurdum

This is my favorite! It’s not about the right way, it’s about an extreme way. If you did this in my production code, I would slap you silly. But if you’re doing it to understand linq, or the use of lambdas, or immutable state. How far can you push the SOLID principles, what if every METHOD had a single responsibility? How about writing a class with no references to a concrete type only Generic types.

Mindfulness

This isn’t about practice, but about getting feedback in everything you do. If you don’t pay attention to what you do every day, understanding the tiny subtle variations you have day after day and their effect on your work. This is the essence of deliberate practice. If you are mindful of what you are doing, then you will strive to do it better next time.