“When I started working professionally in IT this division [the schism between 'systems' programmers and 'applications' programmers] was still quite visible.”

“When I started working professionally in IT this division [the schism between 'systems' programmers and 'applications' programmers] was still quite visible.” I think you nailed a rather fundamental trait (spectrum) in programmers that carries on, morphing along with times. From systems to business logic, or from the 'container' (pun not intended) to the 'content', and dare I generalize: from a strictly technical eye to a strictly goal/business mindset (again, this is a spectrum, everything in-between exists, all flavors contribute to make a world). The cliche would be your low-level C/Rust guy versus some frontend Flash/Js person; but this is oversimplifyling (C person might be very goal-driven with a business approach; Js person might be a performance expert). Reality speaks more of an engineer's world view so to speak: from "bottom -> up" (those that assemble elementary pieces, that need to crack the puzzle by understanding each component, like Lego) to "top -> down" (those that rather manipulate large abstract/complex entities as 'black boxes' and rather work on their structure, the graph, dimensions, and shift behavior thusly with surgical cost-effective changes). Oh just my 2cts I'm probably rambling. I just know that these two extremes on the spectrum are what we battle with for every decision we make, if we are aware enough of both sides. (Is that a blessing or a curse?.. you tell me!) I think it's why, deep down, we still (and might always) search for 'the next C' (cue Rust, Go, D, depends on use-cases I suppose), or why some people are almost principled advocates of the WebAssembly paradigm in complement or replacement of the Js ecosystem. These are the technical people of the spectrum. The high-level engineers are more about pushing for interoperability, available skill pool, maintainability. It's just that 'programming' as a skill now pertains to three dozen very different jobs so the general line is much fuzzier than in the 1950-60-70's; but I think it's a product of human intelligence, whether how we think or how we build our tools, our machines. Historical parallels, yadi yada. The mainframe situation, I think, is even more telling. Every programmer under the Sun has thought of ways to replace COBOL, and there are decent candidates. But the business side of us, of above, of reality, has mainframes still running on COBOL. Because as a 'black box', it works; the benefits of a rewrite have not yet justified their cost. I know a solid team usually requires at least 1 of each 'sides' of the spectrum, keeps everyone else honest (as engineers in a problem space).