I've been programming for 11 years, and professionally for 10 years. In this time, I think I've become highly skilled at

- Distributed backends - Tuning databases - Next.js + react based complex web-apps - react-native based android apps - socket programming - multiplayer software - canvas based software - And currently learning database engineering

After exploring so many fields, either I have lost a unified mental model for programming, or the mental model has become so large that it resides out of my active memory and guides my intuition.

I explored most of these fields being a contractor, and then am entrepreneur. As a result, I didn't have enough validation on my code, and only had achieving the business results as my guiding principle.

I work at a mfaang now, so get enough validation on my output from peers to know that the solutions I come up with are technically sound.

There's still one field that I very much wanted to add to my skillset but couldn't for some or the other reason - k8s based ci/cd at scale on a cloud platform.

I wish mine was this one:

  abstraction arrives by god knows what glorious mechanism.

  after a few iterations for bad typing, I arrive at a fantastic solution.

My method is more like this:

  I try the 3 brute force hammers I know for most problems, typically in a UNIX pipe sequence of pre existing commands, written in different languages so sed, and awk, and cut, and python and a few specific C binaries might be there.

  I then re-write this about 10 times, before recognising I did it between 3 and 10 years ago, better.

My personal experience is that watching better programmers suggests behind the scenes they do a lot of iteration before surfacing with that beautiful abstraction but a very small number have intuition closer to it, and arrive at solutions with strongly typed, DLS like models of the world which seem to work very well.

They think differently.

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.