Four Key Reasons to Learn Markdown
Back-End Leveling UpWriting documentation is fun—really, really fun. I know some engineers may disagree with me, but as a technical writer, creating quality documentation that will...
You Must Teach To Be Taught
Waaaayyy back in December, I had the pleasure of attending a code retreat. In that post, I discussed what I learned.
This month, I had the pleasure of facilitating a code retreat a few weeks ago. Thanks to Highgroove, TapJoy, FourAthens, and my co-coordinator Travis Douce, the Athens Code Retreat was a resounding success.
Also, a special shout out to our Code Retreat homies in South Africa led by Corey Haines, who handed off the baton to us late in their day but early in ours.
Read on to find out how lessons learned from facilitating compares to attending, how the general “You” actually means “I” in the blog title, and how many times it takes (me) to learn the four rules of simple design.
The purpose of a Code Retreat is to get better, to practice one’s craft in a setting without the pressure of “getting it done, yesterday(tm).” Throughout the Code Retreat, we emphasize the 4 rules of simple design. Another way to paraphrase them:
- Tests pass.
- Good naming.
- No duplication / Don’t repeat yourself (DRY).
- Small.
To facilitate self-improvement, we dedicate the last session of the day to the closing circle. In the closing circle, three questions are asked of every participant.
- What did you learn?
- What most surprised you?
- What are you going to do differently going forward?
In my original blog post, I boldly claimed that one could code the Game of Life in 45 minutes if and only if they practice four or five times and skimp on tests. Oh, how wrong I was!
One pair, which included Andy, managed to write a completely functional version in 30 minutes. They even had time to invent their own spaceship. How is this even possible? Other groups took the fast and loose approach. “We know the problem domain. We have the technology. Tests? Where we’re going, we don’t need no stinkin’ tests!”
What was the first pair’s secret sauce? TESTS! GOOD NAMES! DRY! SMALL METHODS! SMALL CODE BASE! Amazing!
I learned magnitudes more facilitating than I did attending. I saw novel approaches that impressed and stretched my understanding of the problem domain. I saw good coding practices win out over the quick and dirty style again and again.
What have you learned when teaching that you didn’t learn as the student?
