Reading my own old code
Last month I opened a dropdown component I built in 2025. The behavior was correct and the tests passed, but the code felt unfamiliar in a way I didn't expect. Some functions were named with a verb and others with a noun. The same boolean state was called isOpen in one place and expanded in another.
Looking closer, I could see I had changed my mind partway through the file without noticing. The early part was written with one mental model, and the later part with a slightly different one. Nothing was broken. The inconsistency simply showed how the work had gone.
What I noticed, and what it meant
Observation | What it told me |
|---|---|
Functions named with verbs and nouns | I hadn't settled on a naming pattern yet |
Two names for one boolean state | My model of the component changed halfway through |
Correct behavior and passing tests | Tests check outcomes, not whether the code reads well |
Shortcuts in the early section | I was still working out the problem, not the code |
Why it's worth the discomfort
Reading old work is uncomfortable, but it's the closest thing I have to feedback from a version of myself who didn't yet know how things would turn out. I can see the shortcuts, the places I was unsure, and which assumptions held up.
The code you wrote last year was written with less information than you have today. Read it as a record of that, not as a verdict.
What I keep now
I keep a short note at the top of anything reusable. It lists the two or three decisions I'd want to remember and the one thing I'd change next time. It takes a few minutes to write, and it saves me from rederiving my own reasoning every time I return to a file. I also keep a short list of naming conventions in the repo so the next component doesn't start the drift again.