It depends on the type of programming.

But for let's say concept-driven programming: My first work product is always a pseudo-framework (not a development framework, but an overarching project organization) which should result in primarily a schedule with periodicity and period-lengths estimated, and then some pseudocode.

The pseudo-framework almost always needs specific organizational cues, which I've learned that almost any project needs. So I quickly add those, like a personal log, a place to park and organize third-party resources, and so on. And then those branches have common branches. Like even a typical log needs specific structures attached for best use, in my experience.

I should add here that I am more than happy to modify the main pseudo-framework in specific ways I've never done before, because this is often a sign that some new leverage has been gained.

So later I'll scrutinize and re-do the framework as needed, which helps me make important changes to the pseudocode, or even code already written, without wanting to take a long vacation too early in the project.

Then there's usually a point where I've done the thing but I really have to ask myself if I want to continue with it. Maintaining it or upgrading or addressing any/all of my TODO items.

In most cases the answer to that question is no. I have learned that programming is, for me, a very low level activity in ways I didn't understand as an aspiring programmer. At its highest level in my awareness it is a symbol, like a C pointer. Better to understand the symbol and how that works.

So I found out that my subconscious mind seems to use a button labeled "let's make him interested in programming now" as a sort of mental clue to get on a schedule.

For this reason, before I write any program _especially out of personal interest_, I first write up a schedule for the next hour, day, or couple days. See if the interest is still around or if it was more purely symbolic.

This has saved me a ton of time and I'm still generally interested in programming (an early fear was that it makes the interest itself go away and then I lose the interest...which if you think about it is a funny fear to have).

Working with/for other people, this general framework interlinks with many other frameworks, for example I would create a program differently for an INTP than I would for an ENFP, because over the years I have found that there is a considerable and reliable difference in perceptions and expectations based on their preferred cognitive functions and interaction styles (this is drawing on personality type theory, not really MBTI but more JCF and APTi).

But even if I don't know their personality type, I am listening to them talk and their vocabulary or choice of phrasing just about any old sentence is helping me design the program for them. It is surprising how many people don't realize that what they are explaining to a programmer is more like their philosophy on life. And that a philosophy dictates the tools, and if you reverse that you better have a really open mind...

This also heavily influences the refinement processes. There are a lot of people who will protest against refinement in deed, if not in word. So you simply cannot refine things for them; it will make them upset. But we can also say they prefer to lend that attention to other functional approaches that are simply like other ways of looking at things.

(A pretty good way to know if you are simply a cog to them or something else is to estimate the breadth of refinement you are allowed to perform, as opposed to the depth)

Those are some examples. This all becomes more of an intuitive approach over time, so these days it's bound to hotkeys and instinctual patterns and not really a chore to set up per project as it may appear.

This helps a lot more than before, when I didn't do so much of this modeling / frameworking stuff. I wish I knew about it back when I was struggling to learn CS, because a lack of a frameworked approach makes it much more difficult to bring theory down to the code level. In fact going further, I can name 3 professors under whom--had I realized their personality dynamics relative to my own--I would have read their textbooks back-to-front and developed a more specifically calibrated approach to understanding the theory they tried to teach, in the way I learn best. Too bad; I had a really hard time understanding some of them in the event. But it's funny what you learn about your field and practice as it overlaps with others.