3 ms·
Absolutely, CS and SE are distinct fields of study. My school offered majors for both. SE is unabashedly about software and the process of developing it. It's
by jallmann 16y ago
Absolutely, CS and SE are distinct fields of study. My school offered majors for both.
SE is unabashedly about software and the process of developing it. It's about design patterns, how to manage software projects, testing and verification, etc. I just looked over my school's latest curriculum and it looks like they've added electives on embedded, real-time and distributed systems.
CS is, well, CS. The software is just a means to an end. I was a CS major, and prefer it that way.
My issue with SE degrees in general is that we don't have the decades (or centuries) of process experience that other engineering disciplines (mech, civil, EE) have. Agile? Waterfall? Pair programming? OOP? TDD? We're still figuring out best practices in software.
There is a noticeable lack of rigor in most software projects, but that is correlated with software being incredibly hard to get 'right', as opposed to a bridge or other fixed piece of critical infrastructure.
- baddox 16y ago> SE is unabashedly about software and the process of developing it. It's about design patterns, how to manage software projects, testing and verification, etc. True, but is an academic setting (especially a university) the right place for such a curriculum? What languages, platforms, testing methodologies, coding practices, etc. do they choose to teach? Do they try to teach things that will get their graduates jobs at Fortune 500 enterprises, or cater more toward the local/regional offerings? What about the start-up world, where you're almost guaranteed to be using a large number of cutting edge technologies that you probably won't have used before you got the job? The thing with CS, at least as it's taught at my university and the several others I looked into, is largely concerned with making sure the students understand theory. It doesn't matter a whole lot what programming languages or textbooks they choose to use, because the assumption is made that when you get a job, you're going to have to learn the ins and outs of that particular job no matter how much you learned about specific software engineering practices in class. This is why I wouldn't even want to study "software engineering" over "computer science," unless I knew exactly where I wanted to live and who I wanted to work for and thought the particular SE program would prepare me directly for that specific job.