For 25 years I've been the person in the room asking to see the data. In incident reviews, in planning meetings, in one-on-ones with engineers who were sure their service was fine because nobody had complained yet, I've said some version of the same sentence: if you can't see it, you can't run it. I believed it. I still do. But this summer I noticed something that made me more curious than I expected: I had spent a whole career measuring other people's work and had never once measured my own.
My own career ran on good intentions: learn more about agents, write more, finally ship something. All true, all vague, and all impossible to learn from, because you can't miss a target you never set. And if you can't miss, you can't find out anything new.
So in late June I tried to do to myself what I'd done to every system I've ever owned. Metrics, a schedule, a few hard rules, and a promise to look at the numbers even when they were bad. It turned into the most interesting experiment I've run in years. I'm not writing this as advice. These are notes from someone still in the middle of figuring it out, and I'm hoping people who've tried something similar will tell me what I'm missing.
What I Built, and Why It Was So Small
I kept it deliberately boring: three markdown files in an Obsidian vault. A metrics page tracking where my time goes, what's covered, and how fast things ship. A weekly schedule with slots for building, writing, open source, and talking to people, planned out to October 2027, which is absurd and which I rephase constantly. And one rule: a project isn't real until it has code, docs, and a published article. All three, or it doesn't count.
I made it small on purpose, because I know my pattern. Designing systems is my comfort zone. Using them, and letting them tell me things, is where the learning actually happens. Keeping the setup plain meant I spent my energy on the second part.
The Numbers, and What They Hid
Twelve weeks produced forty-plus articles on dev.to and Hashnode, more than a dozen open-source tools, flagship test suites between 800 and 1,500 tests each, and a metrics file now on version 93. When I first wrote that list down I felt proud. Then I got curious, because these are exactly the numbers I'd ask questions about if someone on my team presented them. The interesting stuff lives in the gaps between them.
What Didn't Work, and What It Taught Me
I broke my own rule on day one, and I know why
My publishing rule says one article a week, so each piece can stay the best thing on its topic for months. On July 10, the very first day, I published three. In September I published eight in four days from a single series.
I had reasons both times. The drafts were done, and waiting felt wasteful. The more honest reason is that I wanted to see the numbers move. The cadence rule was there to protect the reader, and I'd forgotten that. If someone on my team had proposed eight posts in four days, I'd have asked who it was for. Now I ask myself that before I hit publish, and that one question has made my writing noticeably better.
I built a dashboard that told me what I wanted to hear
My first metrics page counted output: articles written, notes created, projects started. The lines went up every week, and I felt productive looking at them. It took me weeks to see I'd built a vanity dashboard. It couldn't tell a throwaway note from a shipped tool.
I've caught that mistake in other people's quarterly reviews in five seconds. Missing it in my own taught me something useful: blind spots are called that for a reason, and even a file you wrote yourself can give you the outside view you need. The page now opens with a note to myself: "This page no longer primarily measures content volume." It tracks systems that work, writing people actually read, and evidence I could hand a stranger. It's a much more useful page now, and honestly a more interesting one to open every week.
The dashboard turned into a diary
By version 93, the header of that file had grown so long my editor truncates it at 2,000 characters. Every release and decision got appended, because deleting anything felt like erasing my own history. It stopped being a tool for seeing clearly and became a record that I'd been busy. I suspect many engineers do the same thing. We keep old alerts, dashboards, and branches around as receipts for effort. Personal observability drifts the way production observability does, and it turns out the fix is the same too: prune, archive anything past 400 lines, and keep only what helps you decide. It's a small habit, and I'm glad I picked it up.
What Worked, and Why It Surprised Me
Finishing mattered more than starting
The "code, docs, and article" rule broke my oldest habit: the project that's 80% done. I've carried dozens of those over the years. They feel like progress without ever reaching the point where you find out if the idea works. Under this rule they earn nothing, so I started finishing smaller things instead of starting bigger ones, and finishing turned out to be where all the surprises were.
Writing the article also turned out to be my most honest test. When I wrote up an AI review engine where two models are supposed to argue about a pull request, I went back to the raw logs for a quote and found the second model wasn't arguing at all. It was replaying pre-generated text. 89% of what I'd built was theater. The tests were green and the demo looked great. Only explaining it in plain words made me read closely enough to see it. I've come to think writing isn't how I share what I've learned. It's how I find out whether I've learned anything.
Letting go of 22 ideas felt lighter than I expected
In one week this quarter I retired 22 project notes. They weren't shower thoughts. They were designed, scoped, and some of them had been with me for months. A bigger effort covered what they were meant to do and did it better, so each got a banner saying what absorbed it, a link to its new home, and I moved on.
I expected that to hurt. For most of my career I've quietly tied my identity to being the person with ideas. Retiring them felt like it should be a loss. Instead it felt like deleting dead code, one of the most satisfying things an engineer gets to do. That told me something. Maybe what I'd been attached to wasn't the ideas. It was the feeling of having options. Committing to fewer things has been freeing in a way I didn't expect, and the ideas I kept are getting far more of my attention.
A wrong plan was still an honest one
My schedule is wrong constantly. When I made agent security my main focus from October through February, that single decision pushed about 18 weeks of plans back, and I could see exactly which ones moved. Without it, I'd have said yes to everything and spent months wondering why nothing finished. The same happened with writing: in September I studied the top 30 recent posts on dev.to and rewrote my publishing rules around them. Several of my strong opinions turned out to be wrong. That was genuinely exciting, because it was the first time my writing got an opinion from something other than my own taste.
What I'm Still Learning
I went into this expecting better numbers. What I got was an argument. The dashboard kept disagreeing with my gut, and about half the time the dashboard was wrong and half the time I was. When everything lived in my head, I never lost an argument with myself, so I never learned anything from one. Now there's something on the other side of the table, and I'm learning faster than I have in years.
The question I ask most weeks has changed too. It used to be "what should I learn next?" Now it's "what's starved?", which usually points somewhere I hadn't thought to look.
What I'm Still Trying to Figure Out
I can game my own metrics, and on tired weeks I have. I don't know how people who've done this longer keep themselves honest. Nothing on my dashboard goes red when I'm running on four hours of sleep, and I haven't found a good way to measure rest. And this is one person over twelve weeks. It's an experiment I'm going to keep running, and I'd much rather learn from people further along than reinvent everything myself.
Your Turn
I'd really like to learn how other people handle this, especially people who spend their working lives measuring systems.
Do you measure your own career, or only your team's work? If you do, what's worked for you that I should steal?
How do you keep a personal metric from being gamed by the person who wrote it?
What's the metric you'd be most curious (or nervous) to put on your own dashboard? For me it was "articles people actually read" sitting next to "articles I wrote."
Have you ever let go of an idea you were attached to, and felt lighter instead of worse?
And the one I keep coming back to: if an honest dashboard showed you your career tomorrow, what do you hope it would say, and what do you think it actually would?
