I was in a meeting just this morning regarding how we measure the performance of something which ended up with reading a paper on queue theory to help with the design. CS and SE are very related. Also, Civil Engineers do learn physics as part of their course.
> Also, Civil Engineers do learn physics as part of their course.
The analogy is apt for exactly that reason. Some knowledge in physics is fundamentally required, but for the civil engineer it's only professionally relevant to the extent that they can apply it to solve practical problems. A solid understanding of physics (and indeed how to come out wiser after reading a paper relevant to your field) is just one part of their expected skill set.
What would you learn in a BSc Software Engineering that's not in a BSc Computer Science course that's not going to become redundant after a couple years and couldn't be covered in a module? I have thought about this before and argued for Software Engineering to be a specific course/field, but it's just too ephemeral at the moment with a lack of 'core' elements to warrant a 3 year course.
Edit: To be clear, I want the field to mature and develop into something similar to other engineering fields like EE, but it's not there yet.
> What would you learn in a BSc Software Engineering that's not in a BSc Computer Science course that's not going to become redundant after a couple years and couldn't be covered in a module?
Requirements management, information security, software architecture, all the big picture topics that are applied and not theoretical in nature.
I took a module in my MSc in CS on these topics and they were boring, out of date, and things you learn as you need on the job anyway (I took a part-time MSc while working). They were also covered in just two modules.
Sure, some courses could be up-to date but ultimately they'll be out of date in a couple years. Core concepts like OO are a bit more stable but you can be taught this in an applied sense or a theoretical sense and both are covered in a good CS course anyway.
> What would you learn in a BSc Software Engineering that's not in a BSc Computer Science course that's not going to become redundant after a couple years
Industrial economy, ethics, engineering professionalism, development methodology seem rather universal. Then, depending on specialization you could pick up anything from signal theory to control engineering to human anatomy.
> and couldn't be covered in a module?
That's a pair of very, very narrowly placed goalposts. Of course you could cover anything in a module and call it computer science, but where would you go then if you have a legitimate interest in computer science and not a bunch of courses that really have nothing to do with it?
Some software engineering studies, even sometimes called information technology (Australia, Netherlands, Germany) are theoretically equivalent to most of the general CS studies you find in the United States. It all depends on the curriculum at the end of the day.
I'd like to see them have to go into a million-line code base, find the right place, and add some new functionality. They'd learn a lot about the importance of good organization, naming conventions, and leaving pointers for the people who come after you - things they never would have learned in a lecture, or by working on 1000-line programs.
I agree. I think there is a definite need for real 'Software Engineering' discipline that focuses on things like project estimations, timelines, codebase management, best practices, etc.
Absolutely! Some companies are great at this but most (from my experience) use the term but there's 0 'engineering' involved - it's just hacking bits of code together and hoping it lives long enough for a customer to sign off on UAT. There was a good talk on this subject last week - here's the recording if you're interested https://youtu.be/3018ABlET1Y
This is an incredibly flawed analogy. I can say safely that software engineering students (SE specifically, and not CS) have at a general level a massive amount of missing knowledge compared to their CS counterparts. Practically every SE concept either is or can be taught on the job. I don't hire but I can safely say that if I ever did I would hire CS graduates long before someone who calls everything they use an 'app' and couldn't explain tail recursion to me. I will never understand how SE people can brush past basic concepts in favor of specific frameworks that might be out of favor by the time they graduate.
SE students tend to miss fundamental parts of creating good applications while they study how to do so (security, privacy, performance (!), etc). This gap creates a liability in the job markets they saturate, as well. This culture of companies that hire SE majors and SE degree programs is pretty lax when it comes to the stuff that isn't arbitrary software framework knowledge. Frankly, the 'optimization' of CS has been a disaster. Buggy software can cause just as many damaging or long term effects as poorly designed buildings or machines, but in none of the programs that would output people capable of creating those do we see a movement supporting 'practical' knowledge over the basics. It's incredibly short-sighted, and at the very least, it means smaller CS programs.
It all depends on the university and the curriculum. Some universities here provide only "software engineering" or "information technology" programs that are equivalent to their computer science counter part in countries like the US. Sure, you can learn topics like requirements engineering on the job (often an underrated subject if you really want to do it well), but the same thing can be said for literally any of the CS courses..
At the end of the day, the curriculum is really what matters for a person. Actually, you can even argue that "computer science" is not even a real science (similar with many other studies that have "science" in their name). Heck, I'd say software engineering is closer to actual "engineering" than computer science is to actual "science".
Exactly. So the implied premise of this article (that we should see loads of CS majors because people want to work in software) is faulty. They can just as easily study physics, chemistry, math, logic, etc.
At my software company I think we have more physics graduates than software engineer or comp sci.
We use mostly Python and Go btw, which I think might affect things a bit. Graduate schemes for those computing degrees tend to be at big corporate dot net shops.
I'm not sure what you're saying here, that you don't need formal education to do software engineering?
I mean on the one side I agree with you because there's so much you can learn online right now, but the same is true for other branches of engineering and STEM as a whole.
Less that you don't need education and more that the education of a CS degree has little relation to the practice of software development. It's probably improved, but when I was in college 20 years ago CS was something you did abstractly on a whiteboard, it's computer SCIENCE. That's certainly valuable to society as a whole and certain fields, but it has little bearing on building websites or business CRUD or other things the vast majority of us are doing. I don't need a new hire to be able to implement a sort algorithm from first principles, I need them to know git and how to write unit tests and how to communicate with a team effectively.
> but the same is true for other branches of engineering and STEM as a whole.
Is it though, my understanding is that for a lot of engineering programs and science courses, much of the value comes from labs and hands on experience with equipment that a consumer cant get access to.
Using your analogy, probably because there aren’t many well established civil engineering degree programs.
I don’t know what “practitioner program” could get you close to a guaranteed spot at a top software firm. I’ve been out of school for a few years and figure this stuff has been changing fast though, so that perception may be out of date.
Never even heard of a software engineering degree. Only computer engineering or computer science, either of which may include some software engineering courses.
I did a BSc(Comp Sci) in Australia (USyd) starting in 2010. A lot of my friends were doing the Software Engineering degree. We did the same courses and went to the same lectures, the only real differences were a) what faculty we were officially part of, and b) the words on the piece of paper we got at the end.
(I'm stretching the truth a little here because I also did a Maths major in addition to Comp Sci, but that was not part of my Comp Sci requirements so I think it's still valid to the point I'm trying to make, that the two degrees are functionally identical with different names)
There are certainly various more nuts-and-bolts certification programs out there, but if you want to do software stuff and you're going to an "elite" school you'll tend to major in some variant of CS--whether it's located in the math/sciences or the engineering school.
What computer science means varies from school to school. At many University I only wrote proofs for 2 of my CS classes. The rest of my classes were spent writing code.
It's like getting a physics degree to become a civil engineer.