What is rarer is the moment of effective effort's nature, for many types of coding (to agree with your point).
The author's house of cards analogy trivializes it and makes it easier to dismiss as a rhetorical device. I'd use activation energy as a more apt comparison.
IOW, if you put in 30 minutes (or 3 days) understanding code, and do not make the correct 5 minute addition / change at the end of that, all that previous time is wasted. And moreover, that knowledge has some half life in my head, after which it must be reacquired.
And that correct addition / change cannot be made without first paying that cost.
This is not unique to coding, but is generally limited to professions involving the modification of dynamic complex systems. E.g. legal, biological, mathematical.
And I'd hazard to say of those, programming has a wider universe of possible approaches (aka "Why did the last person? Oh... Oh. Oh no."). Legal is probably the closest analogy.
But the question is where do the differences lie. My hypothesis for one difference is that we dont write code like painters paint.
That is bad. We should. Hence my advocacy for literate programming.
It isn't to be dismissive of painting, it is to say we put ourselves in a more precarious position by how little we support ourselves with our tools.
Painters (, mathematicians, etc.) are all working with pencil-and-paper in quite a radically different way.
I think this goes some way to saying, actually, there is a bit of a difference here.
Doctors and nurses, who also deal with complex systems, have gotten exceedingly good at this with charting.
We? Considerably less so. But I'd hazard improving every year.
Reduction of boilerplate and flexibility-for-the-sake-of-flexibility in languages has been a big win, IMHO.
From c. 1m30s to 5m30s
In my limited experience in the creative realm (music), it takes an incredible amount of flow and concentration to get a thought or feeling out of your head and into some form of recorded medium. I can't just stop cold, wake up the next morning, listen to what I was working on and pick up where I left off. The creation is a product of a fleeting experience that can't easily be recreated.
Programming, as practiced, is distinct from painting -- but this has more to do with the practice of each. Programming tools do not afford the same ability to externalise thinking.
Fundamentally, they are built to run the code. Not to assist the programmer.
Jupyter notebooks are, here, a notable exception.
This is fairly unique. If you're painting a big oil painting, yes you need similar kinds of isolation to get it done. BUT you aren't really maintaining a deep conceptualisation of the whole thing in order to paint. Rather you can "let the canvas remember most of your thinking": ie., the painting is its own schematic, by the means of layering & outlining it.
Also, in social-creative work "flow states" arise more naturally. I think people working with people, on the whole, enter flow states. It's why managers struggle to see the issue with asocial-creative work.
The issue here is code by itself is nothing like a dress or a canvas: it doesn't encode much of our thinking. We have to rebuild an interior world when we encounter it.
It is for this reason "literate programming" is almost certainly an excellent way to program -- absent almost any tools or popular sentiment in support of it.
Code can be written more like paintings are painted, ie., "self-documenting" -- but this is very hard to do well.
Programming with jupyter notebooks, I'd guess, is more resilient to interruption -- it is more like making a dress or painting a painting. Yes, you need isolation and quiet -- but an interruption neednt be so fatal. You write in your thought process as part of the activity of making the code.