At the end of a long day writing code with a pair some time back, we were not quite finished with the task we had started that morning. We’d been pounding our heads against a problem and was finally making some headway. So much so that my pair really wanted to shelve the work for safe keeping, just in case I got hit by a bus. I looked at her and suggested that we revert our code to where we started and get a fresh new start tomorrow, with the knowledge and insights that we had fought for and gained today. After my pair stopped laughing and realized that I wasn’t kidding, she cried, “We’d lose a whole day’s worth of coding!” We had some discussion around the idea of reverting but she adamantly refused to do so. In fact, she wouldn’t let me leave the building until I’d shelved the code. Looking back on that instance, I remember that I once thought the way she does. I now know, beyond a shadow of doubt, that she’d never attended a CodeRetreat.
For the neophyte, a CodeRetreat (to steal shamelessly from my own previous post) is “a structured, one-day event where developers revisit the fundamentals of writing code with the express intent of becoming better at their craft.” During a CodeRetreat, there are a few simple rules to follow:
- Everyone pair-programs.
- Pairs will spend each hour-long session figuring out how to solve the same problem.
- At the end of each session, the code is deleted and the process starts all over again from scratch.
- Strive for a simple design.
In retrospect, my pair must never have been to a CodeRetreat because she’d never felt the gut-wrenching a newbie feels the first few times his or her precious code is completely destroyed. But, it turns out, this is a good thing. One of the myriad of things you can walk away from a CodeRetreat with is the revelation that your first code solution for any problem is far from optimal. Maybe you already know that your first pass code isn’t the best or possibly the right solution. Perhaps maybe you’re even enlightened enough to leave a few comments like “needs refactoring” or “optimize this later”. I have yet to meet anyone with the confidence, after working on code for a day, to revert incomplete code and start fresh/new the next day… Unless, of course, that person has attended a CodeRetreat.
After reading this, you may think to yourself, “That’s preposterous, you’ve been writing code for a day, keep the code, refactor it (if you must) but what you have is a good enough base to start with.” Or “It’s 4-8 hours of coding and you’re going to just throw it away?” Or “Haven’t you ever heard of ‘sunk cost’?” There are surely Product Owners and managers whose heads might explode if you responded to them, “Yup, tough day today, but I figured out how to do it…and I reverted all my code, so I can start new tomorrow.”
But what if that’s actually the right thing to do? What if I talked at you about it for an hour with a PowerPoint outlining why it’s more efficient to do so and had the statistics and studies to back it up? How likely, and how confident, would you be to defend that approach to your manager then? If it were me: “Not so much.” To my logical brain, the premise may make sense, but to my primitive brain it’s “No WAY! Gotta deliver!”
The problem is, despite the analogies that are likely to fly around, building code is only somewhat like building a house. You are creating something, for example, that takes up time and resources to create, and you can sell that product. However, let’s look at it another way. If, say, you’ve never built a house but you thought you had the resources to do it yourself, you might be able to piece it together, with a lot of trial and error, YouTube videos and the occasional pointer from your know-it-all father-in-law. The end result, built of your blood, sweat and tears, might not be pretty but it might be livable. You wouldn’t dare turn to your building crew and say, “Now that we’ve figured out how to build it right, let’s break her down and start from scratch!” And you would be crazy to do so because all of those materials are “sunk”. Not to mention, even if for who knows what reason you did want to start from scratch, it would take almost as long to break it down if you were intending to reuse the same materials. This is where the misnomer “building” code or code “engineering” gives people the mistaken assumption that you’re stuck with whatever you build the first time, because the resources are “sunk”. The fact is that only your time (and your employer’s wages) are sunk and, further fact, you can in fact recoup both, potentially, by producing even better code the next time, with the problem space more clearly defined in your brain. This time, you’re less likely to build your bedroom under the laundry room this time, and you won’t forget to leave space for a chimney over the fireplace. With code, those learning opportunities really do contribute to the overall integrity of the code.
This lesson, while surprisingly simple, goes against so much conventional “wisdom”. It’s a lesson whose time has come though.
One way for coders to really learn it for themselves, hands-on, is at a CodeRetreat. This one-day event allows developers to hone their skills in a safe and fertile learning environment without the everyday “pressure to deliver”. The structure of the day, the people attending and the support of knowledgeable facilitators provide a powerful catalyst to encourage testing and surpassing the boundaries of what we’d normally feel safe doing.
The base lesson is this: none of us are at our best the first time we tackle a problem. Whether it’s our understanding of the problem, the approach we pick or even simply the code that we write, one or all of these things will be wrong with the code that any developer writes to solve any moderately complex problem. A CodeRetreat really drives that point home, but how?
Each session of the day is focused on a solution for Conway’s Game of Life. Oh sure, the facilitators tend to throw in some curveballs in the later sessions, but it’s still the same base logic problem. However each session begins with a new coding partner that you have to connect with and figure out ways to communicate with, establish common frames of reference and come up with a unified strategy to develop to. You also start with a blank slate, because all code written previously gets deleted. Yet somehow almost every session you get further into the code solution and your code is almost always better than the previous one.
At the end of the first session there’s generally some frustration about starting anew or consternation (“But we made so much progress in that session…”). These thoughts and feelings quickly fade away as developers learn that their approach or their assumptions were not right. Sometimes, they find out that they were actually very wrong. Sound familiar with real life? Participants quickly accept that the reset gives them a clean slate to try a new approach or correct a design flaw due to incomplete assumptions, without any substantial “loss of productivity”.
Here’s where one of the hidden lessons of a CodeRetreat emerges. Each session forces the reset and a new start for the code. Everyone learns that this reset, which can be frustrating at first, is actually giving you the chance to do/write a better solution the next time. No more dealing with false code paths based on false assumptions cluttering your solution. Do that enough times, maybe five or six, and even us stubborn developers might learn a new trick. In fact, it’s not uncommon for me, at the end of the day retrospective, to ask people, “What do you think you’ll do the next time you’re not finished with your code at the end of the day’s task? Do you think that, if you revert your code and start new, you might do it better and faster next time?”
I started out by saying this is a hard lesson to learn, but actually it isn’t at all. Once you see how far you move away from your original assumptions and your first “false starts”, speaking personally, I learned pretty quickly. Now I have to balance the perfectionist in me with the finisher in me. And that’s where the problem really lies: We can know that we don’t write things the best way the first time, but we have other pressures that weigh on our development like the need to deliver code and finish tasks. There’s also the good intent to come back and refactor later, when we have time, but we know how often that pans out.
CodeRetreats give you back your edge by helping you come to terms with two simple facts: you don’t usually get it right the first time, and to be really good you have to put time in to really honing your craft.