David Ross's Blog Random thoughts of a coder

Your an IT manager at a small manufacturing company and have a staff of 5.  In two months time your team is slated to replace the internal HR web site that is currently running on Classic ASP. The Architect and lead developer have selected the following software stack:

• ASP.NET MVC
• Entity Framework
• .NET 4.0

The team is very experienced however for the last 2 years they have been maintaining the sales web site which runs on ASP.NET and .NET 2.0.  Due to production support constraints you are unable to send the team on an externally run training course… 

Over my career I have seen this situation played out far too many times.  Teams spend the first couple of weeks or months learning on the job and end up having to replace most of the code that was written at the project’s commencement.

A Coding Dojo is a meeting where a bunch of coders get together to work on a programming challenge. They are there have fun and to engage in DeliberatePractice in order to improve their skills. (ref Coding  Dojo)

What’s the best way to learn a new technology, pattern or programming language?  By playing, doing, prototyping, fiddling and experimenting with it.  What’s the best way for a team to learn a new technology, pattern or programming language? By doing it together!!

Coding Dojos rules:

• A challenge isn’t solved or challenge beaten without code i.e. A paper design doesn’t cut it
• Code doesn’t exists unless there are tests
• Work as a team/hook up with an expert

Formats:

• Prepared Kata – Presenter solves the problem in front of an audience but can/should/will change his solution based on ideas/enhancements/feedback from the audience
• Randori Kata – A pair of developers are selected from the audience.  The pair work together together to solve the problem and every 15 or 20 minutes one of the pair is swapped with another audience member.  Preferably everyone in the audience should have an opportunity to sit at the computer and bang out some code.

In a Coding Dojo “meet up” the Randori Kata can be intimidating for a new comer – No one wants to get a mental blank in front of a group of people or have a group commenting of their coding style.  This should be less of an issue in a work environment where the developers already know each other.  In fact the format ensures that everyone participates in the learning experience.

Workplace <Insert Technology here> Coding Dojo:

1. Prep work
   1. Find the most experienced person in the team who has already used the technology
   2. Ask them to create a 30 minute demo (PowerPoint is fine) where the technology is used
   3. Ask them to create a “Cheat sheet” that consists of 3 or 4 pages of generic code snippets that show how the technology is used for different situations
   4. Create a coding problem (don’t tell the team or the person that wrote the Cheat Sheet) that can be solved reasonably easily using the technology and ensure that the solution to the problem utilises items within the Cheat Sheet
2. Kata
   1. Have the team member present the 30 minute introduction demo
   2. Provide everyone with a copy of the “Cheat Sheet”
   3. Spend 10 minutes discussing the technology and the contents of the Cheat Sheet
   4. Explain the coding problem
   5. Randomly chose a developer to join the presenter – Coding in a pair is less stressful
   6. Have the presenter/colleague pair start solving the problem (make sure they write tests)
   7. Following Randori Kata rotate through the developers every 15 to 20 minutes
   8. After two hours of coding stop the clock
   9. Spend 10 minutes in a discussion
      1. What was hard?
      2. What was easy?
      3. How confident do people feel?
      4. What else do we need to learn?