I heard the same sentiment from an architect friend. (The kind of architect who designs buildings) He said that in their business you put your best ideas on paper. Most plans then don't get built for reasons outside of your control. Projects fail, companies fold. Sometimes your designs can't pass review with the authorities because you misunderstood the regulations. Sometimes it can't pass review because the local government doesn't like your customer. Years down the road some of your plans are built. If there are problems with the design some problems might be obvious immediately, but most will only show up as the building ages. And if there are problems, are they there because you designed it wrong? Or the builders skimped on materials? Or is it maybe because the costumer meddled with your designs? You will never know. The feedback loop is both years long, and the execution is inaccurate.
On the other hand besides being an architect he was also dabbling in hobby programming projects. There if he made a syntax error the computer pointed it out to him within seconds. And even when he found a bug after compilation he could be certain it wasn't because the compiler saved money by using 10% less screws than specified or something. That is to say the feedback was both fast and accurate. If you had bugs, most probably it was because you made a mistake.
Software development is a highly people-driven environment. You can introduce something in your process (e. g. a new framework) but the feedback comes only a year later when it becomes evident that the framework hasn’t been a good fit or was introduced poorly (e. g. team members are quitting, productivity has plummeted, tech debt has piled up).
In the time it takes most professions to consider trying a new framework or tool (beyond the early adopters), entire programming languages rise to popularity and fall back into obscurity.
I also recognise the fuzzier process of designing features with stakeholders, implementing them, deploying them and having them tested in the market as something between the Rocket Launch (for the technical process from ideation to deployment and subsequent maintenance) and Stock Picking (for the product/market fit).
To finish populating the 2x2 matrix, the Novice Bowler approach is more similar to what many of the students used to do back when I was tutoring Algorithms and Data Structures at uni. They'd throw things at the IDE until it compiled, and call it a day.