The Importance Of Specific University Courses
As it's coming towards the end of the academic year I've been thinking about what courses I'll want to choose next year. It's the first year that I'll be able to decide which Computer Science classes I actually want to do, rather than what is mandatory.
My initial reaction was to pass the list of classes through a boolean predicate along the lines of "Is this class exciting to me?". This whittled the list down to around 11 classes out of about 15. I can only take 8, or 9 if I'm pushing it. Obviously I need to reduce the list more, or decrease the tolerance of my predicate.
I remember a couple years ago talking to a software developer in a pub about university classes. They suggested I go for the "hardest" classes. They defined the hardest classes as the classes that deal with more bare metal concepts. Anyone that dealt with compilers, assembly language, operating systems was on the list, as well as any and all algorithms classes. The developer I was speaking to mentioned that these classes would appear the most impressive to future employers, even if the courses themselves were not the most relevant.
Now it just so happens that many of those classes are actually what I'm most interested in, but I also have a strong interest in high-level areas such as Distributed Algorithms and Systems (a class), and Machine Learning (another). Another class that's planned for next year is a functional programming introduction using Haskell. It's being run as a MOOC, so I'm almost inclined to say it might be less time consuming than regular classes (hence an opportunity to do an extra class).
Taking all this in to consideration still leaves me with around 3 too many classes than I can feasibly do. So we'll have to see what happens in August when it comes time to decide. Hopefully the timetable will be respectful of my wishes...
Check out my other blog posts! If you found this post interesting, feel free to let me know either on Twitter (@Isaac_M_Jordan), or in the comments section below.
Enjoyed my post? Sign up to the newsletter to receive a small email when I post. No spam, I promise.
James on March 24, 2016, 8:44 p.m.
I came here from Reddit, but there are no comments on the related Reddit post. So, commenting here instead.
I've interviewed probably over a hundred graduates for software engineering posts (and many more engineers who were not recent graduates). Only in about 10% - perhaps more, but certainly less than 20% - of cases did I actually look at the subjects that the candidate studied in their course. I simply assumed, that, holding a B.Sc. in computer science, that they should have a solid grounding in the field.
The interviews (typically several for successful candidates) covered a range of skills essential to the roles I was hiring for. Candidates who had the necessary skill level (taking into account their experience), who had strong analytical skills and were enthusiastic got hired.
What I'm trying to tell you is, you should, to quite a significant extent, ignore what you _think_ a possible employer will _think_ about the subjects you are studying. Instead, study topics that you think will equip you to pursue the kind of career you want to have.
In your position, yes, I would study the topics which deal with how things are implemented. But not to impress an employer - instead to ensure that I _understand how a computer actually works_. Many times in my career I have needed to understand the behaviour of the whole stack from application software to the hardware at a reasonably low level (debugging interrupt handlers with an oscilloscope, for example). Indeed, that depth of understanding has both won me interesting jobs and enabled me to succeed in them.
However, there is also another important dimension in which to judge which things to study. You should also prioritise learning things that will _change the way you think about computer science and programming_. I'm thinking here about topics such as an introduction to complexity theory, functional programming, formal systems, human-computer interaction, machine learning, distributed systems, risk analysis and security.
Having said all this, I guess I should confess that actually, _I_ didn't study any of those topics because my degree isn't in computer science. But, in my now pretty long career in programming, I've needed to understand (HCI, machine learning, formal systems, security) or have actually practised in (complexity, functional programming, distributed systems) all of those areas. I did this my comprehensive reading and research following getting my non-CS degree. But you have an advantage over me there, you can choose to be taught many of these things, now.
Isaac Jordan on March 25, 2016, 12:24 p.m.
Hey James, thanks for the awesome reply. Definitely gave me food for thought.
Your second point strikes a cord with me. The classes that cause me to think in new ways are the ones that really excite me. My University's CS department doesn't offer many mathematically-based courses such as formal systems - but they do have machine learning and distributed systems courses that I'm really excited to do.
My point of view has actually changed over the past year or so, as I realised after my internship last summer that the CS courses I've completed are much less important than the actual experience I have. This has led me to take on many projects both in my spare time, and at hackathons.
I also managed to get the internship I really wanted for the coming summer where I'm sure I'll be working on massively distributed systems, so that's pretty awesome. Shame the classes where I learn about them are after the internship, so I'll be learning on the job!
Thanks for the reply.