[skywhopper]

"When I write my HTTP Applications I don't need to understand all the Network Layers beneath it."

If you want your HTTP application to perform well, be secure, be scalable, work with a multitude of browsers in unusual conditions, and be able to troubleshoot weird errors, then yes, you will at some point need to know something about TLS and TCP and IP (v4 and v6) and even Ethernet and Wifi.

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.

[hateCS]

Did you ever consider that a lot of the work being done by developers today makes them more like plumbers and electricians than architects and engineers?

[vonmoltke]

> 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/

[dhoulb]

This! This is the first comment I've read in this thread that's dealt with the core issue.

We, the world, don't need millions of people who can write a good sorting algorithm. A few thousand will do. We need millions of people who can use the sorting algorithm that those thousand people wrote, to build things higher up the stack, and billions of people who can use the things those millions of people wrote to do their work.

As you go deeper in the stack, fewer people ever need to understand it, and they will be paid more and more. We don't need more computer scientists and sorting algorithms. One good solid sorting algorithm is fine. The whole idea of evolution is we build on the successful developments of previous generations. We don't need to know how a lightbulb works, we just use it to illuminate the desk while we write a paper on genetics.

I don't think we should train kids to be computer scientists — the really talented ones will do it anyway, and the number of people entering this field will continue to grow for the foreseeable future — I think we should train them to be lawyers and doctors who understand code. To a level where can throw together a solid working solution to a problem they have, without having to go to a programmer who may not have the deep subject knowledge that allows a novel solution. If the doctor can code, they can iterate on their idea in a way that just isn't possible if someone else is developing it for them.

Excel and macros etc are the beginnings of this, but it'll go further — at some point JavaScript or Python will hopefully be prevalent.

[erichocean]

Excel and macros etc are the beginnings of this

One of the startups I'm CTOing is working on exactly that problem, or rather, has worked on it and is commercializing the solution.

Logo[0] (the language for children) is actually more complex and abstract than what we've got, which isn't a language at all, but closer to a spreadsheet for code, except...people don't even know they are coding, much less using what everyone here would call a debugger. They're just doing stuff that, if you were a computer scientist, you would recognize as coding.

I'm pretty excited about it, we're beta testing with an 800 person company in Australia at the moment, and hope to go into a general release over the summer. I think it's similar in significance to the business world as the spreadsheet, which allowed non-programmers to do number crunching. Our stuff allows non-programmers to do the vast majority of business automation and back office coding being done today.

[0] http://en.wikipedia.org/wiki/Logo_(programming_language)