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.

There has been some buzz around the office recently about getting some TDD training. I figured I could drop my 2¢ in with an example of how it helps me. It’s not about bug-free code. Or even faster coding. To me, it’s about reducing rework.

I have a dirty secret. I’m not always awesome. On occasion, I’ve been known to write a bug. Not often! Most of the code I write mostly works, so I’ve got that going for me.

When I had to rewrite a subsystem of our application because of a drastic change in the requirements, I wasn’t worried. I had the parts that needed changing isolated and I had an interface that would work. I just needed to gut some classes and start over. And write some tests showing the behavior I wanted that section to have. For those playing the home game, this is related to the “London School” of TDD and BDD.

It worked flawlessly. Until our test lead thought of corner cases I had not considered. That’s his job, and he’s good at it. But here is where the awesome came in…

I added some test cases to some itty bitty logic classes deep in the code to handle those new behaviors. Then I made ’em pass. Easy.

The best part is I knew I did’t break the cases I had already covered. That means this bug won’t cause more bugs.

Contrast this with a project I was working on a bit over a year ago. It was very hard to wrap test cases around it because of how I had written the interface to the UI. We played ‘whack-a-mole’ with the same few issues for a few iterations.

And that’s what it’s about. I don’t want to fix code that was working. I want to write code for features and cases that aren’t already there.

Several years ago, I was listening to a podcast and they were making fun of a friend of theirs. The friend liked closing music on podcasts, because it gave him time to pick a new show before that one is done. My mind boggled because I had already solved this problem using iTunes smart playlists.

Fact: Each podcast has a ‘media kind’ of podcast when imported via iTunes.

Fact: Each podcast file has a play count that starts and zero and increases once the file has been played all the way through. If you stop, skip, and go back the play count is still zero until you finish the file. Listen on you iPod then sync and the count goes to 1.

Fact: It’s trivial to right-click a file in iTunes and reset plays

Combine those first two facts with a ‘smart playlist’ with live updating and I always have a list of fresh new podcasts.

Bonus Fact 1: If your car has an iPod interface, naming some playlists 01_* through 05_* will control which order the playlists happen to appear on your 6 disc changer interface.

Bonus Fact 2: If you use an iPad, iPod Touch, or iPhone this list will update as you play through them on that device. Millage varies on other iPods.

I have no idea why now is the time I have a bee in my bonnet to write this down.

I’ve been leading a brown bag session at SEP where we gather as a group and write an iPhone application. The main reason isn’t to learn everything about the iPhone. I want to aclimate to the Cocoa development environment. There is enough about iPhone and Mac development that are very different from Java and .NET that I want to make sure we don’t have to learn from the ground up when we start coding with this stuff for real. When talking with Scott Hanselman, John Sonmez called it a parallel universe where everything is slightly different.

That said, We did a session this past Thursdays and I totally borked it. I ruined it from two sides; I didn’t discuss ANY of the concepts regarding either Storyboards (because I don’t know them, maybe?) or UITableView, and I hit a snag with the demo because I dove straight and hard at the code without thinking about my audience. Oops. I promised them a blog post once I figured out what went wrong.

First, the session I will be talking a bit more about the concepts behind the Storyboard. I’ll also be talking about TableView concepts. It might be the whole session, but it should be worth it.

Now, where did the code go wrong? Look at this portion of the Second iOS App tutorial. I missed a few things in it. The default table set up for a Master/Detail view is to use static cells. I needed to change this to a prototype cell, lay it out, and dequeue it using it’s name. The error was coming from a mismatch between telling the table to use a list of items and telling it to show a list of specific cells.

I’m looking forward to our next session, and hopefully it will run smoother now that it seems we’re getting closer to being on the same page.