Code Katas and Programming Exercises
We all know that the way to become a better developer is to both study and practice our craft.The reading happens from books, blogs, news sites, and tutorials.
The practice? Sure, there is the day to day coding. Sometimes, we really need something with a scope beyond the day to day. You already know that really well anyway.
I have always steered junior programmers to TopCoder. The idea is that the speed of competition can stimulate faster learning. Even if they don't compete, the practice areas are just plain good practice.
Project Euler also offers up a big set of small programming challenges. Just the thing to play with on the lunch break.
Another good site is Dave Thomas' CodeKata blog. I really like the idea presented by Dave. Take a problem per week. Create a different solution (read implementation) each day of the week. Let's face it, we all know that most problems can have many different solutions. Why not explore the possibilities?
Here at the office, I've started a (completely voluntary) group version of the code katas. On Monday, I send out the problem (to a mailing list). Everybody works, mostly independently, on a solution per day. On Friday, we all get together over lunch and review each other's solutions over chips and salsa.
I have observed many benefits to this technique. Everybody learns by seeing other people's solutions. Many of the junior developers go around asking questions as they work on their solutions. Since it is only an exercise, most everyone has lost the fear of the code review. Everyone is claiming to have fun. Communication between development teams is up. Code quality all around is improving. Participation is increasing (though that may be due to the salsa).
Since we are a java shop, I send the problems out with a set of jUnit tests. One test per day. I am also encouraging TDD by getting everyone to write test cases instead of using System.out.println
The change is slow at first. The question is "why not just print it out?"
My answer, "What do you do after you get everything working?"
everybody's answer, "delete the print lines", and they start to realize that my question was a set-up.
This brings in the key point (the Socratic Method rocks). Those prints contained information, knowledge about how a piece of code is supposed to behave. When it is deleted, the knowledge is lost. There are also the all the standard arguments, like confidence in refactoring. For many, it takes some effort to change to a different method of thinking but, it appears to be gradually happening.
As the use of these exercises continues, I hope to introduce other systems for testing and development like, EasyMock, Fit, and jBehave.
So far, it looks like daily programming exercises are a good technique for code improvement and enhancing team cohesion. I'll post updates to report progress.
Update:
I've just been informed of another programming contest site, like TopCoder, called Sphere Online Judge. Thanks llimllib.
Update:
I've just read a post, Kata and Practice that shows one person's experience. An interesting read and it mentions another resource, The Coding Dojo.
Labels: community, continuing education, development, practices
1 comments
