We added daily warmup exercises to our curriculum when we started gSchool.

At first we gave the students a README and said “Go!”. The students responded by hacking out solutions.

We must have given them the impression that the goal was working code.

Our mistake.

Working code is implied. It’s a starting point.

To be fair, most of the students had only been programming for about two weeks when we introduced these exercises. Expecting them to break things down, write unit tests, and refactor their solutions would be unreasonable.

We wanted them to practice doing the simplest thing that could possibly work, so we started giving them a suite of unit tests along with the README.

This was an improvement, but still not optimal. Often the students did not finish the exercises, and we rarely gave them feedback on their solutions.

Our excuse was that we were all crushed under large projects and looming deadlines.

We do regular code reviews on the students' project work, but we rarely took the time to treat the warmup exercises like real code and give them the attention that they deserved.

I’ve been participating in the nitpicking process at JavaRanch since 2006, which has taught me that focusing on tiny details can have a dramatic effect on a developer’s overall code quality.

I created to introduce this feedback cycle into our daily warmups.

We give students individualised feedback on 10-30 lines of code. Then they rewrite it. Wash, rinse, repeat until their solution is simple and expressive. Then they move on to the next exercise.

The rewards were immediate and significant: The students are writing better Ruby.

They pay closer attention to the names that they use for variables and messages. They identify duplication more easily. They choose appropriate methods from the standard library rather than reinventing the wheel.

Practice is about focus, repetition, and continuous feedback.

From the start, warmups were focused. With we added repetition and feedback to the mix.

Within days of launching the prototype, several students were submitting solutions during their lunch breaks, in the evenings, and on the weekend, describing the process as addictive.

We have a lot of improvements to make. We’re learning that the conversations that happen during code reviews are rich and important. Far more important than we realized at first. Right now each submission is ephemeral and isolated. The conversations and the evolution of each piece of code need to be the focus of the application.

Despite its warts, we’re happy about the value we’re deriving from it. If you’d like to do little programming workouts, join us at

comments powered by Disqus

Upcoming Events

  • GoGaRuCo 2013

    GoGaRuCo 2013

    Mission Bay Conference Center

    September 20 & 21 - San Francisco, CA

  • RuPy 2013

    RuPy 2013

    October 11-14 - Budapest, Hungary

Contact Us

(202) 670-2852
(202) 280–1257
1510 Blake Street
Denver, CO 80202 U.S.A

Stay Connected

Get the scoop on upcoming classes.