What I Got Wrong About Learning to Code
Reflections on switching careers into software engineering — the mistakes, the corrections, and what actually accelerated progress.
I spent the first two months of learning to code optimising for the wrong things. Accumulating bookmarks. Comparing frameworks I couldn’t yet evaluate. Treating tutorial completion as progress.
None of it was wasted, exactly, but the return on time was poor. Here’s what I’d tell someone starting the same transition today.
Pick one language and stay with it
The specific choice matters less than the commitment. I went with Python for its readability and the strength of its ecosystem for numerical work. Others start with JavaScript or Go for different, equally valid reasons.
The mistake is switching. Every new language resets your momentum. Syntax is the least interesting part of programming — the interesting parts (abstraction, decomposition, debugging) are language-agnostic, but you only reach them by pushing through fluency in one language first.
Structured curriculum, then projects, not the reverse
The popular advice is “just build things.” This is correct but premature. Building things without a foundational mental model means you’re pattern-matching against Stack Overflow answers without understanding why they work.
What worked for me: a structured curriculum (CS50, then a solid algorithms course) to build the conceptual scaffolding, followed by small projects that exercised those concepts. The curriculum gave me vocabulary. The projects gave me fluency.
Writing accelerates understanding
The most effective study technique I found was writing about what I was learning. Not polished essays — short, explanatory notes aimed at a reader who knows less than I do. The act of explaining exposes gaps that passive study conceals.
This blog exists partly for that reason. It’s a forcing function for clarity.
The uncomfortable part
Career transitions involve a period where you’re objectively worse at your new field than your old one. That period lasts longer than you expect. The only useful response is to keep working through it systematically rather than seeking reassurance that you’re making progress.
Progress is real but nonlinear. The plateaus are where the work happens. The breakthroughs are where you notice the work has happened.