Lots of kind words poured in as a response to My approach to GTD and PKM, and one question was asked so frequently that I decided to write about it.

Why is “Get mom a birthday present” a project and not a task?

GTD is very orthodox in what a “project” is: it’s anything that:

1. you think you’ll complete in the next year
2. requires more than one step to complete.

I used to think this was an overly broad definition for things like “buy mom a present”, “install weight rack”, etc and would just have them sit as tasks.

Over the past year, though, I've come to realize that this was not quite ideal. It's hard to read "buy mom a present" as a task when I'm looking for something idly to do between meetings or during weekly review; it's discrete, sure, but not so immediately actionable that I know exactly what to do or when to sequence it. (This is in contrast with, say, "buy mom a signed copy of Piranesi", where the action is clear and the time required is obvious.)

So: more things have become "projects". This has a couple second-order effects:

1. I'm forced to actually think about what the next step is for these smaller things, which is useful — especially the past month, where with Lucy the amount of executive function and mental capacity I have to actually do something is pretty limited.
2. At any point in time I have more projects active than I am used to, which is of course Not Ideal (context switching is hard! work in progress is bad!) but also truer than pretending I only ever have two or three things bouncing around my head at any given time.

(Again: none of this stuff has inherent merit; it's only useful insofaras it lets me spend my time more effectively and calm my mind so that I can focus on what I'm doing at any given point in time. But GTD does do those things, at least for me.)

Earlier this week, I stumbled upon this brilliant marketing-slash-documentation idea from SingleStore — notebooks as a first-party page! There are a handful of nice things about this idea:

• Very easy to fan out. You're not going to really run out of sample notebooks from which you can create pages.
• Easy to share and 'productize'.
• Lends itself obviously to both onboarding and existing users ("try it now" for people who aren't signed in, "use my API key" for people who are.)
• Doesn't require narrative or cohesion in the same way the same content as a blog post does.

I wouldn't be surprised if this doesn't become much more popular across developer tools businesses in the next few years.

One pernicious thing with writing about productivity and knowledge systems: you only change systems that aren’t working, and you tend to write about things during times of change. So most writing about productivity systems stem from people whose systems have failed them.

It is with this ironic prologue that I answer a question I've received from a few folks in reference to my usesthis.com interview:

Curious if you could share a bit more about how you use Things & Obsidian? I love Things but feel like I’m kind of holding it wrong. And haven’t yet been able to get into Obsidian.

Things

I have used Things for six years now; as of today, this is what my setup looks like.

I think Things is pretty much the perfect amount of organizational detail for most people: it encourages just the right amount of planning and administrivia without letting you delude yourself into thinking nested projects and deep meta-gardening of your work is anything more than cosplay.

The only change in how I use Things over this time has been how I organize my "Areas". Running a company, co-running a holding firm, being an active husband and father — my days and my schedules are much less neatly organized than they used to, and at any given point in time I have the temporal freedom to work on anything. This freedom is nice, but also a little bit difficult to wrangle: how do I know if I should be working on a new marketing initiative or setting up a 529 for Lucy? Breaking stuff up into my core identities as a person helps (though this is mostly just syntactic sugar around Home / Work / Side projects / Leisure, if we're being honest.)

Beyond that, Things' guide is really good. The only other bits of flavor I'd add:

1. Tags are useful in small doses. I only really use two: Phone and Errand.
2. Only use deadlines for things that are actually exogenous (customer-facing features, government regulations, birthdays, etc.) Otherwise, you run into a kind of urgency fatigue.
3. Being a founder means having a lot of stuff in the air, whether due to delegation or being blocked. For things that I'm waiting on in a non-temporal way, I prefix those projects with ×.
4. Conversely, "unfinishable projects" (blog posts to read, writing ideas, etc.) I prefix with ♾️.

Obsidian

I don't use Obsidian any more! I really love/loved it: it is a delightful piece of software to use, but everything I put into it I needed to share with other people (both technical and non-technical) — so off to Notion it went.

("But Obsidian for Teams is a thing", you might say! This is technically but not really true; it's not something that I can feasibly put in front of a tier one CS rep and expect them to be able to both consume and edit.)

("What about the stuff that you don't need to share with anything else?", one might ask. I posit to you: this information probably does not need to be recorded, and you probably have better things to do with your time.)

I use Notion for this now, and Notion is... fine. It gets the job done; everyone knows how to use it, cross-linking is really useful, the application is slower than I would prefer. It is not a decision or product that feels like it makes a huge impact in my life.

The goal is to do good work

In general, I am much more suspicious of PKM as a field than ever before. Andy Matuschak puts it well:

Most people who write about note-taking don’t seem particularly accomplished in their own fields, whatever those may be. In fact, most such writers aren’t applying their notes to some exogenous creative problem: their primary creative work is writing about productivity. These writers offer advice on note-taking to help scientists and executives with the challenges of their work, but the advice was developed in a context disconnected from those external realities.

My information-related problems in 2024 can be summed up in three ways:

1. I am often juggling dozens of projects of varying cadence, urgency, and aperture, and it's easy for me to forget certain things.
2. I have a lot of internal/tribal knowledge that doesn't neatly fit into some existing repository (codebase, blog, Slack) but should be shared with others.
3. It's easy for me to overfocus on short-term urgent work to the detriment of longer-term, more important but less time-sensitive work.

These problems were not the same as my problems in 2020; I suspect they will not be the same as my problems in 2028.

Solutions are only good insofaras they solve your problems; before committing to Yet Another App or Yet Another Methodology, ask yourself if really what you need is eight hours of sleep, a long walk on a sunny day, or a particularly good Manhattan and a particularly engrossing book. These things cannot be bought on Gumroad for $49 (with a cohort-based video series for an additional $299), but tend to be much more efficacious.

The advice might seem dated these days, but I think the stair step approach to bootstrapping is evergreen:

It’s much easier to sell an add-on to an existing ecosystem like a WordPress plugin, a Shopify app, a Heroku add-on – they’re usually small things to build, relatively inexpensive for customers to purchase, and you have built in discovery through the plugin repository or app store.   Other examples include Magento or Drupal add-ons, a Photoshop plugin, a WordPress theme, or an ebook or course.

These are all great examples for how to obviate marketing as a huge concern for a first product, but they also share a certain sense of finality that a full-fledged SaaS rarely does. Once you've built the thing and added it to the marketing channel of choice, it is done (modulo minor going concerns like changes to the underlying ecosystem, version updates, et cetera.) It is very hard to spend too much tinkering around the margins on a fifty page book or a Shopify <> Helpscout connector, and that inability is a feature that gently nudges you onto greener pastures.

This is a circuitous path to my suggestion of a new genre of entry-level product for the prospective bootstrapper, which I will call the data product. Here are some examples:

• A beautiful and meticulous dossier for various iOS devices and their screen sizes
• A dense tabular UI to poke around various AWS instance prices
• An even denser tabular UI to poke around SSD prices

These projects have many merits: they are small in scope, require few engineering decisions that could cause an otherwise well-intentioned engineer to bikeshed, easily marketable, and lend themselves to expansion into adjacent products.

A prior iteration of this site had a page called "Project ideas" that listed a bunch of things that I'd like to build. This was a good idea and useful in its own right (I got a few people to build companies and projects based on them, and it was a useful avenue by which folks could tell me which ideas were already implemented.)

I still haven't quite worked out how this current iteration of my site should handle these sorts of long-form mutable catalog-style posts: the whole thing is really organized around a central timeline, and in lieu of search or a colophon page its harder to designate a given post as an evergreen dumping ground. So instead, I'm just going to batch a few ideas every few months.

(If you end up exploring any of these ideas, please let me know!)

Fuzzy search atop git history

There's a lot of interesting work around applying LLM-powered search to software development workflows; many of these are inordinately ambitious (You gotta be able to taste the kool-aid), to the detriment of the more mundane but solvable problems. Things like:

1. "Which commit introduced the Automation model?"
2. "Which of my myriad stashes contains the exploration work I was doing on a new splash page?"
3. "What un-merged branches touch the markdown rendering engine?"

API wrapper around RDS Performance Insights

One genre of project that I stubbornly refuse to change my priors on despite a dearth of success stories (RIP Briefmetrics!) is: "UI wrapper around obscure/arcane/annoying but valuable FAANG API." RDS Performance Insights is a great example of this, and one can even purloin the great work done by Planetscale to find an early form factor that works well.

A better search around chat.db.

iMessage is one of the biggest social networks in the world; every MacBook has its entire iMessage history stored in a SQLite database called chat.db. It is wild to me that there aren't more projects that take advantage of this, given how annoying it is to actually search and collate one's iMessage history at scale?

...I always hammer on locked doors.

What's that supposed to mean?

The Anderson Tapes was released in 1971, placing it a decade after the original Ocean's Eleven (perhaps the first film to boldly ask: what if committing a heist was really cool?) and before The Conversation, a film more widely credited as introducing the concept of surveillance to the American filmgoer.

The Conversation only came out three years after The Anderson Tapes, and yet its treatment of surveillance is somehow much more postmodern and cynical; Coppola is interested in the interiority and paranoia of his characters, and it is taken for granted that everyone involved is already aware of their wiretapped lives (in no small part, I suspect, due to Watergate happening between these two films.)

This film, conversely, treats surveillance with a heavy-handed sincerity that could be construed as gimmicky ^[1] if it weren't so prescient. This is a straightforward movie with a straightforward message: we have spent the past decade building the Panopticon, and no amount of Scottish charm or ingenuity will purchase your escape.

Connery is great, of course, and there are bit parts to enjoy outside its use as a time capsule (a young, sinewy Christopher Walken; a Burn After Reading-esque denoument) but the enduring virtue of this film fifty years after its release is its wisdom in understanding exactly how and why the world changed, and to what end.

The total LOC delta to migrate Buttondown from Django 4 to Django 5 was +143, -150. (I was incentivized to do so because our search right now is quite slow, and the lowest hanging piece of fruit is to move some of the tsvector generation out of band, and I'd rather do that using the fancy new GeneratedField abstraction than rolling the SQL myself.)

The process was so boring as to almost not warrant a blog post:

1. Had to remove our usage of DEFAULT_FILE_STORAGE and roll it into the STORAGES dict which we were already using;
2. Had to bump up django-typescript-routes and django-safedelete to new minor versions (and for the latter create a new migration);
3. Had to trivially rewrite a few tests that were failing because we were incorrectly passing in some non-existent keyword arguments.

The one wrinkle was some still-unattributable change in Whitenoise / Django behavior; we were using CompressedManifestStaticFilesStorage and some of our vended CSS had, I guess, incorrect manifests? It's still not immediately obvious to me what the root cause was, but it was an easy enough fix.

Django 5's been in production for us for three days. A grand total of zero post-deploy bugs have surfaced.

There are few pleasures greater than getting to be profiled for an interview series that you've been reading for months, and last week I got to do exactly that.

To browse Manu's site — not just this interview series — feels a bit like walking on a quiet beach in autumn: there's a sense of peace and timelessness that is hard to find in the hustle and bustle of the increasingly-cacophonous internet. Fittingly, the interview is centered on the why and how of blogging:

It’s gone on a series of reinventions since then: my ability to consistently write has waxed and waned, but I keep coming back to this notion — particularly lately — that building artifacts under my own domain’s auspices is more durable and valuable than throwing them out into the algorithmic ether.

Whenever I really struggle with a book, I try to start from a place of authorial intent: what did the writer wish to accomplish with their writing? I find this particularly useful with postmodern + experimental work, as it lets me divorce my reaction to the form from my reaction to the work itself. Sometimes the answer is onanistic delight (If On A Winter's Night A Traveler, Pale Fire); sometimes it is meant to conjure a certain thesis about the exultatory power of art itself (Cloud Atlas, Ship of Theseus); sometimes it is meant to discuss the subjectivity of perspective and importance of interiority (Rashomon, The Hunting Gun).

Diaz' message with Trust is a melange of the latter two: art and capital are more similar forms of power than you suspect, he argues, and power has a tendency to occlude itself.

This is a bold organizing ethos — it is no wonder this book contended for and won a Pulitzer! — but it is hard to find much supporting material in the prose and character work.

We open Trust with a novella called Bonds, which we later understand to be considered not just (to quote the book itself!) a literary achievement that could have come from Edith Wharton or Henry James but a scathing exposé akin to those of Sinclair Lewis. Instead, it reads like a Wikipedia summary of the Carnegie family, with flat prose and characters sanded down to one-sentence flash cards.

This is what I've grown to call the Studio 60 on the Sunset Strip problem: it's really hard to depict diegetically what the reader must consider "a great work", whether its sketch comedy (in Studio 60's case) or bold, brilliant early twentieth century writing (in Trust's).

And once we've escaped the meta-fictional world of Bonds into the world of the Bevels, on whom Bonds is purportedly based, things are no better. Much post-Pulitzer hay has been made of Trust's desire to understand capital and patriarchy; this desire, if extant, is bloodless. Many sums, movements, and theories about capital, financialization, and soft power are discussed — they all seem as though Diaz spent his time trawling through Investopedia, and assuming his readers are more interested in vibes than barbs. (This inattention to detail transcends the financial aspects of Trust. Diaz also, not thinking readers of a memoir from a New Yorker writer would know what the Voynich Manuscript is, dedicates a two page exegesis to it; he also deploys gaslighting as a verb even though that phrasology only began in recent decades.)

The final section of the book — in which we are revealed that more than anything Trust is a murder mystery, and we get to hear from the woman behind the mask — is both the most controversial and the most interesting. Diaz is most interested in a sort of meta-feminism, revealing that Mildred orchestrated (really) the Great Depression. From an interview:

Mildred was not a victim, was not a sacrificial lamb. And I think the passage that you just quoted shows her agency and with agency comes responsibility, mistakes or the possibility of making mistakes.

I think this is where Trust succeeded the most — the visceral joy you get when suddenly you get to recontextualize all that came before, and various puzzle pieces lock into place.

But it's a shame about all the other stuff along the way.

Highlights

Today's gentleman is yesterday's upstart.

I am a financier in a city ruled by financiers. My father was a financier in a city ruled by industrialists. His father was a financier in a city ruled by merchants. His father was a financier in a city ruled by a tight-knit society, indolent and priggish, like most provincial aristocracies. These four cities are one and the same, New York.

"There is a better world,” a man said. “But it's more expensive."

You say that these numbers mean dial it down. I say they mean dial it up. You haven't gotten through. There are people you haven't persuaded yet. These number mean dial it up. Otherwise you're like the French radical, watching the crowd run by and saying, "There go my people. I must find out where they're going so I can lead them."

I ran into a great post from Karri of Linear on product management. Most of what he says warrants further discussion and digestion, but I wanted to chime in on the rhetorical question which prompted his lovely response:

Consider this: if “talk to customers” is the biggest secret to product success, then why aren’t more products successful? Why are so many founders unsuccessful? What explains PMs who’ve been talking to customers 5 times a week for years, without ever making products that win?

"Talk to customers" has become, to me, the same kind of truism as "charge more" and "users don't care about your codebase" — easy to deploy and sound clever in doing so, but dangerous in their banality.

At risk of deploying a metaphor (c.f. The taste of beer), customer feedback is something like a GPS: faster than driving aimlessly, slower than knowing the streets like the back of your hand. Especially in commodity/parity-style industries (like product management tools in Karri's case, or email in mine) customers make for good historians but poor futurists, and certainly they won't do the hardest and most important job of identifying your leverage points for you.

None of this is to say you shouldn't talk to customers: you should! But it should be neither the first nor the last step in your process: if someone needs to talk with people to figure out what to build next, it means they have insufficient vision; if someone needs to talk with people to figure out if something is truly ready for GA it means your org has insufficient conviction and process.

Customers are great at informing a product: reminding you of edge cases, blind spots, prior art, and so on. But there are many incredible things that can be built without information, and the annals of history are swamped with products that had very well-informed backlogs and yet no leverage or power to stop their own demise.

It is rare and difficult for a long-running series to reverse a downward slide. There are simply too many sources of gravity: writers run out of obvious plot lines and have to start re-hashing, Flanderizing, and escaping the confines of the show's existing logic; actors change, and audiences grow tired of what was once novel; it is simply hard to capture lightning and put it back into the bottle, and the commercial demands of the television industry incentivize showrunners to turn their works into shambling ghouls (another year of steady work for the crew, another year of solid residuals, another year of fun with coworkers with whom you've grown fond) rather than a surgical and cohesive narrative arc.

(All of these things are true of books series as well: take, for instance, the Berlin Game nonology which started with promise and ended with Deighton left with no other choice but to raze his characters [and goodwill] to the ground.)

Slow Horses bucks — or at least bucked — this trend. Its fourth season is a triumph: it rights every slight misstep of Slow Horses (Season 3) and Slow Horses (Season 2) (both solid seasons in their own right, but not nearly as great as the gemstone first season) and delivers the best six hours of thrilling, compelling spycraft in a long time.

Some miscellaneous notes:

• One of the keys to Slow Horses' success is the legitimacy of its stakes. There's no Game of Thrones-esque flippancy with which characters are killed off less out of narrative cohesion and more out of a desire to shock the user, but nobody (besides, presumably, Gary Oldman's Jackson Lamb) is safe from death: this is something we're reminded of every season, and it gives a sense of actual danger and urgency to every shootout or chase.
• Speaking of Jackson Lamb: this season probably had the least screentime from Oldman. This can be a dangerous gambit — it paid off here, and his absence (modulo the handful of convenient deus ex machina opportunities he's afforded) is felt but not painful.
• Spy stories must thread a very tricky needle when it comes to realism. It's really hard to be entirely grounded in craftwork and realpolitik unless you're le Carré or The Americans, and it's also hard to be bombastic and exciting in the traditional language of television action sequences without feeling like you've suddenly entered a different, sillier show. (This was, I'd argue, the main flaw in Season 3: we suddenly entered a Call of Duty commercial in the back third of the season.)
• Season-long arcs dedicated to flushing out a character's backstory can, similarly, be hit or miss: shows need to earn an audience's trust that we actually care and empathize with them enough to follow them down unexpected corridors, and actors need to be able to shift from being relatively one-note to full-fledged protagonism. Jack Lowden passed with flying colors.

A little over six months ago, I wrote Notes on Zed. My conclusion at that time was that Zed made a lot of great choices and felt really good to use, but lacked parity with VS Code's feature/ecosystem to its detriment.

Six months later, I spent a few days using it as my daily driver to see what had changed:

• It's still really, really fast — and in fact, the delta between VS Code and Zed has grown even larger (either objectively or subjectively) since I last used it.
• They've made a good amount of progress on Python support, but it's still not great:
  • Pyright is so bad as to almost entirely disqualify it from being a Python editor, and extensions are still so nascent so as to be an exercise in Linux-esque experimentation rather than outright pragmatism.
  • Similarly, the LSP architecture makes it difficult to employ both Ruff and Pyright.
  • I timeboxed an hour to figure out how to get Zed's task runner to recognize my pytest suite; I was unable to do so.
• Multi-buffer editing is great though it breaks my brain a little. It seems obviously like the correct interface change, not unlike so many other little lovely decisions Zed has made.
• There are a myriad of memory leaks. I diagnosed two during my time with Zed: one, due to it trying to index a SQLite database within the repository; another, due to inline assistance.
• I miss GitLens and ErrorLens much more than I would have expected.

This list probably sounds more negative than my experience warrants. Zed's core value proposition — performance and productivity — is still enticing and tangible, despite some of my fears about them pivoting towards AI and collaboration tools. The team is iterating quickly: I'm excited both to try Zed again in a few months.

What surprised me the most about this time was how much I missed Cursor, which I've been using ever since Using Cursor to port Django tests to pytest. Common wisdom is that the AI layer for all of these tools is essentially a commodity without much differentiation, but I found myself missing the aggressive autocomplete and file-level refactoring that Cursor is (in)famous for.

So: at least for Buttondown, back to Cursor. But the Zed team is doing really good work, and the things that they're investing in feel much more durable than the things their competitors are investing in. If I were to bet, this time next year Zed will be my full-time editor of choice.

We've had Lucy for two weeks, which qualifies us as experts, which means it is time to write about parenthood. (In all seriousness, consider the below descriptive and not prescriptive: mostly, it's a notepad filled with things that were remarkable or surprising or divergent from popular consensus.)

• American pop culture puts too much emphasis on the onus of diaper changing. Diapers are easy; swaddles are slightly more difficult (we've gone with what we refer to as "the three corners method"), and the true endgame foe is the onesie. Sleeves are difficult!
• We were nervous about Telemachus not adjusting well to having a baby sister in the house; instead, he is enamored with her, and already quite protective, and mostly just annoyed at my wife and me for getting up so often in the middle of the night.
• Common wisdom says that babies sleep for eighteen hours a day, the mechanics of which are hard to really internalize until you're amidst it. There is more downtime than you expect — it's just that the downtime comes in a random, somnambulant staccato.
• There is a surprisingly deep amount of variation amongst baby bottles. (We've gone with Dr. Brown; the form factor of the bottle itself is easy to wash, and the nipples are the right size.)
• You will spend so much time going up and down stairs; you will spend so much time washing (bottles, pumps, blankets, etc.)
• We have never been more vividly aware of our luck and fortune. DMs and texts and emails, hand-knit hats and blankets, embroidered sweaters, Doordashed lobster rolls and hand-delivered pots of 冬瓜海鲜羹, words of advice and encouragement: all of these things are glittering gems; our coffers overflow.