The Full Monty
There's no hiding from realityPurpose
Initially there was the idea (not mine) of using a Monte Carlo simulation to estimate how long certain tasks would take. That turned out to be quite useful, offering a statistical counterweight to my intuition and "stripping" it of self-deception (hence the name and logo).
The Quantified Self philosophy is notoriously easy to overdo: when you start tracking and analyzing something, you get the urge to do the same for absolutely everything else, which makes this project both a data-driven exploration of certain aspects of my life and work, as well as an excercise in self-restraint.
What are my goals?
Understanding
Ultimately, the main goal of this project has always been understanding, whether I decide to act upon that understanding or not.
For example, I use Full Monty to adjust the estimates I give when talking with co-workers about ETAs, and I'm actively trying to reduce the variance between my original estimate and the simulation.
When it comes to tracking the volume of the packages I receive, however, I'm just kinda curious to see if there are trends in my behaviour.
Skill building
Part of the impetus for Full Monty to be a web-app instead of a native one is simply that I wanted more exposure to tools we don't use often (or at all) in my day-to-day work, for example NextJS and GraphQL. This actually made the project suffer a bit since some technological forces were dictated by what I wanted use versus what might have been best for its scope (e.g. React vs Svelte, MongoDB vs SQLite, a web-app vs a native or Electron one).
The stack
This project is as much for my edification as it is for keeping my skills fresh when it comes to current industry standards, and the stack therefore leans heavily towards React. The choice of datastore was largely dictated by wanting flexibility, but the data turned out to be quite well-defined, which resulted in a switch from MongoDB to SQLite for portability (and removing unnecessary complexity).
