Sunday, August 31, 2008

My Coding Dojo

After reading Jeff Atwood's post on code kata I decided that I was going to start a Coding Dojo at work so I could improve my coding skills and learn new tricks from other developers. Since this is an ongoing process, I'm going to document our experiences here on my blog.

Ideas

After reading Jeff Atwood's code kata post, I followed a few of his links and read about Coding Dojos and where the dojo got its start: Dave Thomas' 21 Code Katas. Pragmatic Dave's code kata really got me excited and interested in how I could continually become a better programmer through disciplied practice. Work alone is just not enough, you have to sit down and actively try something new and fail at it a few times to learn. Work does not allow you to do that often, if ever. Now that the seeds have been planted, I need to figure out where to go next. I thought it might be a good idea to look for local dojos.

Nothing in my area and nothing I could find at work either.

OK. Now what?

New Dojo

It was time I started my own dojo, but how was I going to do that? To help me figure that out, I wrote down some ideas I should look into while I started this dojo.
  1. What do I want from the dojo
  2. How will the dojo help others around me
  3. How will the meetings go
    1. What kata should we use
    2. Meeting styles e.g. Randori Kata, Prepared Kata
    3. Meeting length
  4. How often will we meet
  5. How many people is the best size for a dojo
Using these guides I had written I began to piece together my concept for the an IBM code dojo on my team wiki. Piece by piece I began to assemble what a code dojo would mean to me and my fellow IBMers. Along the way, I came to the conclusion that when starting a coding dojo, there is one important idea to remember:

Above all things, do what works best for you and your dojo.

What works best for my dojo may not work best for your dojo so don't feel you have to work the dojo in any sort of prescribed way. The best part of a coding dojo is that it is flexible and adaptive to the needs and desires of the members of the dojo. If you don't like doing the kata, then do something else that helps you learn and grow as developers.

First Meeting

After working out what I wanted the coding dojo to be for me, it was time to invite some people to join the dojo. Starting out I got about five people to join, by keeping the numbers small I can work with the dojo better so we can work out any kinks in how our dojo will operate.

Before our first meeting, I had come up with some points I'd like to bring up. These might help you to work out a first dojo meeting as well.
  1. What I'd like to get from our dojo
  2. A brief description of how kata might work for us
  3. What everyone else would like to get from the dojo
  4. How often we should meet
  5. Introduce a sample kata (see Code Kata for some ideas)
  6. Introduce the dojo wiki
  7. Plan next dojo meeting and kata topic
  8. Write up a meeting retrospective
    1. What went well
    2. What didn't go well
    3. What could we improve next time
After going through this agenda with the dojo, we had some great feedback on what we would like to achieve individually and as a dojo. We also got much of the administrative sort of work (meeting times / location) out of the way quickly with little hassle

The Future

My dojo will be holding its second meeting in the next few days, and as we grow and learn as a dojo I am going to document our progress here on this blog. As I document our progress, I'm going to be writing in a way that  others wishing to start their own dojo have some insight and suggestions on how to go about that. So for now, farewell and I'll be writing about our dojo in the next couple of weeks.

Thursday, August 14, 2008

Kicking Ass

Creating Passionate Users was by far one of my favorite blogs I used to read, but unfortunately it has gone dark for now. Fortunately, Kathy Sierra has started microblogging over at Twitter and its great to read what she has to say again. Recently she tweeted something that really got my attention:

We tell our authors: "Don't focus on making your BOOK better... focus on making the READER better." Often changes TOC (fewer topics) & tone

This got me thinking... What am I doing on my blog to help you kick ass? When I thought about that, realized I wasn't doing anything to help readers kick ass. I had simply put up whatever idea comes to my head. Now I'd like to change my direction and write more on how I can help you, the reader, kick ass. Not only will this help you, but it helps me become a better writer, programmer, and technology enthusiast.

Here's to helping each other kick ass.