4 ms·

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

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)

lliamander 10y ago
> programming is primarily based on planning and management, most akin to logistical management and orchestration. That's how I feel as well. Maybe it's a by-product of the software we work on? I work on IT management software and distributed control systems. When working with control systems, the "science" part typically is in the analysis and testing phases (since we have to come up with models of physical systems). For coding itself, however, it is closer to what you describe. > I often think of my data model as a physical system, and its behavior in terms of real world systems. I do this too, especially when programming in Erlang. When building software systems that are modeled as a large number of concurrent, message-passing actors/processes, it readily lends itself to this "physical systems" analogy.

lliamander 10y ago

> programming is primarily based on planning and management, most akin to logistical management and orchestration. That's how I feel as well. Maybe it's a by-product of the software we work on? I work on IT management software and distributed control systems. When working with control systems, the "science" part typically is in the analysis and testing phases (since we have to come up with models of physical systems). For coding itself, however, it is closer to what you describe. > I often think of my data model as a physical system, and its behavior in terms of real world systems. I do this too, especially when programming in Erlang. When building software systems that are modeled as a large number of concurrent, message-passing actors/processes, it readily lends itself to this "physical systems" analogy.