Re:What does it take to be a good programmer?
by lliamander on Tuesday January 24, 2017 @03:03AM
(#13469611)
> 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.
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:
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)