I would say maybe we can leave the CS degree to universities for people who want to do science. Hence, the Software Engineering discipline might not be suited to universities, but rather to specialized technical schools and colleges, as it’s a more engineering-oriented profession.
In 1970, I started my BS in CS degree at a state university. The chair of the department made something clear during the first class meeting: "this is not a technical school. We're not going to teach you how to use our computer center (S/360 67 running VM + MFT guests), nor how to write a program that compiles & runs, nor how PL/1 compares to COBOL. You'll learn those things as you go, to get your assignments done.
We're going to teach you the underlying principles that allow you to understand any operating system, compiler, language, problem type & programming solution.
What you learn here & now will serve you forever. "
56 years later I'm a CIO (been one since 1982), and I still remember 'Goto statement considered harmful,' & Denning's 'locality of reference,' & why latency trumps bandwidth for conversational workloads, & some of 'Formal Languages & Their Relationship to Automata,' & why RSA works (until Quantum, anyway)...
I don't require (or even prefer) a CS degree for developers, because most coders can solve most business problems using straightforward techniques & the tools (+ JIT training) provided by employers.
But when I hear hype about a new technology, or review a glib 'technical' justification, or I'm getting briefed on an intricate problem, the principles I struggled to master 50 years ago still serve me.
Nothing to prevent that from being part of a Software Engineering curriculum, either. You'll have a harder time convincing me of the value of differential equations, NP completeness, or even algorithmics (as usually taught) 😄. I wrote a well-respected book on compiler design that focused on implementation, and some guy from Princeton gave a bad review saying that all we needed to teach was the underlying mathematics, and "the implementation is trivial." Spoken like someone who had clearly never implemented, and was probably incapable of implementing, a compiler.
As long as the curriculum covers foundational principles, I'm fine with teaching it in "Software Engineering" in addition to "Computer Science."
I had to master differential equations as part of EE coursework, but having worked as an industrial engineer for 7 years and using exactly one differential equation for work, I'm not advocating that for a CS or SE program :)
I've never written a production quality compiler, but having studied compiler design I'm better able to understand how my source code gets complied to write better code.
My point was not that all that's needed is "the underlying math" (math majors are a special breed, says this engineer). It's that teaching just coding tools & techniques without having students ponder the inner workings of compliers, operating systems, and networks limits practitioners' ability to reason about deeper issues that underlie their code.
In 1970 I could study CS or EE: my university didn't have a Software Engineering degree program. So perhaps we're completely aligned if CS has become "pure theory."
As a CIO in non-technical industries, I've seen many degreed 'developers' who are ignorant of how operating systems, compilers, networks, etc., work. And that's a shame.
I did not misread your post on Twitter. I just don't see how you can teach the general principles you're asking for without some specifics to ground them in. "how to work in teams" -- on what? "production-quality programs that people can use" -- which requires choosing specific tech for implementation language(s) and their attendant ecosystems, then further specific choices for how to deploy, et cetera. "AI-assisted software engineering" -- this is the moving-est of moving targets. Even if future evolutions of this tech make good on the least of their claims (a big "if", imo, but that's a whole 'nother topic), those models, agents, workflow, et cetera are likely to look much different than they do today.
I would say maybe we can leave the CS degree to universities for people who want to do science. Hence, the Software Engineering discipline might not be suited to universities, but rather to specialized technical schools and colleges, as it’s a more engineering-oriented profession.
In 1970, I started my BS in CS degree at a state university. The chair of the department made something clear during the first class meeting: "this is not a technical school. We're not going to teach you how to use our computer center (S/360 67 running VM + MFT guests), nor how to write a program that compiles & runs, nor how PL/1 compares to COBOL. You'll learn those things as you go, to get your assignments done.
We're going to teach you the underlying principles that allow you to understand any operating system, compiler, language, problem type & programming solution.
What you learn here & now will serve you forever. "
56 years later I'm a CIO (been one since 1982), and I still remember 'Goto statement considered harmful,' & Denning's 'locality of reference,' & why latency trumps bandwidth for conversational workloads, & some of 'Formal Languages & Their Relationship to Automata,' & why RSA works (until Quantum, anyway)...
I don't require (or even prefer) a CS degree for developers, because most coders can solve most business problems using straightforward techniques & the tools (+ JIT training) provided by employers.
But when I hear hype about a new technology, or review a glib 'technical' justification, or I'm getting briefed on an intricate problem, the principles I struggled to master 50 years ago still serve me.
Nothing to prevent that from being part of a Software Engineering curriculum, either. You'll have a harder time convincing me of the value of differential equations, NP completeness, or even algorithmics (as usually taught) 😄. I wrote a well-respected book on compiler design that focused on implementation, and some guy from Princeton gave a bad review saying that all we needed to teach was the underlying mathematics, and "the implementation is trivial." Spoken like someone who had clearly never implemented, and was probably incapable of implementing, a compiler.
As long as the curriculum covers foundational principles, I'm fine with teaching it in "Software Engineering" in addition to "Computer Science."
I had to master differential equations as part of EE coursework, but having worked as an industrial engineer for 7 years and using exactly one differential equation for work, I'm not advocating that for a CS or SE program :)
I've never written a production quality compiler, but having studied compiler design I'm better able to understand how my source code gets complied to write better code.
My point was not that all that's needed is "the underlying math" (math majors are a special breed, says this engineer). It's that teaching just coding tools & techniques without having students ponder the inner workings of compliers, operating systems, and networks limits practitioners' ability to reason about deeper issues that underlie their code.
In 1970 I could study CS or EE: my university didn't have a Software Engineering degree program. So perhaps we're completely aligned if CS has become "pure theory."
As a CIO in non-technical industries, I've seen many degreed 'developers' who are ignorant of how operating systems, compilers, networks, etc., work. And that's a shame.
I did not misread your post on Twitter. I just don't see how you can teach the general principles you're asking for without some specifics to ground them in. "how to work in teams" -- on what? "production-quality programs that people can use" -- which requires choosing specific tech for implementation language(s) and their attendant ecosystems, then further specific choices for how to deploy, et cetera. "AI-assisted software engineering" -- this is the moving-est of moving targets. Even if future evolutions of this tech make good on the least of their claims (a big "if", imo, but that's a whole 'nother topic), those models, agents, workflow, et cetera are likely to look much different than they do today.