Snippet-Driven Development
drakerossman.com
drakerossman.com
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.
I'm not sure how to do this with a SpringBoot/NodeJs app that you would find in 90% of shops
Start with tiny snippets. Spend a lot of time in a REPL, or write tiny tests, learning basic facts, proving intuitions, and connecting the dots. Write a lot of comments describing the findings, linking to the docs, etc. Ignore the urge to structure things beyond small, easily observable functions: not enough is known yet.
Eventually I convert a worksheet full of tiny snippets into a worksheet with a number of more interesting functions added, then with functions connected so that parts of the actual problem get solved. I can track the solution at every step back to the tiny snippets and comments.
Then I turn the worksheet into something like real code, using most of these functions, just structured properly, with tests split out, etc.
1. Get a feature request.
2. Create a standalone program that does just that thing (pulling in, presumably, whatever is needed from the primary application(s), otherwise you're reinventing the wheel a lot).
3. Do V&V on this, use it, but leave the code alone.
4. Some time later, merge it with the primary application(s)
(4) would usually require a refactoring/cleaning up to ensure a clean separation between UI and logic layers in the "snippet". Once done, the logic portion should be incorporable into other applications more easily because it's been converted into a library.
I usually don't delay between (3) and (4), but take basically the same approach. Convert the primary application into a suite of libraries and the glue code between them and UI code (this is an ongoing process if it's a legacy application, this is what I try to do early on otherwise). Those libraries can be reused for a "snippet"/spike/whatever you want to call it to avoid reinventing the wheel. The new program is brought up, used enough to be confident in it (combination of testing and real-world use), then its logic is properly modularized (if it wasn't already) and reincorporated into the primary application.
Repeat with the next thing. If all the necessary components are present, but not the glue/UI for it, then you can skip that process (or most of it) and just work on the main application.