there are programmers with little analytical skills but given enough time they will end up with code doing mostly the right things... unfortunately from the out side there is no way to tell to what degree the code evolved from try and error or from true analysis...
Then there are skillful and analytical programmers who over the course of the dev cycle for a problem burn out their "analytical mana" due to simple exhaustion, external pressure or both or simply because the problem grows conceptually over their 'head-room' during the work on it... backtracking and reworking already written down code is still cumbersome, always a risk and unpleasant ('trashing something already done')
Then there often is time eroding the most clean, analytical code with every little update into a mass, unless ofc energy is spent to re-analyse and rewrite.
Then there are ofc some differences between areas in which programming is used.
'how much coding is by guess and by golly'
I hear this quite often from ppl with math, physics background etc. who are often accustomed to read expositions of ideas in math papers: presenting the final versions of the formulas.
Code quite often is more equivalent to the notes a mathematician would make and use before summarizing them into the published paper.
Those Math-Whitepapers are executed in the heads of the humans so they tend to try to keep it clean and minimal and analytical sound.
Those Code-Artefacts are executed by machines which don't care at all about such things, thus as long as the humans are satisfied with the end-results the 'inner-structure' tends to erode. Code is read more often than written but it is often only read later and by other people, so ... first things first: it has to work, right? ;)
But yea, I mostly agree that many programmers slide down into a habit of very special kind of
"reactive programming" ;)
where they try to hit the target by incrementally zeroing down on a solution reacting only on the results of the previous version of the code. Due to the action - reaction structure this tends to be quite flow-inducing and satisfactory... but the results are seldom analytically pleasing or sound.
Writing code is mostly a creative process. When you used standardized tools, the creative process eventually starts to look common, but when you learn how to use the general tool set which might be analogous to a carpenter's tool belt, then you end up with a more custom tailored product which is very specialized for a specific task. Since there are too many ways to solve any specific problem when the tools you are using are equivalent to screws, nuts, hammers, screwdrivers, anything can be fabricated to make the process work.
The real key here is that when creative-problem-solving meets design-pattern-nirvana, then you can start refactoring into the standard patterns that everyone is accustomed to seeing, and then things start to make more sense.
It's like the PubSub pattern is beaten to death in so many different workflows, but ultimately it's the same shit. Event-based programming is PubSub. Clicking causes a publish/emit, and every entity subscribes to these events/emits on a particular address of a specific pattern.
When we are all starting to speak the same language, I think writing code will become more a practice in writing in our general idioms. Lot of programmers are not formally trained, and nobody does apprenticeships before they write code, they just start.