Would like the author to describe the kind of applications/use-case they apply this too? And maybe detail what the next step is of incorporating that snippet back in the actual application?
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.
Thank you for all the valuable feedback. And thank you for the insight on how your team organizes a logbook. I'll try to expand on the process of the snippet organization itself when I have time for it (there's a newsletter on my website you may want to subscribe to).
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.
Yes and yes. Works like a charm for me when I need to learn a new area, including an unfamiliar area in a large existing codebase.
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.
Unless I misunderstood the intent, this sounds like a rephrasing of the Unix philosophy. Evidently the approach works for certain types of problems and up to a point, but we've all seen a shell script hell of one sort or another in our lifetime. I don't see this rephrasing addressing that problem. At some point you are going to need more complex things than a composition of a few simple programs, and that's where the real difficulty lies.
It is a nice comparison, but I would honestly say, that I never had Unix in mind in regards to this approach. And I would say, it again lacks the "catch" I've mentioned in the article: Unix philosophy implies composability, while here you treat your snippets as etudes, isolated etudes, which may or may not compose well, while always keeping in mind, that you are doing all that to eventually tackle a bigger problem.
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.
Readit News
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.