In a recent discussion about the value of deleting code, one specific habit kept coming up: leaving blocks of commented-out code in a file, just in case we might need it later.
We all know we should not do it. We have version control systems that remember every keystroke we have ever made. Yet, we leave that graveyard code right in the middle of our active files. We do it because deleting feels permanent, and keeping it feels safe. But in reality, it just transfers the cognitive load to the next person trying to read the file.
This habit of hoarding code is just a symptom of a much larger problem. We are a generation of digital hoarders.
The cognitive load of "read-it-later"
Look outside your IDE. Look at your browser with its forty open tabs. Look at your read-it-later app, filled with hundreds of articles, tutorials, and deep dives that you saved months ago. We hoard this information with the best of intentions. We tell ourselves that we will read it this weekend.
But we rarely do. Instead, that infinite list of unread links becomes a source of low-grade anxiety. It transforms from a library of knowledge into a visual reminder of everything we are failing to keep up with. It is the exact same cognitive load as the commented-out code, just applied to our daily lives.
Embracing digital decay
The solution to both problems is the same: we need to embrace the concept of decay.
In nature, things that are no longer useful break down and clear the way for new growth. In software and personal knowledge management, we try to keep everything alive forever. But if a piece of code was truly important, you will write it again, probably better. If an article was truly essential, the concept will cross your path again.
We need to stop treating every piece of digital information as a compounding asset. Most of it is temporary context.
This specific realization is actually what pushed me to build my own tool recently. I was tired of feeling guilty about my endless list of saved links, so I built Sigilla. It is a bookmarking tool with a very specific constraint: unread links decay and disappear over time. If you do not read it, the system cleans it up for you. No graveyard, no endless backlog, just the things you actually have the time and intention to focus on right now.
Whether it is a block of legacy code or an article about the latest framework, the most liberating thing you can do is to let it go. There is beauty in letting things decay.
Top comments (25)
Hahaha, totally agree! I keep pointing this out in code reviews - please remove commented-out code, we have Git for a reason 😄
My juniors have almost learned it by now.
That is brilliant. 😄
Code reviews are definitely the best place to catch this habit before it makes it into the main branch.
If you can get your junior developers to truly trust the version control system early on, you are saving them a massive amount of cognitive load in the future. It sounds like you are building a very healthy engineering culture in your team
This idea of having a tool that displays decay is brilliant. If only we could have the same thing in code, with an IDE that would detect from the version control system the age of a commented out section !
That is an incredibly good idea. Imagine an IDE extension where commented-out blocks slowly fade into the background color over a few months until they are completely invisible. It would be the perfect visual representation of tech debt.
With the AI tools we have available today, building a plugin that scans the version control history and applies that kind of visual decay might actually be a very realistic weekend project. Someone should definitely build that. Thank you for the kind words about the article and Sigilla.
I have to admit: I comment code, and leave it there. Or I keep methods without references.
I often hear this argument. But once you need that method, you (1) need to remember you removed it from the code-base years ago, or (2) worse you don't know it ever existed. You (3) need find it in the depths of old commits and (4) adjust all the variable names, you renamed since then. This trail of thoughts makes it really hard for me to let go of the good ideas, me or someone else had some time ago.
I like this thought - but does your boss also like it?
It is refreshing to see Juniors that want to remove those old pieces of code. We discuss them, and then decide if we acually want to remove them. Sometimes we keep them, sometimes we don't. A fresh pair of eyes might be the best that can happen to these almost dead lines of code.
You make some very fair points, Hauke. Digging through Git history is definitely a headache, and you are right that most bosses do not want to pay for the same work twice.
However, I usually find that if a codebase has evolved so much that all the variable names and the surrounding architecture have changed, trying to revive and integrate old commented-out code often takes more time than just writing a fresh version. The archaeology itself becomes the bottleneck.
I do really love your approach with the junior developers, though. Having that conversation and forcing yourselves to justify why a piece of unused code is still there is a fantastic team exercise. It turns dead code into a teaching moment.
This really hit home. I spent last weekend cleaning out a project that had ~200 lines of commented-out code across maybe 15 files. The wild part? Most of it was from features we'd already reimplemented differently months ago. Total waste of mental bandwidth every time someone opened those files.
The browser tabs thing is spot on too. I've started doing a weekly "tab bankruptcy" where I just close everything and start fresh on Monday. If something was truly important, it'll come back to me. And honestly? It almost never does. The anxiety of 40+ open tabs was way worse than actually losing any of that info.
Curious about the decay timer on Sigilla - is it configurable per bookmark, or is it a global setting? Because I could see wanting different decay rates for "quick reference" stuff vs deeper reads.
Tab bankruptcy is a perfect way to describe it. That feeling of relief is exactly what I wanted to capture with the app. The anxiety of having 40 open tabs is definitely worse than losing the links.
Right now, the decay timer is a global setting just to keep the saving process as quick and frictionless as possible. But I really like your idea of having different decay rates depending on if it is a quick reference or a deeper read. I will definitely look into adding that. Thanks for the feedback.
This is painfully accurate.
Commented-out code and unread tabs are basically the same thing postponed decisions that quietly add cognitive load.
Really like the idea of designing for decay instead of accumulation. Not everything needs to be preserved. Sometimes letting it go is the real productivity win.
"Postponed decisions" is the exact right way to phrase it.
We trick ourselves into thinking we are saving valuable information, when we are actually just deferring the choice of what to do with it.
Designing for decay is a big shift in mindset, especially in an industry that defaults to storing everything forever. I am really glad the concept resonated with you. Sometimes the ultimate productivity hack is just accepting that you do not have to process every single input.
I never thought about digital information having a shelf life, but you are absolutely right. Most of what we save is just temporary context that loses its value within a week anyway. The idea of embracing decay is actually quite beautiful and liberating. It takes away the low-grade anxiety of that 'read it later' pile. I am curious to see how Sigilla changes my browsing habits. Sometimes less really is more when it comes to knowledge management!
Hi Ava, thank you for reading! 'Low-grade anxiety' is the perfect way to describe it, and exactly what I wanted to cure for myself. Once you accept that most information really just has a short shelf life, letting go of those saved links becomes a relief rather than a failure. I am really looking forward to hearing how the auto-decay affects your daily workflow. Let me know how it feels after a few days!
Agree
Thanks for reading Salik!
Can’t agree more!!
Thanks Evan!
It is a real cool project specially that you build this application Sigilla that helps you :).
Thank you, Benjamin. Building something to solve my own problem was definitely the biggest motivation behind this.
When you are your own first user, it makes the whole process much clearer. You know exactly what the product actually needs to do, and more importantly, what it should not do. I am really glad you liked the project and the article.
You are welcome :)
But, does Sigilla have an "undelete" function? :P
P.S. how similar is digital hoarding to "FOMO" ?
That is a great question. And the answer is a very strict no. Having an undelete function would completely defeat the purpose of the app. The whole point is the permanence of the decay. It forces you to actually prioritize what matters to you right now.
As for your second question, I think they are incredibly closely related. Digital hoarding is essentially the manifestation of FOMO. We save all these articles, tools, and tutorials because we are terrified of missing out on some crucial piece of knowledge that everyone else seems to have. Letting go of the digital hoard is really just practicing how to let go of that fear.
Some comments may only be visible to logged-in visitors. Sign in to view all comments.