In both technical and creative endeavors, it is much easier to spot the problem with a large volume of something than with a few examples.
Therefore, if you are failing at something and getting stuck trying to find on why you're failing, repeating it in slightly varied ways until you have a large enough sample may be enough to spot the problem without needing external resources. Doesn't matter that you know you're doing it wrong, keep going and let your brain marinate in the mess.
If one thing turns out good during this process, problem solved. If not, check what everything has in common and the issue should reveal itself.
The easiest pitfall is becoming blind to the issue because you've spent so long generating it unintentionally. If you still can't find it at scale, you probably need to take a break. Suddenly exposing a refreshed mind to a large volume of something flawed will make it pop right out.
The more well-known version of this idea is quantity becomes quality, a saying usually accompanied by an anecdote about a pottery class which was graded on making a high quantity of pots having better quality than a class graded on quality because the students spent more time iterating. It's a guard against perfectionism, especially in the early stages where rapid iteration teaches you more than careful scrutiny and the best possible improvement is refining your process, not the product. Not a bad strategy, but too high-level for my taste.
Marinating is a one-time technique to find a specific and holistic problem. For something procedural where you're likely screwing up on individual steps, you'll instead want to take a systemic approach to narrow down issues to a step rather than trying to extract it out of multiple final outputs. It doesn't hurt to reflect while/between making all the rubbish, and doing so will speed up the process, but the main focus is building up enough volume that the pattern stands out once you look at it all together.
This can include taking shortcuts that would never count for quantity becomes quality because you haven't put in the work to iterate on it. For example, if a short piece of writing seems bad, literally copy-pasting several times until it fills the screen and staring at it can be sufficient to find simple issues such as repetitive sentence structures.
However, if such a shortcut doesn't exist for the domain or exact copies aren't distinct enough to make the issue clear, generating enough rubbish to marinate in can be extremely inefficient, especially if you can't justify the time by working on other incremental improvements in the process.
This means marinating is ideal at intermediate skill levels, where you have enough knowledge to meaningfully iterate around the problem, rather than as a novice where any problem might be so significant that it wastes all further effort until solved.
Additionally, marinating is for finding a specific problem in specific outputs. If it's general enough that it could be found with minor diagnostics without needing to see the outputs, logically generating more outputs is unnecessary. Unfortunately, you may not be knowledgeable enough to recognize that is the case, or know of the general issue but be unable to recognize that it's applicable in this instance.
If you know you have this kind of known unknown, find some external resources with a holistic overview of common problems and come back. With some luck, that alone will be enough to show you the problem, or at least give you some quicker tests to diagnose them and you'll learn more in the process.
Even better, consult an expert. The problem may be immediately obvious to them because they've seen far more examples of it than a novice's few attempts. Marinating is essentially a hacky substitute for experience. It's never as good as the real thing.
- Rew
Nightly Notes
This all feels too abstract, but I don't know how else to explain it. Documenting rare processes was much easier to find examples for because it's a specific set of steps to follow with clear outputs.
Marinating could apply to almost any domain, and what an output is, how problems are diagnosed, and how novices build knowledge will vary wildly between them. I don't want to narrow it down because I know I've done this in many different domains myself, but I can't pull clear examples because the end result is an intuitive leap. The problem was always there, this is simply a crutch to help you spot it.
I've read other people explaining things on a similar level of abstractness by wrapping it all in a hypothetical, but I couldn't think of a good one to use either. I do think writing it out helped me understand what I'm doing when I do this, at least.
I want to come back and rewrite this someday. Not as an addendum or variation on the same idea, but from scratch. I think this is the first time I've felt that way about a post immediately after writing it.
The daily wheel goes on.
- Rew