By Friday afternoon the week's urgency has usually burned off. The big tickets are merged or punted. Standup is a memory. There's an hour or two left where nobody expects a heroic push, and into that gap I like to slip the most underrated task in software: cleaning up code nobody asked me to clean up.
It's not glamorous and it rarely shows up in a sprint report. But there's a particular calm to it that I've come to look forward to all week. Refactoring on a quiet afternoon is the programming equivalent of tidying a workshop — putting tools back where they belong so that next week's work goes smoother.
Refactoring is reading made active
The best way to understand a piece of code is to improve it. When I refactor, I'm forced to actually read — not skim — every branch, every odd variable, every comment that no longer matches the code beneath it. Renaming a confusing function means I have to decide what it really does. Extracting a tangled block means I have to find its true seams.
So even when the refactor itself is small, the understanding I gain is large. I finish the afternoon knowing the module better than I did that morning, which pays off the next time something breaks in it. Refactoring is reading with your hands instead of just your eyes, and the knowledge sticks because you earned it.
Small, safe, reversible
The trick to enjoying it — rather than detonating your weekend — is to keep the changes small, safe, and reversible. Rename a thing. Pull a function out. Replace a magic number with a named constant. Each step should leave the tests green and the behaviour identical. I'm not redesigning the architecture on a Friday; I'm sweeping the floor. The discipline is to make a hundred tiny correct moves rather than one ambitious risky one.
This is where good tests earn their keep. With a solid suite, refactoring becomes almost playful: change, run, confirm, repeat. The green bar is a little hit of reassurance every couple of minutes. Without tests, the same work is nerve-wracking, which is exactly why a Friday refactor often starts by writing the missing test first. Pin the behaviour down, then reshape the code around it with confidence.
It's an investment in next week's you
None of this is about perfectionism. Code doesn't need to be pristine; it needs to be workable. But the small messes accumulate. A slightly-wrong name here, a function doing two jobs there, a comment that lies — individually harmless, collectively a tax on every future change. A regular, low-stakes habit of tidying keeps that tax from compounding into the kind of debt that needs a whole project to repay.
And honestly, it just feels good. There's a clean satisfaction in leaving the code a little better than you found it, in the boy-scout sense. You close the laptop on Friday knowing that Monday's you walks into a slightly kinder codebase. That's a small, real kindness — the kind we don't extend to ourselves often enough.
So if your Friday afternoon ever feels aimless, open the file that's been quietly annoying you and spend an hour making it nicer. Nobody will thank you. You won't put it in the standup. But the work will be there, quietly making everything afterward a fraction easier, which is most of what good engineering ever is.
