Writing ~30 daily, deeply technical posts about the history, physics, and software guts of “time” was not something I could sit down and free-type into a CMS every morning. To keep the whole thing cohesive, connecting the 1967 cesium-second redefinition to the Y2038 bug without contradicting myself three weeks apart, I leaned hard on my research workflow.
\nI don’t have a spicy, controversial take on second brains or personal knowledge management. I have one firm opinion: every engineer should have one. That’s it.
\nThe secret to how I organized the Time series, if there is one, is that I kept it boring. Simple files, a little Markdown discipline, and everything stored locally.
\nIf you opened my Obsidian vault and looked in Research/Time/, you wouldn’t find a chaotic pile of notes. You’d find a few folders (Physics, Computing, Calendars, Measurement) and one file that mattered more than the rest: 30 Days of Time - Blog Plan.md.
That document was the central nervous system for the whole month. It didn’t hold the actual post text. It held the roadmap, stitched together with Obsidian’s cross-links. When I was plotting Week 3, the plan read like this:
\n### Day 13 - Unix time\n- Source: [[Unix Time]]\nThat [[Unix Time]] link pointed to a dedicated research note where I’d dumped every raw finding, link, and code snippet I had on the topic, including the rabbit hole on leap seconds getting smeared. The plan stayed clean and skimmable. The mess lived one click away, exactly where I needed it when I sat down to write.
Don’t go too crazy with plugins. I run a fair number of them myself and that’s fine, find the ones that genuinely help you. But the thing that actually pays off is getting good at the fundamentals of Markdown first, instead of spending a weekend configuring when you could be writing.
\nTags and cross-linking are the connective tissue. By tagging research notes with #time and #physics and linking them to each other, you build a web of context that surfaces on its own when you go to write. I didn’t have to remember where I’d put the note on atomic clocks. The links pulled it up next to everything related to it.
Tag your concepts, link your ideas, and let the structure do the remembering for you.
\nI was experimenting with building Second Brains using LLMs and agents over a year ago, and those early lessons still hold up.
\nWhen your entire knowledge base is plain, cleanly tagged, locally-stored Markdown, it becomes easy for the LLM harnesses to help you learn, explain, and synthesize your knowledge. A well-organized vault doesn’t just help your biological brain find things. It lets your AI tools act as an actual research assistant instead of a passive text generator. They can follow your [[links]], read your tags, and pull the same context you would have pulled by hand.
I’ve leaned into this hard on this project. I wrote templates, a handful of custom skills, and a few project-specific sub-agents whose whole job is to figure out how to make my harness work harder for me. That’s the general move I’d push: don’t just store context, build the small pieces of automation that turn that context into real productivity.
\nThe work you do to make a vault readable for you is the same work that makes it readable for the agents.
\nYou don’t need a perfect system on day one. I still don’t. The Time vault grew one messy note at a time until it was ready to help shape the series.
\nAs the tooling gets faster and context keeps exploding, having a system to organize your thinking is a superpower. Build something that helps you organize your Markdown, tag your concepts, and cross-link your ideas. Then keep feeding it.
\nHow are you managing your long-term research right now?
\n\n\n", "date_published": "2026-06-25T10:00:00-05:00", "url": "https://llbbl.blog/2026/06/25/how-i-researched-the-time.html", "tags": ["Writing","Ai-tools","Second-brain","Obsidian","Pkm"] } ] }I’d appreciate a follow. You can subscribe with your email below. The emails go out once a week, or you can find me on Mastodon at @logan@llbbl.blog.
\n