Programming Jigs
In woodworking there's the concept of a jig, which is a sort of ad hoc stencil for woodworking projects. You might fashion a jig by screwing two wood blocks together in such a way that one protrudes a specific distance from the first, so that you can use them as backstops to hold two workpieces against each other at specific distances while you fasten them together. Or you might make a jig with precisely measured holes, and then use that to quickly drill holes in the right locations on the boards that you'll use for your workpiece.
Jigs are often used when making multiple pieces of the same design, but they are also useful when working with a project that has symmetry (e.g., a box with four sides that need identical joinery). While Googling "woodworking jig" will pull up an array of indie woodworkers trying to sell you products designed to replace custom-built jigs, there's a spirit among the woodworking community of quickly throwing together your own jig from scrap wood in your shop.
Fashioning a jig is akin to a snippet system in a text editor, a templating engine like jinja2, or a custom script to generate boilerplate code for a project. I thought about this relationship most recently because, in building a cryptographic compiler based on the MLIR compiler toolchain, I found most people who contribute are not going to want to spend the time learning the minute details required to properly set up the boilerplate for a new dialect or compiler pass. So I wrote a set of scripts that mostly sets it up for them.
I've done this sort of thing a lot in my career; configuring my snippets to generate Java AutoValues fast, setting up a hygenic vim macro or regular expression to progressively apply across dozens of files (which I then save in a README or PR/commit description for later reference), and writing ad hoc scripts to generate boilerplate code. I find it curious that most programmers I have worked with don't seem to do the same thing, whereas every woodworker I have ever talked to will quickly suggest making a jig for any project that requires repeating a task mildly precisely across more than one workpiece.
Instead what most programmers lean toward is re-engineering the entire system so as to avoid the need to write boilerplate entirely. And while, yes, this makes sense when you squint, in my experience this causes an explosion of complexity and a long time horizon to achieve the desired result. Some projects go so far as to build a new programming language, or at least propose changes to the language specification, just to make their boilerplate avoidance template metaprogramming wizardry possible. I heard at one point that the Django web framework did this to some degree to Python, since it relies heavily on advanced Python magic to work, but I can't find the reference right now.
And I don't think that boilerplate is inherently evil, at least insofar as it makes certain useful implicit or unobvious semantics explicit. For example, during my first serious attempt to write Go code, I was appalled to learn that they use capitalization to make functions and variables publicly visible from outside a module. Presumably because the authors just didn't want to type "public" or "export." In my opinion it hinders a system's coherence to have too much rely on convention merely to avoid a few keystrokes.
But more to the point, what I love about my "programming jigs" is how I can assemble them from whatever software tools I have lying around my terminal; sed, awk, jinja2, the python standard library, UltiSnippets, vim macros, etc. Even if the jig is only useful for one day or one PR, the more jigs I make, the quicker I get at identifying what sort of jig will solve my immediate task.