Remember Refactoring?

When I started my career in the software industry in the mid 2000s, refactoring was in the zeitgeist. Martin Fowler's seminal book on the topic was widely discussed in the blogosphere. In the Microsoft .NET world, ReSharper was a mind-blowing new product that integrated into your IDE and offered automated refactoring tools.

It was normal for engineers to spend time improving the internal design of their codebase. We looked for code smells. We fretted over variable names and the size of classes. We added comments. We extracted methods and rooted out dead code.

In other words, engineers (good engineers, at least) had taste in code. One of the signs of experience was that you could review another engineer's code and point out issues in its quality, rather than just its functionality.

I can't be alone in thinking that in 2026 refactoring very suddenly feels like a very quaint concept. I remember as recently as 2024 having regular conversations in team meetings about how myself or a fellow engineer was going to spend some time refactoring a certain area of a codebase, and that was a normal thing that we all knew intuitively was a good idea. In 2026, I can't imagine having a conversation like that.

LLMs made code disposable. It happened so fast I didn't even notice. In 2026, Claude is almost a compiler that turns your English language prompt into a high-level programming language in the way a typical compiler would automatically turn your high-level programming language into assembly language. And I've never heard an engineer talk about refactoring assembly language. Who cares about the assembly language, right? 

Is having "taste" in C# code as weird as someone having taste in assembly language now? I'm not sure how to feel about that. I remember refactoring.