Last year, I decided to refresh my computer science fundamentals by enrolling in CS50, Harvard’s introductory course. My goal was to better understand the basics I had skipped earlier, the kind of foundational thinking I missed while chasing languages and tools for specific use cases. That focus made my vision a bit narrow when it came to building scalable solutions.
A secondary (and very personal) goal was to be prepared for the day my kid might come to me with questions, and that I don’t just jump to giving solutions, but actually help them think through the problem.
What did CS50 teach me beyond computer science — even in the first class?
CS50’s first lecture is fascinating. The instructor doesn’t talk about programming languages, frameworks, or syntax. Instead, he emphasizes the importance of pseudocode, in simpler terms, defining a problem clearly before writing any code.
This approach forces you to step back and look at problems from a broader perspective, ensuring that whatever you build can scale just by tweaking smaller components. It’s almost like system design, except you’re not actually learning system design yet.
To practice this mindset, the course encourages using Scratch, a visual code editor built by MIT, to express your pseudocode logic and test ideas.
What’s Scratch?
Scratch is a drag-and-drop code editor and surprisingly, it’s hard to use effectively if you don’t have a clear pseudocode plan.
Why is it hard to use without proper pseudocode?
Depending on the problem, you might end up creating repetitive or overly complex functions. But if your pseudocode is solid, you’ll design your variables, constants, and flow correctly from the start, with minimal rework.
Is it hard to master?
Absolutely. My first ten attempts were terrible in terms of scalability. I kept taking shortcuts just to “ship” something. Shipping gives that instant sense of achievement and then we often forget to revisit our designs to fix scalability issues later.
So I made it a habit: after shipping, I’d always think about my next pivot and return to the base design. Eventually, I got tired of this repetition, and that frustration pushed me to build better, more scalable designs, even within Scratch’s limited capabilities. I’m still learning to avoid this common pitfall.
Am I perfect now?
Hell no. But I’ve built a practice of comparing my pseudocode with my final design and questioning my known pivots (we all know our likely pivots, even if not precisely). More often than not, I end up making changes to improve the structure.
Does this slow me down?
Yes, for now. But it saves tons of time later when I need to make changes or pivot. It also makes collaboration much easier if I ever open-source my projects or onboard others.
Can we apply pseudocode outside computer science?
Definitely. It has improved how I approach product ideation, development, user problem definition, and other product areas. It’s even made the quality of my ENG ticket descriptions more structured and actionable.
My first Scratch project
My very first project was simple but fun: a small program that reminded me to take an umbrella before leaving the house based on the weather forecast, and to go for a walk if it was sunny. (People living in Berlin will get this 😄)
I’ll share more takeaways from my CS50 journey in upcoming posts. For now, I highly recommend my product and engineering friends give this course a try whether as a refresher or a new challenge. I hope you enjoy it as much as I did.