Red-green-refactor writing

There's a concept in test-driven development called red-green-refactor, which describes three distinct stages that your tests and code go through. The first step is to write your tests in such a way that they describe what you want your code to do. Your code isn't written yet, so the tests start off failing (red). The second step is to write just enough code to pass the tests (make them green). The final step is to rewrite your code so that it is nicer and solves the problem better, while still passing the tests. This is called refactoring.

In writing, you hear very similar advice, though not given in exactly the same terms. It's generally considered useful to write an outline before you start, so that you can structure your ideas without worrying about how exactly to write them. Then you should write. Usually, the best way to write is not to worry too much about getting everything perfect the first time, just spill your thoughts out as quickly as you can. In the third step, editing, you refine those thoughts and make sure you're expressing them the best way.

Why do this? In both cases, it's about separating out the different components of the task so you can focus on them individually. Tests and outlines both describe your goal without going into details, which allows you to focus on design. Writing, of either code or words, is best done without trying to do everything perfectly. Realistically, you can write more fluidly if you're not worrying about polish and minor details. More importantly, you learn a lot from the first draft that you can use in refinement. Finally, refactoring (or editing) is a deliberate process that is much easier to do with detachment once you're no longer stuck on just getting the thing done.

This is particularly relevant to me because I write a lot of both code and words. For a long time, I've wanted to find a way to make that writing easier and faster, and to give it a bit more structure. Test-driven development is something I know helps me to write more structured code. In particular, I find the way you write code when you have already gone to the trouble of thinking through the problem (with your tests) is qualitatively different; it's more structured and you tend to feel a greater degree of control over what you're doing. I'd love to find a way to bring that quality to my writing.

To test this idea, I thought I would just try writing something in the red-green-refactor style. To make it a bit more interesting, I figured I could record what I'm writing and have it play back. This should give you some idea of what it looks like to write to an outline and refactor later. I couldn't find any existing tools to do this, so I wrote my own. You can click the "replay" button below and adjust the speed slider to control how quickly it replays.

I've found it pretty useful to extend the red-green-refactor idea to writing. Certainly, it's been easier to write this particular post than others because I had a structured starting point and could focus on writing and editing separately. This let me get into a flow that wasn't interrupted by thinking about what I wanted to say, or whether what I was saying was polished enough. It strikes me that there might be other areas where this idea could be useful too. Really, anywhere where you would benefit from focusing on one goal at a time rather than trying to satisfy them all at once.