From Scratch to C: My First 3 Weeks Inside Harvard’s CS50

When I attended the opening lectures of CS50x (Harvard’s flagship Introduction to Computer Science course), Professor David J. Malan gave an upfront disclaimer: learning to program can feel like attempting to drink water straight from a firehose.

Three weeks in, I can wholeheartedly confirm: the sheer volume and density of information is staggering. Initially, there was a momentary pause knowing the entire curriculum is delivered in English, but the pedagogical clarity and structure made the immersion deeply engaging with just the occasional targeted search.

To avoid getting overwhelmed, I established a deliberate study cadence: splitting each lecture and problem set across 2 to 3 days, pausing the videos frequently, analyzing the underlying control flow, sketching on paper, and iteratively implementing in code. In the end, wrestling with difficult bugs and arriving at an elegant solution entirely on your own provides an incomparable sense of fulfillment.

Here is my honest logbook of that intense opening sprint—from visual logic in Scratch to low-level engineering in C, along with behind-the-scenes thoughts, hurdles, and breakthroughs.

Week 0: Computational Thinking (and Experimenting in Scratch)

Week 0 flipped a crucial mental switch: Computer Science is not about memorizing syntax rules, but about algorithmic problem-solving. It is the structured process that occurs in the space between the input (the problem statement) and the output (the verified solution).

Grasping how hardware and software operate under the hood—from binary representation to how text and images are encoded in volatile memory—provided a grounding foundation. But the concepts solidified during the practical problem set.

To cultivate algorithmic logic without the cognitive load of syntax errors, the curriculum begins with Scratch, a visual block-based environment developed at MIT. I built my first interactive project (Starting from Scratch), defining custom procedures with parameter passing, managing variable state, and nesting conditionals. While it resembles a colorful game on the surface, it forces you to think about abstraction, modularity, and control flow before typing a single line of raw text.

Week 1: The Shock of C and Embracing the Terminal

Moving from Scratch’s forgiving UI to low-level C in Week 1 was an immediate reality check. Suddenly, a single misplaced semicolon halts compilation in its tracks.

As the lectures progressed, I pushed myself to experiment beyond the code displayed on screen. There were natural friction points—such as discovering firsthand that declaring a char literal strictly requires single quotes ('a'), whereas strings use double quotes—but every compiler warning quickly translated into durable knowledge.

Two milestones stood out during this phase:

1. Leaving the GUI Behind for the CLI: Interacting directly with the command line (ls, cd, make, ./hello). While navigating without a mouse feels foreign at first, you quickly realize how much faster and more precise keyboard-driven workflows become.
2. Digital Whiteboard Modeling: When tackling the Mario pyramid generation and the Cash greedy coin-change algorithm, mental simulation hit a wall. The breakthrough was opening a digital whiteboard, drawing the coordinate axes, and plotting iteration bounds for outer and inner loops. I challenged myself to extract modular helper functions, and watching the test suites execute with optimal complexity was immensely rewarding.

Week 2: Arrays, Strings, and Building Engineering Resilience

Week 2 plunged into deeper hardware and memory concepts: how RAM organizes contiguous blocks of data (arrays), why strings in C are simply byte sequences terminated by an invisible null byte (\0), and the mathematical foundations of cryptography.

I structured my study into 25-minute Pomodoro focus blocks and experienced the classic developer emotional rollercoaster. In my study log, I wrote: “Just learned about Arrays, super intuitive and clean!”—followed 25 minutes later by: “Okay, multidimensional arrays and pointer boundaries are definitely not trivial anymore.”

The problem sets presented genuine challenges:

• In Scrabble, translating character ASCII values into localized letter scoring tables required careful boundary checking. At one point, I jotted down: “This logic is genuinely tricky tonight. Stepping away to reset and tackling it with a clear head tomorrow.” That proved to be the right call. The next morning, mapping the array indexes on the whiteboard made the implementation fall into place seamlessly.
• In Readability and Caesar, decomposing the problem into discrete pipeline stages made everything click—from character-by-character ASCII rotation with modulo arithmetic to floating-point rounding for readability index formulas.

Core Takeaways from the First 3 Weeks

If I had to distill the most valuable lessons from this initial marathon into three principles, they would be:

1. Diagram Before You Code: Trying to write code directly in the editor before clarifying the algorithmic flow leads to compounding bugs. Sketching inputs, outputs, and edge cases on paper or a whiteboard saves hours of refactoring.
2. Treat Compiler Warnings as Mentors: The compiler is not an obstacle; it is an infallible pair programmer. Seeing check50 transform from red failures to all-green assertions after rigorous iteration is one of the most rewarding feelings in tech.
3. Trust the Process and Cadence: As I noted in my journal: pause, comprehend, document, and execute. Working through problem sets from first principles and connecting concepts across lectures builds genuine, unshakeable confidence.

The foundational computer science principles I am cultivating here will directly anchor my coursework at FATEC and my ongoing full-stack projects. The career reset continues to prove itself as the best decision I’ve made.