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.

Bus Factor = 1

I haven't been as prolific on this blog as I had hoped a few months ago, but thats how life goes. You get busy with school and you don't have time to write. Since I have a few minutes I thought I would write quickly about something I learned at the end of this quarter at Neumont.

Always bus-proof your projects.

Many of you developers know what I'm talking about, but I'll explain what I mean by "bus-proof." Think about a development project that you have been on for a moment. If someone on your team was hit by a bus, would the project be able to continue? How many people would have to be hit by a bus until the project couldn't continue? Thats basically the entire concept of the bus factor of a project.

I learned the hard way this quarter that you should always bus-proof your projects. The project I was working on this quarter had a bus factor of 1. Can you guess what happened? *dramatic pause* He got hit by a bus. OK, so he didn't really get hit by a bus but he wasn't able to work on the project anymore or even help us out with any questions we had.

After he got hit by the bus we were basically SOL after that.

Although the project ended up being a complete disaster, I did learn something from this experience. I found that there are a couple of different ways that you can help to bus-proof your project

Always comment your code.
If your code isn't commented then the next set of developers behind you will have no clue what you were trying to do. Always comment anything that you had to hack around or make a decision on why you wrote the code the way you did. This way no one has to guess your intentions in the code.

Document your decisions
You are going to make many design decisions in your project that isn't going to end up as a comment in some source code.It makes life much easier if you just document why you decided to use pattern x over pattern y or why you chose to use Guice over Spring. You get the idea.

Have a roadmap
One thing that I have found is very useful to a project that is going to be around for any amount of time is the roadmap. By documenting what you plan on doing with the project and give it direction, it is much easier for new developers to see where you have been and where you are going.

Limit the scope of your work
One of the easiest ways to give your project a bus factor is to allow one person to have their hands in the whole project. It is easy to see why this is a problem because if only one person has a grasp of the whole project Murphy's Law is going to take its toll. There are a couple of solutions I see to this problem though. First you have more than one person with an intimate knowledge of the project and second... DOCUMENT YOUR PROJECT. (See the tips above)

As you can see, these are just a couple of ways you can help bus-proof your project. As a good programmer you should always be looking for different ways to keep the project's bus factor down. I definitely learned the value of keeping the bus-factor down at the end of this quarter.