I believe we should move to a world where programmers aren't required a degree and software engineers have very high requirements. Programming is very simple, turning a flow chart into code is as easy as mounting an IKEA furniture once you know the basic features of the language you are using. Architecturing a software on the other hand needs a level of understanding, rigor and effort such that we should seek good CS graduates to do it.
I really like this view. But any time I have suggested something similar (I think I might draw a different separation point between programmers/engineers in the general case), I have been accused of gate keeping.
The argument against is often phrased in such a way that enforcing, or even defining, separate ‘professions’ for individuals in software careers and those professions having differing requirements, is seen as a morally negative stance on its face. As a particularized example, one of the frequent arguments would be that a hierarchical structure would inevitably emerge among people potentially working on the same application. This argument is predicated on this stratification being inherently bad.
I think the push back on separating roles like you propose would be instant and vitriolic. I got slammed hard for saying that a person who had no concern or any interest in how data structures in a given application were implemented should not be hired as a ‘system programming’ dev.
I absolutely think you are correct at the theoretical level, but practical implementation of the idea is almost a non-starter.
For some obtuse reason people think software is some ethereal magic abstraction that somehow doesn't follow any rules or practices. We have to start pushing for the fact that yes, to engineer software you need a true engineer just like to engineer a house you need a true engineer. Nobody ever laments the fact that it's clear that basic construction workers could never engineer a building following all the best practices and regulations (and most importantly, know the pertinent laws of physics in detail). And yet we give basic programmers tasks such as developing a scheduler, a traffic management system and whatnot. I want programmers to have the right responsibilities and the right expectations, I want regulated proven industry standards that we can follow and I want software to suck less
Your whole argument breaks down when it is me - a "completely unqualified", uneducated person, but also a programmer since I was 6 y/o - who has to teach people with university diplomas how to do it correctly. Happens at every job I ever had.
Overall, university diploma means absolutely nothing to me - sometimes it's a minus (because it sometimes grows a specific attitude that has no place in my teams). The only working indicator is time spent doing the job + personal interview.
The problem I see with this plan is that the state of the art in CS moves profoundly faster than the pace of careers, certifications, curriculum development, &c.
Imagine, if you will, the practices that would have been taught to the "By the book" computer engineers who graduated in 2000. Would you think it happy to have those practices dominant, by regulation, today? Would you want to have the task of lobbying the professional standards committees to update the curriculum so that a decade from now the thing you think is important would be accepted practice?
I think that the difficulty we have updating e.g. language versions or crypto practices is a good model for how well our field responds when we do things more formally. Imagine how long python 2 would be around if it had been the basis for professional credentials for decades!
It's actually quite common in other areas of engineering where you have engineers (typically with four year engineering degrees) and technicians (who typically don't). And, yes, you have very good technicians and not so good engineers--but it's not easy or particularly routine for technicians to transition to an engineering job.
That said, there is probably not such a gap between a programmer and a computer scientist--especially in terms of the skills needed for most software jobs.
Perhaps the size of the company could dictate the size and scope of work. With a small company, one person would bear responsibility for everything. Whereas within a larger corporation, the responsibility is spread amongst a cohort of people who then can focus on a subset of skills.
Doesn't this separation already exist in the form of job titles? Although not consistent from one company to another, a principal engineer's job is to architect the software, while other engineers implement the features.
Of course, many startups don't have a software architect and they allow "regular" engineers to design the system, but that wouldn't change just because the industry decides that it isn't the programmer's job to design systems.
But why do I have a feeling that it's written with an idea to make faculty life easy, not necessarily for a great student learning outcome, although that's what they say.
The undergrad CS courses mostly do not deviate in content.The variance is in quality.
"pick good professor over interesting course" paid off for me in university.
Factors such as these matter: course pace, instructor and TA accessibility, course slides and other material quality, lecture interesting or boring etc.
---
Isn't it surprising that one of the most watched courses is by an YouTube tutor with a credential no american university will ever take seriously for hiring even an adjunct teaching faculty?
What About Copying/Cheating?
* Reduce salience of project grades?
– Exams can test whether student mastered the material
Most of my CS classes didn't give exams and were graded entirely on projects.
I found this to be one of the best features of my CS education.
Projects are vastly more interesting, impactful,
and representative of meaningful learning.
Pretty much all my CS classes had something akin to a midterm worth a third of your grade and a final worth half your grade, with projects only being like 20%. I wish I went to your school.
