I lead a team of software engineers, but I still want to keep my hands on the code and work in a codebase of my own.
Nearly 300 changes over eight years. Two of those years are completely empty, and more than half of everything landed in the last stretch.
For me, as an engineering manager, a codebase of my own isn't only about writing code. It keeps me connected to the technical reality, helps me see what my team's days actually look like, lets me make better-grounded technical calls, and keeps my own skills from going rusty.
That's what I actually needed, a chance to build things again myself, to experiment, to get things wrong, to work problems out, and to learn.
Because leading a team of engineers doesn't mean you stop being one. Sometimes going back to the code yourself is what makes you a better manager.
These days other people write the code in my job. That's not a bad thing. It's a step up, and most of the time it's the best use of my time.
But there's another side to it. Over time I started to forget what it's like to go through the whole thing myself, to understand how a system fits together, to make the technical decisions, and then to live with what they cost.
This is where I keep that kind of thinking alive.
This codebase isn't perfect. Neither is its history. And that's exactly why I want to show it.
An engineering manager doesn't have to be the person writing the most code. But it's worth going back to it every so often, just so you don't forget what it feels like.
Hundreds of changes. Then two years of silence.
I've been working on this site for eight years, and its history tells my story from those years pretty well. Here's what it looks like:
For two years I didn't make a single change to it. One year, just one. The longest gap ran 732 days and ended in December 2022.
So for two years this site was just there in my life. It was mine, but I wasn't working on it.
Then look at 2026. This year I've made more changes than in any other. Not at a steady pace, more in short, intense bursts, with the quiet settling back in between them.
This isn't a story about disciplined work on a side project. It's a story about someone who finally had a bit of time and a lot of ideas.
What's more interesting is when it happened. The year I became an engineering manager turned out to be the year I did more on my own project than in some of my most active years writing code full time.
I didn't plan that, but I think it's a good thing. When your job stops depending on you writing code, you have to go out of your way to make the time to write it for yourself. Stepping back from coding isn't the same as walking away from it. This chart just reminds me that I still believe that.
And I'm showing it exactly as it is, even though it would have been easy to dress the story up.
Because the honest version is worth more:
A personal project doesn't have to be something you're always working on. It just has to be there when you feel like coming back to it.
The machinery is what matters, not the site
Here's what the site looks like under the hood right now.
After every change I make, it checks itself in a real browser, and if something breaks, it rolls back to the last good version on its own.
Every night it backs itself up, emails me the copy, and can restore the whole site if something goes sideways.
Every day it checks that the site is up and accessible. It counts errors even when visitors are running ad blockers.
There's a mechanism for database changes too, so I can apply them and undo them if I need to.
And before any code reaches the site, it gets checked against the standards I've set for myself.
The interesting part here honestly isn't the site. It's the machinery that lets me work on it safely, try things, and not worry about breaking something.
For a personal website, this is overkill. That's the whole point.
I wanted to actually understand all of it, not just sort of. A personal project is one of the few places I can pick up the parts that aren't much fun but do matter, without it landing on anyone else. If I break something, I'm the one who cleans it up.
The other way to learn this is for the first time on a project that matters, with people watching, deadlines, responsibility, and pressure. I've done it that way. This way is better.
A personal project lets you get things wrong safely, figure out what went wrong, fix it, and try again. That's exactly why it can afford to be more complicated than it has any need to be.
Because the goal here isn't a perfect site. The goal is learning to build things properly.
What my job stopped teaching me, and my own project still does
There are three things this project gives me that my day job mostly doesn't anymore.
1. I have to do all of it myself. On a team, the work gets split across people. As a manager you coordinate more, decide more, and unblock other people more, and you finish the whole thing start to end less and less. On my own project there's no one to hand it to. I come up with the idea, write the code, make the change, test it, document it, and clean up after myself. That's where I feel what being an engineer actually means again.
2. I live with the results of my decisions. When I review someone else's code and wave through a shortcut, the fallout usually doesn't reach me. On my own project it does. Make a bad technical call, or take the quick route instead of the right one, and I'm the one living with it later. That teaches you fast to tell what sounds good in theory from what actually holds up.
3. It keeps my opinions honest. It's easy to have opinions about code when you're judging someone else's. It's a lot harder to hold yourself to the same bar when it's all on you. This project keeps me honest about what I actually know, what's worth doing, and where I quietly take the easy way out myself.
And that's probably why a few of my opinions about coding have shifted while working on it.
A personal project reminds me that engineering isn't only making calls about other people's work. It's being willing to live with the results of those calls yourself.
The stretches where I wasn't working on it mattered too
The years with no changes at all aren't a failure. They're just part of the story.
Nothing depended on this site, so nothing fell over while I ignored it. It just kept running. And when I came back, it was still there.
Coming back taught me something else - the code I wrote years ago is a good test of how well I did it at the time. My past self had left me a site that still worked.
What I hadn't left were any notes on why things were built the way they were. That's exactly why the site now has a manual, and a system that reads the code and checks it against my own rules.
The core of it is simple. If your day job isn't about writing code anymore, you should still keep somewhere you can write it.
It doesn't have to be popular. It doesn't have to be steady. It doesn't have to be impressive.
It just has to be your place to try things, get them wrong, fix them, and learn.