If you’ve been watching this blog, you probably have seen that I tend to tag my posts with how many days I’ve been working on a project; I also try to keep that metric up to date in the list of projects at https://slashie.net… but why?
I don’t know. It just gives me some perspective of how much of my life has a particular project eaten… I guess.
It’s an approximate metric that I used to track manually in the old times of the blog, around 2008. Recently as I started microblogging again, I brought it back. The problem is: it’s easy for the number to slip away. Thankfully, we have better tools than we did in 2008.
This one was very quick from inception to publishing on npm: the scope was clear: getting an idea of how many days you have worked in a project, based on the git history. I had actually already used claude to make a throw-away similar tool to get the number for Emerald Woods (it yield 210 days of work), so it was a question of packaging it nicely.
Create a nodejs I can install globally that I can run inside a git repository and will tell me how many different days of work registered in the current branch, something like npx run howManyDays
The initial prompt covered most of it, which of course brings the question of whether this kind of tooling makes sense to be packaged, maintained, and published, when a developer can roll their own quickly.
This specific case, however, I think is worth it for the convenience and to be able to reliably obtain comparable numbers across projects through the years, as technology keeps evolving.
So there it is, how-many-days in npmjs. Just run `npx how-many-days` in some old project, and get surprised by the results (I got 584 days at Ananias and.. 778 days to my name in NovaMundi! these are big spans on my life)
Slashie's Gamedev Adventures 