Universities have always been under fire to provide courses "better suited" for market needs and it seems to me that they've been slowly caving in during the last decade or so. This, of course, probably varies a lot between country and even between universities in the same country.
The fact is: university courses that degenerate into professional training courses end up providing little value. Timeless CS principles are abandoned for marketable high-level skills that are obsolete even before students finish their studies, and that help nothing when the market itself changes (or needs to change).
I see Europe's Bologna process as a perfect example of this. It was supposed to make higher education comparable between EU countries but instead now provides an excuse for shorter and shallower courses, comparable only because they don't go any further than the lowest common denominator.
What you say is really evident in some circles: a magical view of computing platforms and a complete ignorance of hardware details critical for software performance. There is a blind faith on compilers/interpreters to somehow extract maximum performance from the hardware in the face of wastefulness.
As anecdotal evidence, I've more than once had to convince people that allocating new objects by the millions (in the JVM) has a real CPU performance cost. The usual response is that the application isn't limited by memory and the time required by the garbage collector is negligible, thinking nothing about cache locality and how memory access is now a major bottleneck for modern CPUs.
That said, had a similar issue with logic in a simulation software where each virtual unit was its' own OO based object, with it's own threads for events... could only run about 4 simultaneous simulations on a server, and it still would bottleneck (GC was horrible). change it to a single event-loop that signaled each unit, and most of the concurrency issues went away. Streamlined the message passing (more functional approach) and memory usage dropped a lot... couldn't convince the manager to switch away from an SQL backend, which was the final bottleneck (normalized data structures), as it was then fast enough.
Had another instance where a configuration table from a database was loaded into memory (for performance), but then was kept in memory as a DataTable, with text based queries for each access for each key, that happened over a thousand times in a single web request (logins were taking too long)... Changed it to a HashTable, and lo and behold, concurrency was no longer a problem... similar issues with not understanding how static variables worked in a multithreaded application... OO ftw again (sarcasm).
Of course not. People should have the choice on how and what they want to learn. I just disagree when choice is turned into equivalence (i.e. formal education providing no value over self-learning / disguising knowledge to build bird houses as knowledge to build skyscrapers).
In some cases (some people) it may not actually matter, but in the general case, looks like it does.
But isn't that why we're supposed to have "Junior" and "Senior" level positions? I think that what software development really needs is a loosely structured guild system where you gain rank not by attrition or seniority but by reputation, where you gain/lose reputation based on who you back for seniority and how well they do. It seems that beyond CS education, it's a constant learning process. You cannot make a career only with what you learn getting a degree in CS.
It's true that a degree in CS doesn't make a career, and that it's mostly a constant learning process. After a while the difference between having a degree or not having one is difficult to measure and junior/senior levels become defined by experience. But everything else being equal, the person with the degree will have forgotten a lot that the person without the degree wasn't exposed to in the first place. Many people will be exceptions to this, but I'm just talking about the general rule here.
Once you enter an organization, you build reputation there. This is the only thing that matters. To transfer this reputation between organizations, the organizations themselves must recognize the transfer (a form of trust). When you have long and convoluted interview processes, it means there is no such trust. The organization you are trying to join is basically starting from scratch in evaluating you skills, disregarding infomation that says that even if you can't balance a binary tree now, you once did and so can do it again if required.
University degrees are supposed to provide this information. They provide knowledge but also provide a path that is known to be difficult and with a known level of "reputation" once completed. Experience alone cannot possibly provide this, because work at company A says litte to company B if the inner workings of A is an unknown quantity to B.
This is the theory at least. If universities aren't doing they work properly, this whole system collapses.
And Bologna helps a lot with your education, by making higher education comparable between EU countries, you can easily apply for student exchange programs and study subjects that aren't approached by your home university.
I studied in one of the best engineering university of Portugal and I studied for one semester in Sweden and although both universities were under the Bologna agreement, I could notice differences in both systems.
The only thing that Bologna imposes in universities is how many hours of effort is 1 course credit (ECTS). Course content, organization and etc, is up to each university.
This, by itself, isn't a bad thing.
However, the market perception is that these 3 year courses give the same level of qualification as the previous 5 year courses. It doesn't help that the name of the degree has been made the same on purpose ("licenciatura"). "They just removed useless stuff," they say.
This feeds back into students as "no need to go any further." Once they have reached the degree that the market recognizes (the "licenciatura") there isn't much incentive to continue for another 2 years to get a masters degree (btw, in the previous system a masters degree was 7 years).
Universities have to handle this somehow, and they do it by actually "removing useless stuff" from the 3 year curriculum thus reinforcing market perception and actually putting themselves on course to become training schools instead of universities.
These arguments are pretty specific to the portuguese case, and elsewhere things are bound to have been different but with the same general outcome. The general argument is this: solving the comparability problem between EU countries went too far and breached the universities' ability to resist outside influence (mainly political).
PS: The ECTS system is deeply flawed exactly because it is based on "hours of effort." Not only bacause that's a subjective measure on its own, but mainly because "effort" does not directly correlate to actual learning. A course may have very work-intensive assignments for very little knowledge.
While doing this, I was fumbling around from tutorial to tutorial, figuring out what's what (I still mis-type "backbone" and "bootstrap"). Reading through the questions that others are asking on stackoverflow, I saw a recurrent pattern. Someone would ask "How do I X?" Someone would answer "You do this, this, then that," explaining fairly-articulately the correct answer. A reply to that would be "I don't get it. Can you post a fiddle?" Sometimes inside of those, you'd see (what I think) is a mis-use of a framework. It would work, but either dragged an entire framework into the picture, or caused a tremendous amount of work to happen, when there would usually be a much simpler solution (i.e. do I -always- have to use jQuery?).
I feel like the entry level of programmer might need to change into a different title. "Software tradesman?" I'd describe these as people that know how to assemble a list of components into a working whole. They can replicate a pattern, filling in blanks where appropriate, but can't nip / tuck to change it, and certainly can't design and create a whole -new- component.
Dealing with the DOM isn't nearly has hard as it has/had been in the past, but it's still a bit more complex than jQuery's API... You can start with document.querySelector*, but then if you need an array, you need Array.from the results, then you can each/map/reduce until your heart's content... event binding is still quite a bit more verbose as well. Not to mention unbinding/cleanup when adding/removing nodes.
In the end, half the time I check "is jQuery in the project already" then I'll use it. More often than not, it is... that is except in "enterprise" projects where "enterprise" architects and the minions of developers have managed to introduce 3-4 different copies of varying old/ancient versions of jQuery and no idea which one is actually loaded. Because it's "just the front end" and have no concept/concern for actual load/performance... don't think about capturing state properly, and get weird behavioral patterns as a result.
Sorry for the rant, it just irks me that people are so dismissive of the front end or capability that the web offers because much of it is so easy to get results. On another note, if you get more into it, do yourself a favor and avoid Angular.
Taking my own learning as an example, I want to build a single-page application, so I decided that I needed a framework to manage it, since that's what all the cool kids were doing. While sipping on a frosty beverage, I was comparing Backbone and Angular, and then realized that Parse (which I'd already decided to use) built their JS API on top of backbone. That quickly simplified things for me, but I still see people that are trying to bolt together angular and parse.