| An interesting read. Near the end I started to feel like what the author is describing is very similar to the general approach I've coalesced on, over the years. 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. |
Addressing the "fully self-sufficient program" - no, the imports are limited to minimum, at least from the owned codebase. 3rd party libraries are okay - the point is to limit the system coupling, and also to provide a fresh and unburdened look onto the functionality piece. Think github gists - you find them via google, they solve some pain point of yours, and they also serve as an "etude" for their authors.
After all, this development approach is a very psychological thing (and I would say, every approach is). It also aims to solve the issue of developer's burnout, the fear of an extremely big-scoped work, and gives possibility to ship as often as physically possible. Having a lot of snippets is way better than having something in development for weeks without any insight on what is being worked on. And when you've accumulated quite a lot of snippets, the task of gluing those together becomes a rather playful quasi-snippet in itself.
Speaking of the "framework-heavy" stuff, React included, - yes, it would definitely be harder to implement this strategy compared to, say, backend development, - you gotta have a lot of boilerplate just to make the snippet run (after all, it should be at least viewable in browser, which is already a lot.) But you still can use this way of development with a moderate success (and depending on your managerial skill or self-control): the front-end developer would have to accommodate and internalize the fact, that snippets are to be written with more boilerplate, and after all, React is component based, and components are already snippets per se.