I could argue that software developers probably leave some amount of untapped potential on the floor by not at least sometimes attempting to "forget technique," and instead dive into deep flow and get really ambitious about high level results, without engaging in explicit "technique," at each step.

Think about trying to spin up a purely mental model of an entire distributed system in your head, and then attempting to make deep, cross-functional inferences as a result of seeing the forest, and then solidifying those inferences into concrete, but super ambitious goals, instead of "incremental" goals, as everyone seems so fond of talking about nowadays. "Incremental" progress doesn't often produce paradigm shifts in the overall "game", and it's not the only way to approach problem solving.

I think this is mostly due to cost and risk, but I worry that this is an engineering "muscle" to be trained that we allow to wither away through lack of use.

Also, for the purposes of the article, you can even just discard the music analogy and focus on the four parts: you need some theory, you need time to work on your own projects, you need time to work on production code, you need to actually ship. We need a better balance of those things.

But I do think the analogy works well--it's like PG's analogy of hackers and painters.