Does Your Code Spark Joy?

Marie Kondo and her new Netflix show (Tidying Up) have been the talk of the town lately. Marie invented the KonMari method of tidying up and published a book on the subject in 2014.

The KonMari style of tidying is to pull out everything within a category (in order: clothes, books, paper, miscellaneous, and sentimental), pile the items in one room, and then go through each item individually. With each item, you are to hold it in your hands and ask yourself, Does this spark joy? If it does not, you thank it, and set it aside to discard or donate.

I read the book a year or two after it was published and have been regularly practicing (a portion of) the KonMari method for the last couple years. My wife and I have gotten rid of about 40 boxes of crap, and we add a few boxes to that list every year. It's incredibly satisfying to live in a house in which I know nearly every item within the house sparks joy for someone who lives here.

But tidying isn't just for the household items. It can be used for code, too.

I'm not going to suggest you perform the KonMari method on every line of code you've written. You're not going to go digging for the nasty shit you wrote five years ago, pull it out, throw it on the living room floor (or the Desktop directory, or whatever), and look at each file to see if it sparks joy. That doesn't make any sense—it'd be a massive waste of time, because while you should be embarrassed by old code, you don't have to go cleaning it all up. Some code is just fine as it is. Sometimes you write code and later place it in a deep, dark corner of the internet (or your personal backups/), never to be seen again. That's okay.

Instead, I'm suggesting is that you ask the question—Does this spark joy?—as you actively write code.

If the answer is No then you ought to spend some time cleaning up. It's difficult enough for developers to pick up good code written by another developer. To hand someone a steaming pile of garbage code you didn't even like when you wrote it an attribute you won't find in good developers. Instead, write code that you'd want to read.

Look, I've written a lot of really terrible code in my career. A lot. For the first few years I worked at an agency that allowed scope creep on every project without adjusting schedule. Our developers pleaded and pleaded for time to write programmatic tests and feel confident the application would run smoothly when we made a mistake. And we were denied the time every time. Much of that code is still out in the wild, a rotting testless heap that barely works. (That job didn't bring me joy so I got the fuck out.)

So, it's time to clean up your code. To refactor. If you're not used to it, refactoring can be a daunting task. I put together a list of four tips for refactoring like a pro. By following this approach and using the tips, you can ensure you have the proper time to give your code the attention it deserves.

Everything is constantly changing in our lives. My wife and I tidy at least once a year, because some item that sparked joy last year may not next year, making it time to thank the item and move on.

Programming should work the same way. Every developer—including you—should always be learning something new. Not just new languages, but new methods for solving problems. New idioms within syntax(es) you're already comfortable with. New methods you never knew existed. Looking at old code shouldn't spark joy—it should be embarrassing. And that's good. It means you are getting better, but it also means you should do a little tidying, just enough to make you happy, and then move on until the next time you have to work with that code.

Tidy code makes for a tidy project and helps promote an organized mind. Plus, refactoring gives you practice to take your programming game to the next level.

And if you go through this process and you still hate the code you're writing, it might be time to do something about it. Now, go clean up some code!