A Case for Rough Draft Code
Why your first draft of a project should be a bit messy
Clean Code
I have mentioned in my other articles I recently started a software developer apprenticeship. As part of this apprenticeship, we read several books in tandem with coding up projects and learning new languages.
I’m often humbled when I think I have a general understanding of a subject, but after further exploration, I realize I have barely scratched the surface of all the knowledge to gain. This is the exciting place I find myself now while reading Clean Code: A Handbook of Agile Software Craftsmanship¹.
What I want to write about today is “rough draft code.” Most of what I will share here I have learned from this book.
Perfectionism
As a perfectionist by nature, I used to think that the first time I coded a project, I had to get it all right. Even before writing one line of code, I felt intimidated by all the work awaiting me. I thought whatever I wrote, I was essentially writing it permanently — whatever I came up with right away was the way it would remain. It was like I couldn’t see the trees because I was so overwhelmed by the thought of the forest. Due to this mindset, I would get blocked frequently. Instead of simply starting small and letting the code evolve, I was stuck trying to construct the perfect implementation.
What I have learned from this book (and my apprenticeship) is a different tactic. We can use TDD (Test-Driven Development) to drive our project and start with small, “less than perfect” code. TDD allows us to succeed with this practice because you can simply isolate what you are currently trying to accomplish. Of course, this will often change as the project progresses. This way of writing code lends itself nicely to TDD — tests cover all your “messy,” rough draft code.
Your code will never be perfect in its first iteration. It will most likely take several refactors, walk-throughs, and reviews to get the project to where you want. And if you have tests, you don’t have to fear making changes to your code!²
Now, when I’m coding, my goal is to write the smallest failing test — make it pass, and then refactor as necessary (red, green, refactor). Kind of like a kata, the project begins to reveal itself to me as I progress. This way of coding takes more effort and thought in the short term as you start to develop good habits, but it will become second nature over time.
Writing Code Like a Story
Your code should ideally read like a story. Your functions should be named appropriately — indicating the single action they are taking. Your variables should be clear, distinct, and intentional. Your functions or methods are your verbs. Your classes and variables are your nouns.
“Master programmers think of systems as stories to be told rather than programs to be written.”³
You wouldn’t expect to put pen to paper (or fingers to keyboard) and write a masterpiece on your first try. (Unless maybe you’re the next Shakespeare, but I’m guessing even he wrote rough drafts).
“When you write a paper or an article, you get your thoughts down first, then you massage it until it reads well. The first draft might be clumsy and disorganized, so you wordsmith it and restructure it and refine it until it reads the way you want it to read.”⁴
If we think about writing our code the same way we think about telling a story or writing a blog, this mindset gives us a good bit of freedom. I write several rough drafts before ultimately publishing an article. I’ll go through several iterations before I’m happy. So why should our code be any different?
Rough Draft Code
We can think of coding our project the same way we write an article. Uncle Bob tells us it’s perfectly acceptable to start with long functions, terrible variable names, or one large class. Then, over time and refactors, you’ll see your code in a way that lends itself to being refined. It will reveal itself to you.
“The art of programming is, and has always been, the art of language design.”⁵
Instead of white-knuckling through my code, I can freely write one small piece of the project at a time, covered by tests, with the safety net of refactoring around every corner. With this new freedom in place, I can create a poorly named variable, an ugly, nested method, or one big class on my first go-around. Then, as I go through one by one and refactor, I can begin to extract, split functions, change names, and eliminate duplication. More often than not, the ultimate broken-down structure becomes more apparent over time.
It takes effort and concentration to create a final product of anything. So, again I ask (myself, or perhaps anyone who struggles with this same potential blocker), why should coding be any different?
Go Forth and Code
With this new mindset in place, notice if you approach your projects differently. In the words of Kent Beck, “Make it work, make it right, make it fast.” In other words, first, we make it work, then we make it right. Happy coding!
[1] Clean Code: A Handbook of Agile Software Craftsmanship written by Robert C. Martin (“Uncle Bob”)
[2] Clean Code Ch. 9
[3], [4], [5] Clean Code Ch. 3
