> [!tldr] By not understanding what was actually complex, I made _very_ complected things The [[PDW|Data Journal]], my enduring [[Project-Based Learning|Learning Project]], is a never-ending font of lessons learned. This is a short true story about [[Simplicity]]. The timeline of my experience with the data journal follows the progression from "don't know any better" to [[Mastery is Knowing What You Actually Need|mastery]]. I have marched from the left side, across the peak, to the right side of this graphic: ![[Pasted image 20241203210702.png]] During the period in the middle, I made a choice in the name of simplicity that ultimately lead to a **ton** of complexity. > [!quote] The Data Journal shouldn't be one thing, it should be allowed to be _many_ things! The idea was to build a _distributed_ "Personal Data Warehouse" that supported incremental and independent updates, which could be seamlessly and asynchronously merged in a highly controlled way.[^1] Honestly I still think this is the correct philosophy, but I think I went about it wrong. # Surrogate Keys > [!quote] Imagined Scenarios > - What if I want to change the name of a data point I'm capturing?! > - What if I want to change the order of the columns on the spreadsheet!? In a single-source system, you don't have worry about your [[Single Source of Truth]]. In a distributed system you do. I feared wanting to change the title of my `Sleep` measure to `Hours Slept` (for example). "Aha!" I thought, "I'll use [[Surrogate Keys]]!". Instead of `Sleep` being the key that referred to that type of measure, I'll use a randomly generated string like `FG4J`. Then I'll simply have a _display name property_ of the Measure class! This way I do the random assignment _once_, and I can change the name as often as I like! No problems. I can also have that surrogate key live _anywhere_ in the spreadsheet, and the data can still find it & map correctly! Huzzah I'm a genius. [[YAGNI]]. You know how many times I changed the names or positions of things? Maybe twice. You know how much time I spent _enabling_ those capabilities? **Way, way longer** than it would have taken to change them manually. ## [[Shortcuts App|Siri Shortcuts]], Surrogate Keys, & Literal [[Complect]]ing I use dozens of custom Siri Shortcuts to do my tracking. By introducing surrogate keys, I'd done this: ![[A Lesson in Complexity 2026-02-14 11.53.11.excalidraw.svg]] %%[[A Lesson in Complexity 2026-02-14 11.53.11.excalidraw.md|🖋 Edit in Excalidraw]]%% # The _Correct_ Way Obviously there has to be a correspondence between what's in the Siri Shortcut and the Google Sheet it's writing to... so what's the _actual simplest way_ to do this? ![[A Lesson in Complexity 2026-02-14 12.21.36.excalidraw.svg]] %%[[A Lesson in Complexity 2026-02-14 12.21.36.excalidraw.md|🖋 Edit in Excalidraw]]%% By accepting that the position of the arguments in the Siri Shortcut will match the order of the columns in the spreadsheet, I've solved the "what if I want to change the name" issue, removed the need for lookup tables, and reduced the number of lines of code by a factor of 5 or more. The new approach is **as simple as possible**. A simple rule now applies to my Data Journal - don't change the order of columns unless you also go change the shortcut for those columns. I've needed to change them zero times. It's all so obvious in retrospect. # Lesson Although complexity is _objective_, not subjective, the goal you pick in pursuit of "simplicity" matters **heaps**, and it's not always obvious what _[[Do the Simplest Thing]]_ really is. **** # More ## Source - self, painful experience [^1]: unknowingly I recreated many of the tenets of [[Local-First]] development