Daily Notes for 2024-02-13

ยท 1137 words ยท 6 minute read

Gave Logseq a shot ๐Ÿ”—

… I really did. I don’t think it’s gonna take.

There’s a lot to like about it, and if your whole thing is “I’m gonna go try this new model of thinking about things,” it’s a fine representative of the smart/connected/non-hierarchical etc. notes market. It is very outline-centric, so org-mode and Workflowy people will feel more at home.

The approach I took to my trial was to just go with its preference for daily journal pages as the starting point. I did do an overlay on that using PARA, more or less.

  • Daily pages included a section for meeting notes, a task inbox, and a section I called “facts” that was just meant to be “random snippets of this and that flowing in throughout the day.”
  • My project pages included project notes and project-specific tasks.
  • My area pages included notes and tasks that I knew were related to a given area when I created them.

Logseq includes a built-in TODO page that gathers all your open tasks, which you really need if you’re dumping todos into daily pages. On a desktop monitor it feels manageable. On a laptop panel, especially one with a 16:9 ratio, it feels overwhelming if you have many open tasks.

I came across a number of strategies for dealing with the problem of “loose tasks flying around in your note volume” including review of the TODO page, custom queries, and the use of a plugin that offers a way to quickly scroll through available tasks and inject the ones you want to tackle today into your journal.

Another plugin provided a way to automatically roll daily journal tasks over with the creation of a new daily page, but it threw me a few curveballs after a day of trying to use it without having to think about it.

Two obvious comparisons to make are org-mode in Emacs and Obsidian.

If you like the thought of a very outline-oriented notes and tasks manager, but wish there was a more robust and purpose-built sync capability than org-mode offers, Logseq offers org-mode syntax and has a paid sync capability that seems to work pretty well. If you don’t care about a mobile use case I don’t know why you’d pay for sync when there are things like Dropbox and Syncthing. But if getting at your stuff on your phone matters and you’re sort of over trying to make Beorg or Plainorg work, Logseq might be interesting.

Obsidian is the real competitor, though, and as I read through forums and subreddits I saw some hair-splitting over which solution was “better” based on features that come out-of-the-box. Logseq does have better built-in task management stuff, but a single, very mature plugin in Obsidian closes that gap and then exceeds Logseq’s out-of-the-box experience, and you’re back to finding plugins to get parity.

I’d be remiss to leave out org-roam (Emacs) and Denote (also Emacs). If your use case is just notes with no tasks, either of these will work pretty well, too. You’re just left with the sync challenge, and neither is suitable for mobile (IMHO … livable, but not great). I said “just notes with no tasks” because org-mode’s agenda, which is generally how you’re going to aggregate todos across a bunch of connected notes, has known scale issues over time as you add more and more files as potential sources of tasks. If you don’t mind adding more custom lisp and a package or two you can overcome that. You’re still left with the mobile problem.

What about one big page? ๐Ÿ”—

I thought about that, too, after a little Ed trolling. I’ve done the whole “one big org file” thing in the past, but that was a simpler time.

I did model PARA into a single org file, tweaked a few org-capture templates, and made some conventions to take advantage of the :CATEGORY: property and tags inheritance. That made the agenda a lot more digestible and useful.

The single-file approach also lets Beorg and Plainorg work pretty well.

That isn’t exactly a “connected notes” thing anymore. It’s more like Workflowy, and that’s if you’re doing it in org. I can’t imagine doing it without org-mode’s assistance. Too much going on.

Migration day ๐Ÿ”—

I’m sitting on a call with a migration specialist from Jamf, having promised the team that I’d be available to yell or threaten if they requested it. This is our third go at effecting a migration off of self-hosted infra and into their cloud. Fingers crossed Went fine. We’ll be able to decom a load balancer along with several compute and db nodes. We’ve also observed that a few backoffice integrations work much better in their cloud instance, meaning better reporting about the state of our end user compute fleet.

We’re sort of in a change season right now: In the coming half we’ve got a new password manager, a VPN refresh and some bits and bobs to improve our SSO situation. Getting Jamf in the rear-view mirror means a significant amount of headspace opens up for the team and will vastly improve our chances of success on one major initiative I pulled forward by two quarters and have sitting on the dock, awaiting a more reliable endpoint management setup to take advantage of it. Better reporting also means we’ll be able to make good on a major change we made to laptop fleet management that has improved our hardware budgeting situation a lot, but has needed better insight to really sing.

I took this job knowing there’d be a lot of simplification work to get through, and it hasn’t disappointed. There are days I want to pull my hair out – like the first and second times we had to scrub our Jamf migration – but there are also plenty of days when things come together and I clock out knowing we took a step forward.

Most days I also ask myself what’s compelling about all this to me. IT’s generally thankless work. But “run services orgs” is pretty much what I do, even when I’ve led engineering teams who probably didn’t want to think of themselves that way. I think the simplest answer is “you can help a lot of people and make a lot of things better,” including for the people who are also asking themselves why on earth they’re in IT every couple of days.

I also happen to like unknotting Christmas tree lights.

Kill It With Fire ๐Ÿ”—

Through this change season, I’ve been noticing and appreciating my Readwise notes from Kill It With Fire, Marianne Bellotti’s excellent book on dealing with legacy systems. I read it thinking it would be more “technical,” but it’s as much about the leadership and cultural challenges of dealing with legacy systems. Right up there with Camille Fourier’s The Manager’s Path.