I went back through some old project backups and found websites and applications I had not opened for years. There were landing pages that had gone nowhere, unfinished logic and folders whose names no longer meant much to me.
I remembered the ambition more easily than the code. I had wanted to make things work, often before I understood how to give them a structure that would survive the next change.
Opening those files was a useful way to see the distance between the developer I was then and the way I work now. It was also a reminder that the older work had served a purpose, even when the result was rough.
Making it work came first
There were tables nested inside other tables, styles written directly into HTML and JavaScript full of tightly connected conditions and loops. Some of it predated the frameworks I would later use.
A working contact form had felt like a significant achievement. I wrote the validation by hand and spent hours debugging it. Looking back, I could see the repetition and the awkward decisions. At the time, the immediate problem was getting the form to do what I wanted.
That distinction matters when I look at early work. I can see ways to write it more clearly now because I have had more practice. I did not have that experience when I was making the original decisions.
The stylesheet told the same story
One large CSS file contained class after class without a clear naming approach. Inline styles appeared throughout the HTML. Finding a rule was one task; working out what else it affected was another.
I spend more time planning those relationships now. Clear names and a consistent structure make it easier to return to a piece of work and understand why it behaves as it does.
The old files showed me what happens when the next visible result is always the priority. I would keep adding until the page looked right, but the structure underneath became harder to follow. The effort had gone into reaching the next screen, with less thought given to the next edit.
A small feature could take a lot of effort
I also found an early attempt at lazy-loading images. It relied on JavaScript and load events, and the implementation was fragile. I could remember trying to connect the pieces well enough to get the behaviour I wanted.
It is easy to forget that effort once the same task becomes familiar, or a browser feature makes it simpler. Finding the original code brought the problem back into focus. I had been learning how the page worked by trying to change what it did.
The implementation was imperfect, but the experimentation mattered. It gave me something to inspect, break and understand. That was how a lot of my early development happened.
Notes for a future version of me
The comments were another reminder. “Fix later” and “check tomorrow” were scattered through the code, without enough explanation to tell me what I had intended.
They probably felt clear when I wrote them. Years later, they were clues with most of the context missing. I have become more appreciative of useful names and comments that explain the reason for a decision. They save the next person, including me, from having to reconstruct it.
I did not reopen the backups to turn every old project into something current. I wanted to look at them honestly and recognise what had changed. Some ideas were unfinished. Some solutions were cumbersome. They were still evidence that I had been trying things and staying with problems long enough to learn from them.
It was encouraging to see progress in such an ordinary form. There was no single file where I suddenly became a better developer. There were many attempts, some abandoned and some completed, that made later work easier to understand.
I kept the backups. The rough edges are part of why they are worth revisiting.