Haha, Just the Old Stuff.

1 minute read

Date:

Intro Algorithms (433)

Table of Contents

Beginning

At first, learning algorithms felt a lot like going through IP (Intro to Programming) and DS (Data Structures) all over again: sorting, searching, recursion, dynamic programming. Familiar ground.

But what made this course different—and fun—was how everything had to be proven asymptotically. You couldn’t just wave your hands and say “merge sort is $O(n \log n)$.” You had to show it, step by step. And not just for standard algorithms, but also for variations, tweaks, or new problems where you had to design something from scratch. At first, it felt almost dystopian: a computer science class where you don’t touch code. But over time, I started to appreciate the freedom. No debugging sessions at 2 a.m.—just describing an algorithm on paper, proving that it works, and proving how fast it runs. It turned CS into a kind of math puzzle.

The Proof Game

Most problems came in three acts:

  1. Design — Describe the algorithm in plain steps (pseudocode optional).
  2. Correctness — Prove, usually by induction or an invariant, that it actually solves the problem.
  3. Efficiency — Prove, usually with a recurrence or summation, that its running time is what you claim.

For example, divide-and-conquer proofs almost always boiled down to: \(T\!\left(\frac{n}{b}\right) + f(n)\)

Which, by the Master Theorem, unfolds into clean asymptotics. The fact that you could analyze so many algorithms with one formula felt almost magical.

A Refreshing Challenge

In the end, this class was less about learning “new tricks” and more about building mathematical maturity in CS. It was like weightlifting for the brain: repetitive, yes, but each proof stretched a different muscle.

And I did well in it. Honestly, I was proud of myself—not just for remembering the old stuff, but for seeing it from a new, more rigorous angle.