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.

It seems some of my esteemed colleagues decided to have a “Blogging” contest. They have, therefore, pressured me in to posting a couple of blog entries. I hates them so.

I’m a regular at the Indianapolis Code and Coffee. If you’re local, join us at 7:00 am on Thursday! Korff and I started doing some Project Euler problems in Haskell this week. Matt Swanson made a comment about Euler being way focused on math and wanting Project Euler for “practical” things. His idea of practical was, as an example, displaying a list of items on a web page. Hrm… Reminds me of Ruby Koans or Rails for Zombies. I’ll get to that post in a few days.

I’ve done some of the Euler problems and they are really math oriented. The point of these exercises really is to think about math and the relationship of numbers. What a programmer can take from these exercises is focusing on algorithmic implementation and optimization. It is not that we solve it, but that we tweak and re tweak our implementation to be faster or more expressive. It is a great way to learn about a programming language in the small.

Koans are small guided steps. Where Project Euler expects a single number as an answer with out regard to HOW you got the answer, koans are all about the journey. They are usually language specific. They are a series of automated test failures that allow a conversation of learning similar to The Little Schemer. Again, koans are about learning small concepts a little at a time.

Katas are also about the journey. The problems that katas use are actually incidental. It isn’t important that I’m dealing with an incomplete simulation of a bowling game, or pricing some children’s books. It is about the things you do around the problem. Katas are about the red/green/refactor cycle.

All of these have their place and appeal to different people for different reasons. But they deal with software in the small. Like writing short stories, they teach you how to communicate more effectively. These lessons can be taken to larger structures, but they can also teach a kind of tunnel vision. A short story is not a novel and their structures are different. With that caveat out of the way, enjoy yourself. If you’re pressed for time, they can be great bite-sized puzzlers and exercises. They can also teach you to take care with the smallest parts of your code.