Marie Kondo is that Japanese woman who became famous with her method for reaching a tidy home and a tidy life.
Her method can be summed up as:
Throw away most of your shit.
You don't really need it. It's holding you back. It adds to your mental load, it bloats your life and living space.
Everything that doesn't make you happy (or is very useful) must be thrown away.
It's hard to describe how liberating it feels to just have less. It's a feeling very few people will ever actually experience.
But as humans, we are anxious creatures afraid of scarcity. So the act of throwing stuff away can be very difficult.
Why is it so hard, and why is it also so important? Let's discuss.
Is it really that important?
Yes. But you can't really know this if you never experimented both sides: the clean and the dirty. As I explain in this article about the technical debt, most developers never worked in the clean and don't understand just how huge the difference feels.
Just as throwing your shit away is important for living in a clean space, throwing your code away is important for working on a clean, debt-free codebase.
Removing a line of code is much harder than adding one.
Blaise Pascal (not Mark Twain) wrote :
If I had more time, I would have written a shorter letter.
The best code is short, DRY and simple. The least good code is long, repetitive and complex.
Adding code is easy. You have a need, you just throw code at it until the problem disappears. But more code means more maintenance, more bugs, more complexity, more problems.
Removing code is hard. You need to either accept that your need won't be fulfilled, or you have to write the best, shortest, most elegant code to fulfill that need.
No code means no problems.
You're not really throwing anything away.
Are you using Git? If not, stop reading this and go implement Git.
If you're using Git correctly, then you have a trace of every line of code ever written in your codebase.
Many developers will complain that it is hard to find deleted code because their Git history is a mess. When we dig to find out why they can't keep a clean commit history, we soon realize it's because their codebase is a mess.
Don't be a victim of tautology. A messy kitchen only attracts more mess. Break the cycle and be free.
Marketing VS Technical
The marketing like new features, and for good reasons. New features are good. They supposedly attract new clients, and new clients are good. More clients means more money, and money is good.
Experimenting and changing to see what works and what doesn't is a great way to develop your product and achieve success. But adding a feature is like buying an air-fryer: there is a risk that you actually won't be using it.
So adding stuff is great, but you have to follow rules:
Dont add crap to your app. Add clean, well-coded, well-polished small features. Go for a good little MVP (Minimum Viable Product), don't go for the huge, badly-hacked feature.
You can't keep adding stuff if you don't remove stuff. If a feature is not used by a majority of your users, you probably want to just throw it away.
Conclusion
This article was originally about 1000 words, but since I had some time, I made it under 600.
Throw your shit away, today.
Also available on my blog
If you want to thank me, coffee
Top comments (27)
If it doesnt spark joy.
rm -rf */DROP DATABASEin production.I imagined Marie Kondo coming to my computer, taking an overview to my Projects folder and let my console start point at Projects/ while adding
alias cd='rm -rf'😆I can have so much fun with this.
Mostly good suggestions here ;D
Laugh will be sin! 😂 this joke make me crying! Oh shit!
based
Dear customer, disregarding the bullshit your agency has dumped into Figma, I hereby deliver a clean, minimalist, and usable website without carousel sliders, chatbots, call-to-action teasers for newsletter signup, and muted auto-play videos consuming your end users' bandwidth.
One day you will understand and be grateful, too!
I wish we lived in this world.
Me too! At least I have one customer, a sustainability consultant, who asked me to remove a background video from her website, after looking at websitecarbon and lighthouse performance audits.
But we don't. Here's a Lighthouse audit of konmari.com:
Unfortunately not, as most repositories, at least on GitHub, now default to forcing squash commits when merging feature branches. So if you have tried different possible solutions in your feature branch, only the latest version of your code will make it into the main branch, and GitHub will even tell you that it's "safe to delete" your feature branch now.
I usually keep my original feature branches in my local repository for some time, but I doubt that it's a good idea to rely on git, and even more so, on one central origin like GitHub, GitLab, BitBucket, or your company's official SVN upstream, as the only place to persist your work history.
Besides my official code releases, I save bookmarks in my browser, take notes with a pen on paper in an actual notebook, and use DEV and other websites for technical writing, which helps me to get my ideas in order and possibly get some feedback from others as well.
Concerning Marie Kondo and similar influencers, I have always been fascinated but critical at the same time. Take their ideas too literally, and you'll throw away anything that doesn't make you happy or that you haven't used for one year, including your snowboard after there was no snow last winter, and all the stuff that does not spark joy in your heart despite being necessary to clean your home, repair your bike, or send important documents to the tax office. Like with all the modern "mindfulness" fad, you can find truth and inspiration in concepts like "magic cleaning", but always take it with a grain of salt!
Ironically, konmari.com, which appears to be her official website (is it?) offers visitors to shop for new items! Maybe that's the real marketing idea behind magic cleaning: make people throw away their old stuff, then offer them a shop to replace the magically cleaned items.
Indeed this is bad practice. Rebase is the obvious way to go.
It happened to me in code and in life that I threw away stuff that I actually needed later, so a mistake. But practicing mindful getting-rid-of-my-shit has been amazing, as a whole. That being said, it's good to remember that anything related to self-help is the domain of wolves and scammers.
I like to retain my feature branches too, for a short while. Where "short while" is about 10 years.
One of my favorite pieces on the subject is from the round of interviews James Gosling made in the 90s as they were promoting Java.
He said that when he moves to a new house he packages everything in boxes with a clear list of the box contents.
Then he doesn't unpack. He opens a box only based on necessity.
6 months later he throws out everything else without looking. If he'll look he won't throw it away.
He credited this approach for Java's very lean set of language features. For me that's the killer feature of Java.
I really wanna try this but I'm scared lol.
I totally agree with this statement, but it also depends on the language/ecosystem you're working with. In the Elm language community, it's very easy for us to remove dead code, as explained in this article: jfmengels.net/safe-dead-code-removal/ (disclosure: it's my article and my tool behind it). The biggest blocker that remains is, as you mentioned, the developer's fear of throwing code away because it's too hard to find it back if you need it again (which in my experience, is extremely rarely needed).
For Marie Kondo - Sketch of rooms and lists for all product allow a conceit view of your house inventory.
For Devs - Storybook and tests allow you to rebuild and condense your code without fearing errors or bugs.
Throw your shit out, with confidence and reassurance
Now that Marie Kondo has overcome her tidying habits, this post may be in need of refreshing... or not.
Oh this is so true! Thanks for this article 🎉 I know a few colleagues that should read this.
Also comparing features to an air-fryer : SPOT ON 👌
A friend says that it's funnier to delete old code than write new code
As always, comments are welcome.