Practical Refactoring, in Many Small Steps

I was still at university, probably in my final year, when I came across a video that stuck with me more than I expected. Looking back, it probably had more influence on how I think about code than I realized at the time. So, credit where it's due: this one goes to Llewellyn Falco and Woody Zuill.

The video is called "Practical Refactoring - How to clean code in many small steps." And honestly, I think even non-programmers would enjoy watching it.

You don't really need to understand the code to get something out of it. It's a bit like those oddly satisfying videos where someone untangles a huge mess of cables, cleans up a filthy workspace, or takes something chaotic and gradually makes it neat again.

Except here, the mess is code.

And there's something weirdly satisfying about watching it happen. You start with this ugly, tangled piece of code, and then, one small change at a time, it becomes something clean and understandable. Even if you have no idea what the code does, you can still see the transformation.

For me, though, the interesting part went beyond the satisfaction of watching the mess disappear.

What I liked about it wasn't really any single refactoring trick. It was seeing someone take code that looked awful and just... work through it. One small change at a time. No grand rewrite. No "let's throw this away and start again." Just a series of small, safe improvements that gradually turned the whole thing into something much easier to understand.

That was a pretty important idea for me.

Before seeing that, I think I had a tendency to look at bad code and think, this is going to be painful. The video gave me a different way of looking at it. Messy code isn't necessarily something you have to live with. And you don't have to fix all of it at once either. You can just make the next change a little better than what was there before.

I've tried to keep that idea with me throughout my career, along with a lot of the thinking that Llewellyn and Woody have shared over the years.

In practice, it comes down to something pretty simple: make the code easier for the next person to change.

That person might be you six months from now. It might be a developer who has never seen the code before. These days, it might even be an AI.

And that's where I think this stuff matters even more. When the code is simple and easy to work with, you can give a problem to someone less experienced, or to an AI, and there's a much better chance that the change they make won't leave the codebase in an even worse state.

Good code isn't just about making today's code look nice.

It's about making tomorrow's change a little less painful.