Over the last two weeks I have been tasked with refactoring some old code. Some very old and never touched since it was originally written, some newer, and some that was part of previous refactorings but was still written in an older form. So quite a wild mix.

The idea was to move everything to a newer way of writing components in the given framework, with the goal of having a consistent style across the codebase to reduce cognitive switching between forms and styles. But also to take advantage of newer techniques that require the new form to be applied to all components to be useful. Also, VS Code’s language server support is much better for the newer styles when it comes to linting and detecting errors or unused code.

When I was planning it, it looked like a really straightforward task. Nothing special, nothing too complicated. I have written most of this stuff anyway and should know everything that has been written there - right…

To avoid making too many changes at once and blowing up the PR too much, I limited myself to a straight 1:1 functional refactoring. No big optimisations and no big improvements for reasons of “this is better” or “this is more performant” or “this is what you would do in today’s world” or “this new way is much cleaner” and so on.

Remember - (very) old code - there are PLENTY of things I would do differently today. Scope and external requirements have changed over time, browsers and frameworks have become more capable and, at least I hope so, I have become a better developer over the years.

The goal was a “quick and easy” just get it done task to achieve an isolated goal for now.

So my self-imposed rules were:

• one component at a time
• a 1:1 transition to the new form
• no major refactoring or “structural” improvements

After the first few components I was shocked at how exhausting the whole process was. I refactored a medium complexity component line by line, function by function, tested it and was mentally exhausted and it took WAY longer than planned. A truly mind-boggling experience that I could not explain at the time. A lingering cold certainly did not help, but that could not be the only explanation. The gap between my expectations and the actual energy and concentration I had to muster was staggering. A seemingly straightforward, easy task turned out to be an energy drain that I could not explain.

I pushed through, but as it wasn’t time-critical, I took extra breaks and spread the work out over a few days (assuming I was still a bit under the weather). But it left me scratching my head as to what had just happened and how my estimates and planning had been so far off.

A few days later, while doing some chores around my apartment, my brain came up with a possible explanation: I had written most of the code in front of me. I was revisiting old code of mine, written with a different scope, different goals and a different skill level at the time. So I sat there judging my old crap code that my past self had written, while at the same time preventing myself from improving and correcting it and making it better. I had to muster so much willpower and mental gymnastics to obey my own rules while silently judging everything in front of me, unable to “correct” my former work. Not being fully aware of this mental split in my head added another layer of effort and willpower nedded that I was not aware of.

I am doing this development stuff for quite a some years and it is fascinating that I still find many and often ways to humble myself with these kinds of assumptions and pitfalls that I run into. Underestimating tasks that come with some non-technical or task-related hidden costs can set you off big time. Perhaps if I had realised what was going on after the first few components it would have been different. The inability and unwillingness to reassess my original assumptions made everything less efficient and much more exhausting in the end.

It was a good reminder that sometimes something hidden and not obvious at the time can really throw you off. Especially when it is a seemingly simple task. I think it’s a good and humbling experience, even if it’s a bit embarrassing.

So to all the product owners, project managers and devs out there: If your development team is taking far more time than you expect and the coffee consumption is off the charts… Maybe it’s because they’re screaming inside their heads at the code their former selves wrote.