CS50x: Online Course Review
Like any computer science course, CS50 has lectures and it has problems to solve. It’s just that CS50 does both super well.
The CS50 lectures are spearheaded by David Malan, who embodies the spirit of the course through enthusiastic delivery, passion for the subject, and emphasis on pedagogy (not just course content). Even if you have no interest in computer science, any educator will find value in Malan’s approach to the lecture (watch Week 0 on YouTube).
But lectures alone don’t develop skill and understanding, and a course lives or dies by the problems it presents. Therefore, accompanying each of Malan’s presentations comes a Problem Set that asks students to implement a computer program. These problems are creative, ambitious and inspiring. From a password cracker to spell checker, each project feels tangible and practical. Other online coding courses are good at breaking down challenges into bite-sized chunks. None task you with creating something as ambitious as CS50 does each week.
CS50 is pushing university pedagogy forward. Perhaps its boldest step was putting its lectures on the internet in the first place — opening it up to world-wide scrutiny. There’s no doubt this has contributed to CS50’s steady rise since 2012 and it’s far from done yet. While CS50 is setting new precedent in university education, there is so much more to be achieved in the field of pedagogy as a whole. So it’s also practical to look for areas where CS50 could be improved from one remote student’s perspective.
As mentioned, CS50 does lectures and problems really well. The challenge comes with bridging the gap between the two. The lectures get off to a strong start, and the prospect of watching a new Malan performance got me through the first few weeks. However, the course content steadily outgrows the 2-hour lecture format. David Malan does his best to communicate the ideas of each week, but a threshold is crossed around Week 5 where it becomes impractical to type and test code examples live on stage. As a result, lectures get more conceptual, using shapes and lines to represent the processes going on under the hood, making it harder to dive into the code later on.
This is compounded by what felt like an expectation for students to jump from the lecture and explainer videos to the primary problem set straight away. From Week 5 onwards, I found this to be unrealistic, even after watching the lectures twice, replicating everything done on screen with my own code and going through the subsequent explainer videos. There are just so many concepts squeezed into one week that it overloads anyone’s working memory, and so wrapping one’s head round a project that encompasses all of them is an impossibility.
The way around this was to build a series of basic, isolated programs that solved one simple problem to aid understanding of the bigger picture. This seems like a logical step now, but at the time felt contrary to the (perhaps involuntary) assumptions set by the course. I got the impression CS50 expected explanation to equal understanding, when I found it was only until practical implementation where true appreciation of the problem and solution occurs. Could this friction be a deliberate element of the course, forcing students to carve their own learning curve to cope with the towering task at hand? Perhaps. But this also reminded me of a quote by Paul Graham:
If you think something’s supposed to hurt, you’re less likely to notice if you’re doing it wrong.
Is there merit to making lessons actively harder to learn? If so, how do we mark the balance between a lesson well learned and a rising dropout rate?