On my recent trip to San Diego, my co-workers and I participated in something called a Code Retreat. It reminded me of my days in art school, when my professor would instruct me to hold my pencil in odd ways while drawing, which broke my reliance on muscle memory, and forced me to focus more on the process of mark making and see my task in a new light.
A Code Retreat is kind of like that. You pair up with a buddy, and write some basic software as a team. Every 45 minutes you have to delete all of your code and start over. There are other limitations too, such as you cannot speak to each other for one cycle, or every function you write can be no more than 3 lines, or you can’t use `if` statements or any type of loop. These limitations force you out of stale habits and can profoundly change your perspective on tasks that have become too rote and rigid.
My biggest take-away from the retreat, which was expertly run by the legendary Michael Douglas Adams, was a newly minted respect for test-driven development. One of the limitations of our game, was that it needed to be written in Node.js, and we had to follow the standard patterns of test-driven development. From Wikipedia:
Test-driven development (TDD) is a software development process that relies on the repetition of a very short development cycle: first the developer writes an (initially failing) automated test case that defines a desired improvement or new function, then produces the minimum amount of code to pass that test, and finally refactors the new code to acceptable standards.
In my opinion, the short, quick iterations of TDD make for a cleaner and more logical end product where other developers can easily follow your process. My hopes are to inject these lessons in my day-to-day work.
Fellow developers: if you ever get the opportunity to do a Code Retreat, jump on that train fast! You’ll be surprised what you learn when you hold that pencil differently.