I like thinking about coding with these type of metaphors. Coding, imo, is more like a puzzle. I get cooking but it's a bit too abstract for something as deterministic as most coding is. I do see it applying to the experimental side.
Relating to puzzle...
- Design: you "know" what you want your outcomes to look like
- Software: you "know" the type of pieces you're dealing with (there can be variants)
- Compile: pieces can only fit to exact tab/blank structure(per piece variant)
- Iterate: your entire design is systematic. In complex puzzles, your early decisions can greatly alter future state. How you progress and build in later states is important to.
- Can be good, eg like puzzle-solving strategies that are very specific in the beginning, but enable rapid/seamless building in the future.
- Can be bad, eg it may seem like you're mostly complete in the later states, however, there are holes and holes left ignored are a liability for the acceptable state. You might find that you've incorrectly placed pieces that seemed viable in the past, but leave you in conflicted situations in the future.
Coding is often seen as technical/deterministic as the makers are often technical, and so the mediun is typically used in a fashion that affords scaling and regularity.
There is nothing inherently deterministic about coding as a medium of expression; the fact that the basis is binary doesn't decrease the power of expression we can wield vis-a-vis analog media.
Of course there are constraints of the tooling; but whether you are inherently building something that it makes sense to compare to a puzzle is entirely up to you as a creator.
> There is nothing inherently deterministic about coding as a medium of expression
I don't disagree with this and realize I failed to recognize this perspective... even myself, generally, I internalize & embrace expression through coding.
I metaphorize coding as a puzzle mostly when debugging or designing complex software.
Relating to puzzle...