My Stats
Almost ten years of my GitLab activity, month by month: the commits and merge requests I open, review, and merge, going back to 2016.
A note first
Most of what I have built is closed source, so I cannot show the source code itself. These numbers are what I can show of it. They do not measure quality or performance. They measure frequency: how often the work shipped, and the busy stretches of my career, across almost ten years.
These come straight from GitLab Analytics: the commits and merge requests I open, review, and merge, going back to my first month in 2016. The busy months were busy for a reason. Demand from our customers ran high, deadlines landed back to back, and at the peak I had six or seven projects running at once.
The chart below lets you explore it month by month, by commits or merge requests.
The shape of the work
Each cell is one month; brighter means more shipped. The early stretch is thin because that is where I started, as a student assistant still finding my footing. Hover those first months and the role shows.
A few months show no recorded activity, whether genuinely quiet or simply outside what this count captures. Data as of 2026-05-30; the current month is partial.
How these are counted
- Commits are the ones I authored.
- Merge requests are the ones I opened, that were reviewed, and merged.
What the numbers leave out
What these numbers cannot show is whether the work was sound, whether it aged well, or whether the next person can pick it up. Most of the code is closed source, so the closest I can show is this:
- Code Samples puts code I wrote by hand next to the same work after an AI-assisted session, so you can judge the craft directly.
- Web Data Services is a system I led to production that other teams still build on, which is the kind of longevity these numbers cannot show.
- My Engineering Practice is the set of standards I hold all of this to in the first place.