Why Practice?

This evening while talking with my wife about my the TicTacToe game I'd been building as a practice, I found myself saying things about practicing I understood implicitly, but hadn't stated explicitly. So here it goes!

The Big Picture and the Start

Reflecting on the TicTacToe game revealed several parts of the utility of practice. The first was a common challenge; figuring out how to start. It wasn't immediately obvious to me how I would implement the computer player in the game. I practice to get exposed to common patterns and strategies so when I find myself in unfamiliar circumstances, there's a chance I'll be able to draw upon previous experience to find a way forward. While it's rare there is will be a perfect fit with previous experience, becoming comfortable with being asked to solve non-obvious problems is also of great value.

Although TicTacToe seems like a simple game, it can be difficult to explicitly state the strategies one would want to implement for a computer player. I took the opportunity to teach and play the game with my five year old daughter several times before deciding on a set of strategies for the computer. It made me realize that in much more complex systems, it would behoove me to experience new problem domains as much as possible before planning and implementation. Small iterations and user stories help to make explicit the assumptions customers often take for granted, but when possible, dog fooding and ghosting potential users is ideal.

The Details and the Grind

The other purpose of practice is to be as rigorous as possible with best practices and processes. While this sounds obvious, often times practice and the problem at hand may not seem important enough to be rigorous. After implementing the first classes of the TicTacToe game and being able to hold the whole solution in my head, I found it very easy to get more sloppy with my TDD cycles. Because I thought I knew the solution, I wasn't as dependent on listening to my tests for feedback as how to proceed. Clearly, this is a dangerous practice. One of the best solutions to this is pair program. Pairing reduces the chances that you'll cut corners and highlight implicit assumptions you've made that may not be shared by the team or customer.

While it's nice to say that pairing solves the problem of sloppy programing, who wants to pair with a sloppy developer? The purpose of practicing with simple problems and familiar domains is to develop the discipline to be rigorous in the face of complex problems and unfamiliar domains. If you cannot bring forth your best effort when things are easy, it's highly unlikely you'll be able to deliver the best possible production code.

Have Fun!

Although it seems trite, practice can be fun. By involving my daughter as a tester of the game, we both got something out of it. I could see more clearly what I needed to do to make the game useable and fun. It gave me a purpose for pushing myself to have fun with the practice.

Summing Up

• Practice getting comfortable solving non-obvious problems.
• Practice common strategies, patterns, structures, and algorithms for problems.
• Practice looking at problem domains through the eyes of a developer.
• Practice a rigorous workflow so when dealing with complex domains you're not distracted by the details of developing.
• Practice for fun!