What Refactoring Started to Mean to Me

I have been building this website with Cursor over the last few weeks. I expected to learn a bit more about frontend development. I did not expect to develop a stronger appreciation for refactoring.

The appreciation came from a very practical frustration: I would fix something in one place and then realize the same issue still existed somewhere else.

Where it first showed up

The first example was the Work section. A Work card on the home page opened a detail page with one structure. The Work link in the top navigation opened a broader page with a different treatment of the same material. Neither page was exactly wrong, but the relationship between the two was not clear enough.

Content about my Safety work made this more obvious. Safety Centre, Mobile Telematics, and Share My Ride were related parts of the same safety work. In the implementation, they sometimes looked like separate projects and sometimes like supporting examples. The page rendered, the copy was readable, and the links worked. But the hierarchy was doing too much work in my head and not enough work on the page. The problem was less about a broken page and more about the same idea being represented differently in different parts of the site.

Part of this came from the way I was working with Cursor. I would ask for one change, then another, then refine something else a few days later. Each instruction was reasonable on its own. But over time, inconsistent experiences crept in. That felt familiar from product work. PMs often give engineers a series of locally sensible requests, and only later realize that the product now has too many small exceptions.

That is when I started to understand how code accumulates the history of decisions.

Most of these decisions were reasonable when they were made. Add a section. Change a card. Move a public reference link closer to the work it supports. Add a writing page. Add another article. Improve the article styling. Add share buttons. Add a bottom CTA.

Each change was small. The problem was that the same decisions started repeating.

When a page fix is no longer enough

Writing was a good example. The first article could have stayed as a one-off page. But once I added more articles, the repeated editorial choices became obvious: where the title sits, how metadata appears, whether there is a back link, how much spacing the intro gets, where share controls belong, and how the page should end.

At that point, “make this article look better” was the wrong instruction. Fixing one article's layout would solve the visible issue on that page, but it would not help the next one. What I needed was a reusable pattern — something that gave future articles a clear place to go.

So I asked for an article kit instead of another one-off polish pass: article layout, metadata, share controls, bottom CTA, typography, and spacing that every article could share by default. Once those pieces existed, the next article did not need the same set of design decisions all over again.

The Work section needed a similar cleanup. Instead of letting the home page, Work page, and detail pages each describe the same work slightly differently, the content moved into a shared model. Public references were attached to the relevant work instead of being placed manually wherever they looked right at the time. Safety was treated as a domain with related parts, rather than a loose collection of pages and links.

The useful part of the refactor was that I could now look at the site and understand where a piece of content belonged. After seeing the same decision show up in a few places, it became harder to justify handling it separately each time.

There was one place for Work content. One pattern for articles. One place for navigation. One place for visibility rules. Old components that no longer matched the current site were deleted.

Deleting code was more satisfying than I expected. Unused code also created its own friction. Even when it was not rendering anywhere, it made the codebase harder to read because I still had to wonder whether it mattered.

Why this changed how I think about product work

Working through this site with Cursor made the pattern easier to see. The tool helped me move quickly, especially as someone still learning how the codebase was organized. But speed also made it easier to create local fixes. A component could be added because it solved the current screen. A page could be improved without changing the model behind it. A content tweak could land in one route and not another.

Cursor could implement what I asked for. It could not tell me which of those fixes should have become shared structure in the first place. That still required stepping back from the screen-level issue and asking whether I was looking at a one-off problem or a missing reusable pattern.

At company scale, re-architecture often starts when a pattern has repeated often enough that the original implementation is no longer a good container for it. Building shared structure takes time, so it can feel expensive in the moment. When it works, though, it reduces repeated effort across teams, cuts down exception handling, and makes future product development faster and more reliable.

The same tension shows up in product work. Products also accumulate local fixes. A new flow is added for one segment. A support message is patched for one failure mode. A dashboard is created for one team. A policy is added because of one incident. Each decision may be sensible. Over time, though, the product starts carrying too many exceptions.

This also changed how I think about a familiar PM frustration: “We just built this. Why are we spending time refactoring it already?”

As a PM, I used to see some refactoring as rework. Working through this site made it easier to see why the first implementation often exposes the structure that should have existed underneath. You do not always know what deserves to become reusable until the same pattern shows up a few times in slightly different forms.

For this website, that meant turning scattered pages into a clearer structure for Work, Writing, Recommendations, Navigation, Visibility, and shared article components. It is still a small site, and the mess was small enough that I could see the pattern clearly.

I still think PMs should be careful about asking for refactoring without understanding the tradeoff. But I have a better appreciation now for why engineers push for it. Without that cleanup, every future change keeps reopening the same structural questions.