I've always deleted the snippet(s) in question after implementing the full behavior, however - or, more accurately, absorbed them into the final implementation piece-by-piece.
More recently, my team at work has started committing a logbook into our project repo for similar reasons of recording technical musings for posterity. Also similar to what the author describes, only in our case we are effectively _starting_ from the readme files and introducing code snippets where we feel the need. We're also maintaining the log as a single file - the plan is to archive 3- or 6-month chunks at a time as separate files once they reach a certain age.
This logbook experience makes me very curious as to how the author manages their snippets in practice. I wish they had gone into more detail than
> if you're able to keep on top of things [...] it mandates discipline
The baked-in chronological component of the logbook makes it straightforward to look topcis up by roughly _when_ they were deliberated on, but it's not great at guaranteeing a valid code snippet exists that encapsulates any given deliberation. Conversely, snippets that
> should not even be conceptually aware of another snippet's existence
and be treated
> as a fully self-sufficient standalone program
seem to force me to incur a substantial obscuring of how any given musing or deliberation builds on what came before. At the least, many snippets will start with 10-20 boilerplate setup lines and class definitions.
Perhaps I am just wishing the author had explicitly mentioned if they import existing modules, functions, classes, etc as needed to keep the snippets short. If that is indeed an implicit assumption, then overall I don't have much to critique. If not, I am very curious as to what snippet-driven development for "framework-heavy" frontend code (eg React apps) looks like.