In my first year at the specialized high school, a small group of us — four friends strong in math, English, science, and IT — shipped four different projects across four different tech stacks. No single one of them taught me as much as doing all four back to back did.
The First Time You Learn the Shape of a Project
By the fourth project, I could feel the shape of the whole thing before writing a line: how to plan it, where it usually gets messy in the middle, how to structure the handoff to publishing, and how the process ends. That shape doesn't come from reading about software lifecycles — it comes from living through the same lifecycle four times in a row, with different stacks each time so the shape, not the syntax, is what sticks.
Variety Forces Real Understanding
Switching tech stacks between projects meant I couldn't coast on memorized patterns. Each new stack forced me to re-derive first principles — what a good architecture actually looks like, independent of any one framework's conventions. That's a slower way to learn a single tool, but a much faster way to become someone who can pick up any tool.
The Habit That Formed
I never let a team stay stuck on a problem — mine or theirs. If something jammed, I'd find the way through and make sure the team understood it too, not just watch me fix it. By the end of that year, "unblock and teach" had become as automatic as writing a function. That habit, more than any of the four projects themselves, is what I still lean on today.