If you find a module that has not been touched in five years, you treat it with suspicion. The world has changed. The dependencies are old. The patterns are out of date. Maybe the original author had constraints that no longer apply. The code might still be working, but you read it with one question in your head: “if I were starting this today, would I build it the same way?”. Often the answer is no, and that is when you refactor.
I have come to believe the same thing about a career. A career that has been on autopilot for five years is suspect. The skills that mattered then matter less now. Maybe the version of you that picked this path had constraints (financial, geographical, emotional) that no longer apply. The career might still be working, in the narrow sense that the salary lands. But if you ask “if I were starting today, knowing what I know now, would I build the same path?”, the honest answer is sometimes no. That is when it is time for a refactor pass.
I do this on a roughly two-year cadence. It is one of the most uncomfortable hours of the year and one of the most useful.
Why two years and not five
Refactoring code that has not been touched in five years is harder than refactoring code that has not been touched in two. The drift compounds. The longer you leave it, the bigger the gap between the world the code assumes and the world it runs in, and the more the refactor looks like a rewrite.
Careers are the same. Two years is not magic; it is the longest interval where a mid-course correction is still cheap. At two years you can still pivot inside your company, still pick up a new specialisation without a full reset. At five years, the same pivot is a much bigger move: your CV, network, skills, and self-image have settled into a shape, and changing that shape is genuinely hard work.
I think of the bi-annual review as a small refactor commit. You are not rewriting the whole thing. You are looking for the parts that aged badly and nudging them. Nudging every two years compounds far more than one big rewrite every ten.
The questions I ask myself
The actual exercise takes me about an hour, with a notebook, away from a computer. The point is not to produce a glossy document; it is to be honest with myself for sixty minutes.
The questions I ask, in order:
What have I learned in the last two years that I did not know before? Be concrete. Not “I learned dbt”, but “I learned how to model a slowly changing dimension well in dbt, write a clean macro, and think about test coverage on transformations”. If the list is short, that is itself a finding.
Where am I getting bored? Boredom is information. It is the brain saying you have stopped learning at the rate you used to. Sometimes that is fine. Sometimes it is the early signal that the role has stopped fitting.
What skill did I have two years ago that has atrophied? Uncomfortable question. The skill you used every day three jobs ago, that you would have put on your CV with confidence, is now rusty. Maybe that is correct. Maybe it is a warning that you have specialised too narrowly.
Would I hire today’s me, for the job I want in two years? This is the brutal version of the CV question, and the one that produces the clearest list of things to change.
What have I been putting off because it is “a big project” that, if I started this week, would meaningfully change my next two years? Write a public blog post. Do the certification. Apply to the conference talk. The execution rarely takes as long as the avoidance.
I write all of this in a Notion page that I keep year after year. I do not look at the previous entries until I am done with the current one. Then I open last year’s page and read it. The compounding signal from reading three or four of these in a row is the most valuable artifact of the exercise.
The cost of inertia
The trap I am trying to avoid is “the seven-year senior who is actually a two-year senior repeated three and a half times”. You have seen this person. Same job, minor variations, for the better part of a decade. Competent at that job, would also struggle in a meaningfully different one, because they stopped growing around year two and have been treading water since.
This is a socially invisible failure. Nobody notices, because the person is still delivering, still showing up, still shipping. The company is happy in the short term. The person is the one paying: their market value has stopped growing, their options have narrowed, the next job they want is harder to get than it would have been if they had stayed sharp.
I have a friend who spent eight years at the same company doing the same kind of integration work. Genuinely good at it. When he tried to leave, he discovered the industry had moved on. The tools he had mastered were no longer the tools people were hiring for. He spent a year on an unhappy job search before landing something at a level lower than he expected. A refactor pass at year three or year five would have caught it.
The cost of inertia is asymmetric. When things are going fine, the cost is invisible and a refactor feels low-value. When things stop going fine, the cost is suddenly enormous, and you cannot go back and run the refactor you skipped.
Small refactors versus rewrites
Not every refactor pass leads to a big change. Most of mine have produced small ones. That is by design.
The small refactors are things like: sign up for a course on the new tool the team is moving to. Ask for a project rotation into the team you secretly want to be on. Start writing publicly, even one post a quarter, on something you are learning. Volunteer to onboard the next new hire, because teaching is the fastest way to find out what you actually understand. Pick up a side project deliberately outside your day-job stack, to keep the breadth honest.
These are the equivalent of a one-line code refactor: extract a helper, rename a variable, split a long function into two. The activation energy is low, and they compound. Five small career refactors a year is, after a decade, an entirely different career.
The big refactors are rare. Change company. Change specialisation. Move from full-time to freelance, or back. Move country. Take a year off. These are real, and sometimes they are the right call, but they should be a small fraction of the refactors you do. If every two-year review produces “I should change company”, the issue is probably not the company.
The signal that a big refactor is needed is when several small refactors have not moved the needle. You took the course, joined the new team, wrote the blog posts, and you still answer “no” to “would I hire today’s me?”. At that point the structural decision underneath is wrong, and only a structural change will fix it.
The personal architecture decision record
Software engineers have a tool for keeping track of why they made the decisions they made: the architecture decision record, or ADR. A short document, written at the time, explaining the choice, the alternatives, the constraints, and why this option won. Years later, when somebody asks “why did we build it this way?”, the ADR is the answer.
I have started doing the same for my own career. A short note, written at the time, every time I make a non-trivial decision. Took the freelance contract: why, what was the alternative, what was I worried about. Stopped pursuing the management track: why, what would have to change for me to reconsider. Picked up Spanish instead of polishing my French: why, on what timeline.
The notes are short, two paragraphs at most. I write them because the version of me reading them in three years will have a sharper view of whether the decision aged well, and the only way to make that judgement is to know what I was thinking at the time.
The thing this catches over the long run is drift. A career rarely changes in one big visible step. It changes through a series of small decisions, each reasonable in the moment, that together add up to a place you did not mean to end up. The personal ADR is the audit trail. When the bi-annual refactor pass runs, the ADRs are the evidence I read first.
A useful prompt: have I read a paper, picked up a substantial new tool, or had a serious new technical conversation since the last refactor? If the answer is “no, not really”, that is the smoke alarm. The career has stopped getting input. The output will follow.
Refactoring is the part of software work that is least glamorous and most consequential. The codebases that age well are the ones whose owners ran a small refactor pass every couple of years, before the rot got bad. Careers are the same. Set the recurring calendar event, sit down with a notebook, ask the uncomfortable questions, and write down what changed and what didn’t.