Underdrawing is a technique in drawing. It is a legitimate technique which is structurally similar to plagiarism via tracing. Due to its similarity to an illegitimate technique, it may be underused.
In underdrawing, one draws something badly, and then uses the attempt as a guide in creating another version, a better version.
One example is sketching in pencil on canvas, and then painting over that. There's a whole field of people who look underneath masterpieces with infrared in order to compare and contrast the sketch with the final painting.
Another example is in comics, which are often created via a team (or one person wearing several hats) of a penciller, letterer, inker and colorist. The inker draws confident ink lines over the pencil sketch.
A third example is onion skinning in cartoons (that is, animated video). There in order to create the illusion of motion, a frame is created in context, viewing the previous or next few frames translucently overlaid on the current frame.
I am interested in using craft as a metaphor for programming. A colorful and concrete metaphor is helpful for talking about programming (to managers, customers, or bridging to another tradition). Talking about programming helps to coordinate with our teammates and even our past and future selves. What was I doing on Friday (or 5 seconds ago)? Oh, I was partway through underdrawing such-and-so. We may be able to port useful techniques from craft to programming.
One thing in programming that seems relevant is using a previous change as a guide for a new change.
Whenever there is a collection of analogous things in software: components in an entity-component architecture, observers in a pub-sub architecture, stages in a pipeline architecture, then some features will be implementable by "merely" adding another thing in the "usual way". A programmer who is new to a team might be assigned a task, and pointed at a change stored in version control. "Do X looking at so-and-so's Y: it touched the same files, in similar ways, as you will need to touch for X".
Another thing in programming is the Fred Brooks slogan "Build one to throw away". Here, the emphasis is usually on the organic learning, the way that building the first implementation has changed the programmer - specifically their understanding of the problem. However, people's memories for large things are fragile.
Instead of throwing away the first one, you might instead keep it around and use it as a rough guide during your second attempt. You might disagree with some of your previous self's choices (because you now know how badly it went last time) and go in a different direction when you revisit those choices. However, even the effort of disagreeing and reacting against is sped up and improved, focused by keeping the guide in view.
Programming katas are closely related, of course.
One distinction that I'm trying to make here is that we are not doing this simply for personal, organic transformation. We are actually hoping to achieve a qualitatively better result, something like the inked comic that could not have been created by repeatedly erasering and resketching the same pencil sketch.
Let's call "underdrawing" making a sequence of commits to build a thing or add a feature per usual and then re-coding another version from the same starting point while keeping the previous sequence of commits in view. That is, literally in an adjacent window. The second time around, we can lift our gaze from solving the problem at all, to thinking more strategically. We consider each commit, and either endorse it and redo it confidently, or we split it into smaller steps, or we reject it and go in a different direction.