> Similarly, architects and engineers have to understand how the materials they're planning to use are made, what their capabilities and limits are, and how they can best be used to implement their vision for a building or a bridge. They can ignore how the bricks are made and how they perform, but their structure will not last.

Np, they don't. At least not to the degree that some people here think programmers and software engineers should know computer science topics and various levels of abstraction. As an electrical engineer, if I had a custom transformer I needed the spec sheet and evidence that the parts met said spec sheet. The spec sheet had basic electrical and physical parameters along with relevant composition information. I didn't care what exactly the core was made of unless it was specified; I certainly didn't care how the core was cast and milled, how the coils were wound, how the casing was added[1], or what the casing was made of[2]. I didn't care about the details of how out custom or off-the-shelf ASICs were made, only that they met the stated specs. I needed to know how they functioned in the circuit, how they interacted with each other, how the spec tolerance on different parts affected the overall operation. If I had a problem that looked like a lower-level issue, say an ASIC that may have switched manufacturing processes without the manufacturer telling us, I worked the issue at our system level and let an ASIC specialist handle the nitty-gritty details as necessary; the ASIC specialist similarly relied on me to handle the board-level issues.

I was going to give a civil engineering example with concrete, but I'll cut right to the chase. Computer science, misnomer that it is, is a very broad subject area. As it matures, it continues to get broader. At some point, we as an industry, and to some degree the academic community, need to realize that the subject area is too broad for everyone to know everything and that people need to specialize. If I want to build a radar system I need as a minimum: an RF engineer who understands the gory details of RF transmission and RF semiconductors; a power engineer who understands the gory details of DC power conversion and distribution; an electronics engineer who understands the gory details of mixed-signal board design; another electronics engineer who understands the gory details of high-speed digital board design; a firmware engineer who understands the gory details of FPGA and CPLD design; and an ASIC engineer who understands the gory details of analog and mixed-signal chip design.

Everyone I just mentioned will have one or more degrees that say "electrical engineering", and many may only have a bachelors. Each engineer certainly understands the basics of what the others are doing, but each is still a specialized engineer. They are NOT interchangeable. You cannot hire people for their generic "electrical engineering chops" the way Google and its cargo culters hire software engineers, even straight out degree programs. Every electrical engineer cannot know everything equally well, and once you start working and specializing through experience it just gets worse. The sooner this industry realizes that software engineering is not different and that complex software projects need specialist teams coordinated with proper systems engineering[3], the better. I firmly believe that most of the "talent shortage" right now is an artifact of companies looking for people like you describe, people who know everything and can move freely up and down the stack. That is increasingly impractical and not nearly as efficient as getting people to specialize and work together effectively in multidisciplinary teams.

[1] These were fully-encased transformers.

[2] Again, unless we specified something specific.

[3] http://www.incose.org/