Another Valuable Practice from the Kitchen: Clean as You Go

Today I want to explore another example of a valuable practice I picked up from a non-engineering field. This is another kitchen lesson: clean as you go.

This kitchen principle is essential to me, especially now that I’m a parent. I definitely don’t want to spend what little free time I have doing a bunch of dishes after dinner. I’d rather be spending time on a hobby, playing music, or sitting down to relax with some tea and a nice book. Anything but cleaning!

The way I avoid this is to continually clean while I cook. Thanks to mise en place, I usually have time to load dirty dishes into the dishwasher whenever I don’t need to attend to the stove. I’ve even been known to load a dishwasher, run a load, unload it, and re-fill it during the course of cooking a big meal. Ideally, at the end of dinner, the only dishes left are the serving dishes, plates, silverware, and the pot(s)/pan(s) used for cooking. This can typically be cleaned up in five minutes (or less, if I’m just going to let the pots soak overnight).

Jeff Atwood’s article Programming and Chefs provides a selection of quotes that discuss working clean in the kitchen, but I think this commenter from Michael Feathers’s article on Working Clean nails the point home:

In my college years I was a chef/line cook at a few restaurants. Indeed working clean is a common theme in the kitchen. The term I heard over and over was “Clean as you go!”. “Clean as you go!” wasn’t so much a suggestion, but rather a law. Those cooks who didn’t constantly clean would wind up in trouble. Their workspace would become so messy within a matter of an hour or two that the quality of food rapidly diminished. This problem would progress until the other cooks were forced to step in and clean up. This had a negative impact on the entire kitchen and nobody was happy it happened. Interestingly, line cooks, even without college degrees, were extremely efficient at self-management. Those cooks who didn’t work clean, were taunted, teased, and pushed around until they cleaned up, or quit.

How I Employ This Idea in My Professional Life

Jeff Atwood interprets this principle as a need to continually refactor:

For software developers, working clean means constant refactoring. If you don’t stop occasionally– frequently, actually– to revisit and clean up the code you’ve already written, you’re bound to end up with a big, sloppy ball of code. If you forget to regularly clean up behind yourself, things get smelly. Working clean means following your nose and addressing those nagging issues before they become catastrophic.

I am sympathetic to this idea, but I have one concern: simply saying that we need to continually refactor our code is an admonishment. It does not actually lead to building a practice of applying the “clean as you go” idea. We need anchors to help us cultivate a new practice. I propose four:

  1. A simple rule to follow
  2. Start by tidying
  3. Work in smaller steps
  4. Remember: the job isn’t done until you’ve cleaned up

A Simple Rule to Follow

The simplest way to get started with the “clean as you go” practice is to give yourself a rule: whenever you open a file, note, or draft, you must make at least one improvement before you can close it. Clean up spacing, add a comment, rearrange the notes, or even take the opportunity to file an issue that tracks a larger-scale improvement you want to make when you have more time. By setting the bar at a single improvement without any other qualifications, you make the task eminently achievable. You might be surprised at how quickly the state of your digital environment improves by cultivating this one simple practice. Once your eye becomes trained, you will notice improvement opportunities everywhere you look.

Start by Tidying

Sometimes we can feel overwhelmed by the task at hand, or we just don’t know where to start. In these cases, we can apply a lesson I learned from working in the San Francisco Japanese Tea Garden: when you don’t know what else to do, start by tidying. If I wasn’t sure how to accomplish the stated goal, I would begin by cleaning up what was there: removing dead leaves, dead branches, and detritus from taller trees. Even if I didn’t accomplish anything else, the tree looked better. But what typically happened was that during the course of tidying up I would suddenly see how I could approach the higher-level task. As I pointed out in the article:

The same approach will work whenever you feel stuck on a programming or engineering problem. If you find yourself unsure of where to begin, start by tidying the code, design, or documentation. Fix the formatting, add comments, remove unnecessary statements or components. As you work, you will notice other ways to make improvements.

If you do this, not only will you notice other ways to make improvements, but you will have started to understand what you’re working with. You’ll have a map of the terrain, and you may even find the critical starting point for accomplishing your actual goal.

Work in Smaller Steps

We will have an easier time “cleaning as we go” by training ourselves to work in smaller chunks or steps. The smaller the unit of work we can select, the easier it is to test, analyze, review, refactor, and integrate. Large changes isolated on a branch for days, weeks, or months often incur significant rework due to incompatible changes on the main development branch or due to feedback received during a code review. I also find that I’m more likely to cut corners with large changes, leaving in sections of code that I will “improve later” but never seem to actually get to.

We can take a lesson from the TDD workflow of “red-green-refactor” to work in smaller and smaller steps:

  1. We make sure the code fails the test
  2. We make the code pass the test
  3. We refactor the code and make sure that it still passes the test in its improved state
    1. I also like to add clarifying comments in this step
  4. Optionally (and ideally) we commit the changes so we always have a “known-working” state to revert to

I find this process to be most analogous to “cleaning as we go” in the kitchen. We’ve refactored the code as we worked, so the amount of cleanup that will be left to us at the end of the task is significantly reduced.

Remember: The Job Isn’t Done Until You’ve Cleaned Up

We would do well to keep in mind another lesson that I learned from working in the Japanese Tea Garden: the job isn’t done until you’ve cleaned up!. It is equally as important in the kitchen and in our professional work.

Working in the garden emphasizes a stark fact: the job of pruning a tree is more than just the act of pruning. The job isn’t done until clippings are removed from the ground, the paths are swept to look neat, trampled grass has been raked and made to look untouched, the clippings are taken to the compost pile, the tools are cleaned, and everything is put away.
[…]
I observe that developers (including myself) often estimate the time to write the code or solve the problem. We forget about the time we’ll spend testing and debugging our design, cleaning up the code for publication, reorganizing our branches and commit messages, working through code reviews, addressing feedback, merging into master, and working with QA to confirm that the problem is fixed.

We recognize that these are important steps of the development process. We do not skip them or postpone. We take the time to clean up our work before we present it to others for review. We resolve those TODOs and FIXMEs before we merge our code.

These tasks can be a significant burden at the end of a development effort. Instead, we can take smaller steps and clean as we go. This helps us avoid expensive cleanup at the end of a development effort, or even more alarming, checking our mess in to be cleaned up “later.”

“Later” rarely (if ever) comes, so remember to clean as you go!

Further Reading

Share Your Thoughts

This site uses Akismet to reduce spam. Learn how your comment data is processed.