Why you probably should, and shouldn’t, transfer out of SE to CS
If you’re a software engineering student at UWaterloo like me, chances are you’ve heard of someone doing this transfer. You might have considered transferring yourself. Or, you might have read Bo’s blog post on why he made this exact same transfer recently.
If you’re an SE student and you’re considering this transfer yourself, this post is for you. If you’re an incoming student looking at the two programs, this post may answer some of your questions. If you’re an SE or CS student looking for reasons to feel superior to the other, you’ve probably got other pretenses to question first.
Ask yourself: What about CS entices you?
This activity is going to differ for everyone. And that’s the point — people value their education differently.
CS has many advantages. We’ll cover SE advantages in the next section, but let’s focus on CS advantages for now.
You get more flexibility with course selection in CS. It’s totally up to you how well you use this. You can take more introductory courses in other fields. You can take minors and options more easily (especially math minors).
But it’s not always true that “CS people have more free time”. You still have to take a lot of the same hard hitters, such as CS 240 (data structures), CS 341 (algorithms), CS 350 (operating systems), CS 241 (baby compilers), CS 245 (logic), etc, at some point of time. Many CS students also end up taking things like CS 343 (concurrency) and CS 349 (UI) which are required, core courses in SE.
If your “preferred” CS course sequence is looking a lot like the SE program, then maybe there’s no point in transferring. But if you really wanna do that C&O or pure math option, you know what to do.
Another big CS advantage is the ability to change and/or mess with your sequence. You can even drop coop if you like. Again, more useful to some people, less useful to others. SE keeps you in a rigid sequence but that also means you’re always with your cohort.
Switching to CS also opens the opportunity for you to graduate early. Bo talked about this in his aforementioned blog post. He felt that he got mostly everything out of his education that he wanted, and that he’s okay with missing out on the social aspect of SE graduations (iron ring stag/ceremony, grad photos, yearbook, the big spring convocation) in exchange for entering the job market earlier. But graduating early isn’t everyone’s thing.
Speaking about what differs from person to person, fourth year design projects (FYDPs) are one. These are required in SE, and many incoming students see it as a benefit of the program. Many upper year students see it as a forced side project with artificial deadlines and requirements, and that a side project oriented person would be better off doing one on their own time — a totally fair argument.
I’m of the mindset that I probably wouldn’t do one on my own unless I’m forced to, and I also need some level of external direction and mentorship to do one — so I still see FYDPs as a pro. Quite many useful and amazing projects have come out of past SE classes as FYDPs, like UW Flow, InternCompass, Tailor, etc.
And, if you’re an international student, your tuition will be significantly lower in CS (for now, at least. I’m told that this will soon not be the case, as CS international tuition is expected to rise sharply to make up for the gap). Something else to consider.
What SE does well
No, this isn’t a large section just about the cohort system. But yes, the cohort system is amazing (for the most part) — you’ve got a predictable group of friends in an otherwise chaotic landscape of weird course schedules and sequences and streams and coops and exchanges. Even if you don’t try to network with people, you still get to know many of the 100-ish peers in the same field as you.
There have been instances when there has been a lot of unhealthy competition within cohorts. But largely, they seem to work really well as a support structure (especially in upper years). After all, nothing is perfect. A cohort also gives you more bargaining power — an instructor is more likely to accommodate 100 people having clashing assignment deadlines compared to just one person.
That’s all I’ll say about cohorts. Not because they aren’t awesome — but because there are other advantages to the program that are often overlooked.
Some CS courses have SE versions. Like SE212 (replaces CS245), SE350 (replaces CS350) and CS247 (replaces CS246). Sometimes SE students take ECE versions of CS courses, like ECE222 instead of CS251.
All of the examples I listed have better rated SE versions compared to the CS counterparts. This is usually due to more overlap with other SE courses (like with ECE222 and SE350), or less content due to prerequisites covering more content (like with CS247), or better instructor/student engagement and relevancy (like with SE212).
I’ve already mentioned fourth year design projects. This can be a pro or con depending on how you see it.
SE is also very well administered, in my opinion. Getting to an academic advisor is easier. This is largely because the current SE director and associate director are awesome and care about their students. This might change in the long term, but even generally speaking, a smaller, more tightly knit program is easier to administer and feedback is easier to convey/address.
Where SE as a program still needs some work
Clearly, what I conveyed above isn’t a complete picture. It’s important to talk about SE’s flaws and work towards analyzing and/or addressing them.
Let’s focus on the main one: unnecessary and irrelevant courses. Things like CHE 102 (basically grade 12 chemistry on steroids), ECE 106 (electromagnetism, aka a great review of integration), SE 380 (control systems, which has some SE applications but they’re too hard to teach, so most of the time you’re balancing pendulums on carts using math), among others.
Chemistry has no reason to stay in the program. It’s only around to satisfy accreditation requirements, and the SE director is already trying his best to convince CEAB to let us drop CHE 102. On the plus side, at least it’s a (relatively) less-intensive course.
The physics courses are around for similar reasons, but SE has ECE-level hard physics courses just “to be able to say SEs have taken the same physics as ECEs”. I think this is a bad reason, personally. But when polled, it looks like the majority of SE students would rather keep the hard physics/electrostatics courses — either because they get students to develop good study strategies for math-heavy courses in upper years, or because many see their content as interesting.
There are also the three SE 46X courses: testing (SE 465), software architecture (SE 464), and requirements/specifications (SE 463). They are seen as the core distinguishing feature of SE by faculty, but many students see them as common-sense courses with an unnecessary workload. That’s a fair perception, especially if you already know most of that content through co-op jobs or elsewhere. But given the SE program’s focus on working with larger software systems, it’s reasonable to expect courses on these topics to get everyone up to speed.
I have also found those courses to be decently up to date with industry norms, which is always a challenge with any course. That said, I can only speak about SE 465 and 464, since I’ve yet to take SE 463.
I’m not saying that the program is perfect the way it is. I echo the chorus of SE students (both current and former) when I say that many courses could either be trimmed down or removed. There’s definitely room for improvement for future classes, and the onus is on us upper year students to work towards that. I’ve been in numerous SE meetings (academic rep meetings, curriculum committee, etc) where we’ve brought up the same concerns that have made many SE students leave or contemplate leaving the program. Program admin and faculty are definitely listening and are increasingly taking the initiative to make some of these changes.
Progress doesn’t happen overnight. But we can take a step forward.
Conclusion
This is a long post. I reference a lot of specific moments, courses, and milestones. You may have glossed over all of that and jumped right to this section — and I don’t really fault you for that 😛.
Some of you are going to interpret this post as a rebuttal to Bo’s post. It’s not. I know Bo very well and I acknowledge his points of view. I think he made the right choice for himself. But just like he stresses in his post, you shouldn’t switch just because he did. The same reasons may not apply to you. Most of them don’t apply to me.
There are good and bad reasons for switching from SE to CS. Peer pressure and gut instincts are bad reasons for leaving OR staying. If you’re considering the switch, I hope this post helps in your decision-making, and that you have a fulfilling and great educational experience regardless of what you end up choosing. Good luck!
