Impossible, entry level for CS and programming is drastically falling down every year, languages that don't require any CS knowledge or thinking become more and more popular. During my undergraduate studies no one told me that something like CPU cache or branch prediction exists, we were just told C#, Java, JS and PHP are used in the industry so learn it and you will have "a job". Some students did their MP in PHP, JS where you could login as red status bar (HTML injection in login). We were not told about vagrant or static code analysis. I had to learn in myself from reddit and contributions to OSS. People who call them self senior JS developers don't know how to solve basic algorithmic problems.
Maybe this is the source of the recurrent discussions here, and elsewhere, about how formal CS education doesn't matter (something I wholeheartedly disagree).
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.
I don't know that I agree... people can learn in many different ways, and don't always need to deal with different aspects. If all I want to do is build bird houses, do I need to learn everything a structural engineer has to learn to build sky scrapers?
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).
"If all I want to do is build bird houses, do I need to learn everything a structural engineer has to learn to build sky scrapers?"
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.
I will say that it depends on the person... I've taken from learning how to do simple scripts in the 80's/90's and actually done reading on lower-level CS, and although I don't write C/C++ day to day, I do understand the concepts. And while I don't have to think about such things.. understanding memory constraints and how caching and process swaps work in the CPU has come in useful even for higher level language projects.
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.
That's difficult to achive without the reputation system being overrun by politics sooner rather than later, I guess.
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.
I don't agree with your perspective of Europe's Bologna. Universities don't need an European agreement to create shorter and shallower courses, in fact, Bologna doesn't impose any kind of restrictions on the kind of courses the universities have.
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.
Before the Bologna process, engineering and CS degrees in Portugal used to be 5 year courses, minimum. After the Bologna process, curricula were modified so that courses could have a 3 year minimum.
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.
Your comment and the parent comment aren't incompatible. Increasing the size of the software industry will naturally result in much greater specialization, with high-skill folks solving the hardest problems and farming out the easier stuff to low-skill people. Likewise, in the early days everyone needed to know how to fix most things in their car, and car mechanics had to be real experts. Now most car driver can't change their oil, car mechanics are following instructions given to them by the car's computer without much idea of how those decisions get made, but inside car companies there are guys with deep insight about how to electronically balance your engine.
I agree. I picked up JavaScript recently (I'm an embedded systems and firmware guy, so gimme a break!), and decided to play around with designing a basic game. Using parts off of the shelf (bootstrap, parse, and google's APIs) I could build a very pretty, responsive thing that worked well on a variety of devices.
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.
Small aside, getting rid of jQuery is kind of hard... I'm half surprised that no browser has taken the core of jQuery and simply integrated its' usage patterns in the browser at this point (considering everything else added to the DOM).
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.
I guess the 3-4 copies of jQuery are my point; that's generally indicative of a misunderstanding of how things work.
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.
I see so many "oh just do it with jquery" comments on forums.. when in reality, 9 times out of 10, you just need some simple one-off function from it.. you end up loading some massive script to run 2 functions... oh wait, is that why compilers exist? :-) really what we need is a way to get jquery to extract out just the functions you want in a standalone way...
Please let us know which university that was, so others can avoid it. I'm glad you managed to teach yourself these important concepts despite that. I fear that others won't have been as go-ahead as you, and are instead writing the sort of crappy Javascript that brings my browser to its knees on certain websites, or makes my 6 core 64 bit phone run really slowly.
I took CS classes back in the early 90s and again just recently. Back in the 90s, I remember learning about CPU registers; text, stack, and heap memory; pointers; algorithms; etc. The classes I've taken recently were focused on language syntax; REPLs; IDEs; and frameworks. It seems there has definitely been a shift towards the simple during the last 25 years.
