This is really interesting to me, how different people view programming at a conceptual level.

My current view (it changes every couple of years) is that as a skillset, programming is primarily based on planning and management, most akin to logistical management and orchestration. (we're just lucky our workers are CPUs and resources are memory/bandwidth vs workers you have to individually train, and physical resources that are permanently consumed)

The focus of a programmer's work, and the skills required include:

    - domain knowledge and understanding of the work being done  
    - developing use cases and modelling a solution, often built from well defined and understood 'components' and relationships between them (eg. factory/production, shipping/freight, warehouse/storage, storefront)
    - defining processes and procedures to deal with the various states throughout the project's lifecycle  
    - logic and control flow through these processes including synchronization and validation  
  

The more I've looked at examples in areas outside CompSci, the more parallels I've drawn to general project planning and management skills, vs those more artistic or scientific.

In case it's unclear, I _am_ talking about writing code, and not software development in general.

I often think of my data model as a physical system, and its behavior in terms of real world systems. As a simple example, I visualize the function processing a FIFO queue as someone working a specific station in an assembly line factory: their job is to take incoming pieces of a known, expected type and do _something_.

I find this helps me "zoom in and out" mentally, grouping things in context with some understanding of what's going on internally, while still treating it as a "black box". (eg. you can still picture what's going on inside a "factory" when you're looking at it as a whole, with several inputs and the produced output)