If Marie Kondo Was a Coder
Upon first exposure to clean code, I knew that I wanted to spend the rest of my professional career as a developer writing high-quality, clean code. It seemed like the right thing to do, the pragmatic thing to do. As a kid, I would spend my time cleaning, organizing, and discarding unnecessary belongings. That is, if I wasn’t reading a book, watching Nickelodeon, or playing with the computer. I remember being no older than seven years old and turning to my mom and saying, “I love cleaning.”
In some respect, it felt like I was standing at the intersection of two things I absolutely love: being organized and writing code. There is transferability from one to the other.
Fortunately, as a newcomer to tech, I have not experienced being slowed down by someone else’s messy code. Uncle Bob vividly describes this predicament:
Every change they make to the code breaks two or three other parts of the code. No change is trivial. Every addition or modification to the system requires that the tangles, twists, and knots be “understood” so that more tangles, twists, and knots can be added. Over time the mess becomes so big and so deep and so tall, they can not clean it up. There is no way at all.
This sounds so painstakingly terrible, and you just cringe at the thought of this. Prior to 8th Light, I worked for a dev shop with several contributors to a code base. Unlike a product company, we worked on relatively short-term client projects. Each developer had his or her own style when it came to naming conventions, constructing methods, and even spacing. Even as I was going through files and reading code, I had the inkling feeling that things were not quite consistent. I remember wanting more — a comprehensive style guide? More pairing sessions to be attuned to each other’s syntax? A workshop detailing how we should write code? I wasn’t sure at the time, but it felt like an itch I wanted to scratch.
Uncle Bob talks about an acquired sense of cleanliness, called “code-sense.” I like how he acknowledges that some of us are born with it whereas someone of us “have to fight to acquire it.” Nonetheless, it is a quality that can be learned and it comes easier to some than others — as in all things in life. It reminds me of how someone has artistic or design sensibilities, or a penchant toward being organized. It makes me feel less at fault for preferring a clean environment, for being “too clean,” a real-life critique that I’ve received from a previous roommate. In the context of coding, I may not know what to do a messy module, but I’m hoping that with more experience, I can better understand my options.
My favorite section of the first chapter of Clean Code is entitled “What Is Clean Code?” There is a drawing of an experienced programmer accompanied by a quote about their definition of clean code, followed by an interpretation of their definition. I like it so much! Here is a summary of what constitutes clean code from authors and language inventors:
- Elegant — that is, pleasing to read!
- Efficient
- Close attention to detail (e.g. complete error handling)
- Readability (“like well-written prose”) with “crisp abstractions and straightforward lines of control”
- Easily enhanced by other people
- Tested
- Minimal
- Literate, readable by humans
- Taken care of by “someone who cares deeply about the craft”
- No duplication
- Highly expressive
- Simple abstractions
- Reasonable and obvious
Reading attributes of clean code made me really excited. I got this sense that clean code wasn’t just a monolithic, top-down approach to writing code. Rather, it’s a lively exchange of ideas. It shares similarities to writing in the English language. Brevity is a cherished thing. It is more art than science. It is a carefully crafted process, written with clear intentions and dedication. Its words fit its needs. It does not dwell in excess and nonsense.
I believe Marie Kondo would have a thing or two to say about clean code. She’s not a programmer (she is a Japanese organizing consultant and if you haven’t read her book, you haven’t truly lived). Even without a coding background, her belief in how our livelihoods are intertwined and impacted by our clutter-free environment render her an almost-expert. Alas, here is a drawing of her and a quote about organizing and decluttering (which I think is more applicable to refactoring than clean code).
Marie Kondo
Author, The Life-Changing Magic of Tidying Up: The Japanese Art of Decluttering and Organizing
The best way to choose what to keep and what to throw away is to take each item in one’s hand and ask: “Does this spark joy?” If it does, keep it. If not, dispose of it. This is not only the simplest but also the most accurate yardstick by which to judge.
If I had to refine this to address the question “What Is Clean Code?” — I think Marie Kondo would propose that clean code brings us joy. Beyond the beauty and expressiveness of code, she would turn our attentions inward, to our emotions. How does the code make us feel? I think feeling a sense of dread or disgust would be a clear indicator of how we feel about the code. It probably indicates that the code is not very good because it is not literate or readable, as we have previously established.
Likewise, Marie Kondo shares the same values that other programmers, such as Dave Thomas, have shared: minimalism. If we were talking about modules or methods, I imagine that we can determine if code “sparks joy” because of their usability, modularity, and readability. We should look at each unit of code carefully. If it does meet the criteria, thereby sparking a certain joy in the coder’s heart, then by all means, you should keep it. If not, get rid of it or alter it. Overall, striving toward minimalism is what we should be doing as we’re writing code and determining if it brings us joy.
All hail, KonMari!
