|
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. |