I am a programmer and architect (the kind that writes code) with a focus on testing and open source; I maintain the PHPUnit_Selenium project. I believe programming is one of the hardest and most beautiful jobs in the world. Giorgio is a DZone MVB and is not an employee of DZone and has posted 637 posts at DZone. You can read more from them at their website. View Full User Profile

Lessons learned from the Code Retreat

12.10.2012
| 2573 views |
  • submit to reddit

I coached at the Milan edition of the Global Day of Code Retreat on Saturday; here's what I learned during the experience. The day consists of 6 1-hour iterations on the implementation of the Game of Life, but the goal is not producing, just learning.

The philosophy

Gabriele Lana made an introductive talk to explain the reasons behind organizing and participating to a code retreat. In his view, a developer that has only been trained to code in a quick&dirty fashion, can become quick&clean if he invests in his skills. However, being a professional means that you can ethically train only out of your daily job.

Moreover, deliberate practice must be:

  • challenging, targeting a non-trivial goal.
  • Repeated, in order to automatize tasks and reasonings at the brain (thoughts and approaches to a problem) and muscle level (touch typing).
  • Provided with feedback, in order to discern the insights from the false tracks.

Ideally, the problem of implementing the Game of Life should vanish: it's the approach that counts and varies at each iteration. So, code is deleted at the end of each iteration as we do not run a 10-kilometer circuit to get somewhere (were we started) but to exercise our bodies.

Variations

Even when deleting the code between iterations, you're not sure to not carry on design decisions from an earlier period, being primed by a solution. For example, you may have a knack for a Generation class that continues to come out.

So after the first two iterations, variations are picked at random for the participants; for example:

  • change programming language.
  • Whoever has written his first test on a Cell object, must now start from a Game object, and vice versa.
  • A constraint is imposed on the code, such as using no return statements (or public fields).
  • The focus is placed on investing on a particular tool: not touching the mouse to learn keyword shortcuts, or learning to use your new IDE as Jacopo did.
  • Instead of coding, only discuss design with the help of CRC cards.
  • Change paradigm: instead of an object-oriented solution, try a functional one.

Solutions

Solution are almost never finished, but that's not the point. If you stretched your capabilities and got out of a comfort zone, the training has been effective.

If you're interested, this is an object-oriented solution from the first time I fully solved the problem (not during the code retreat, but the week before.)

During the 6th iteration, with Gabriele and Jacopo watching over my shoulder (apiring? Triading?) and fixing my typos and inversions, we wrote a PHP functional solution that fully implemented the game and its visualization. In this case, the focus was on looking for the minimal solution and shorter time to market. Of course, after the iteration I deleted it. :) The comparison between the OO and functional approaches to Game of Life is a story for another day...

Possible improvements

Variations are the key to keep a code retreat efficient after several hours of coding, but it's difficult to get everyone out of their comfort zone. For example, many participants changed their programming language at each iteration, but not their approach to the problem (as a consequence, only learning new syntax, or never step on the uncomfortable Java territory).

Several proposals have been made to enlarge the variations space for all participants:

  • impose a programming language for the whole duration of the code retreat (it doesn't matter which). This way, variations are focused on using only/not using mocks, dropping returns and ifs, and other design constraints.
  • Change the language each time, in order to learn new idioms from functional (Haskell, Clojure), OO (Java, PHP, JavaScript) or esotheric (SQL, Excel) languages.
Published at DZone with permission of Giorgio Sironi, author and DZone MVB.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)