← BlogGENERAL — 8 Jul 2026

Why I'm Learning C Before Touching a Framework

Every framework eventually leaks its abstractions. I'd rather know what's underneath before I need it in an emergency.

CategoryGeneral
Published8 Jul 2026
Reading time4 min
cdsacareer

Every few weeks someone asks why I'm spending time on plain C and data structures instead of picking up whatever framework is currently the fastest route to a portfolio project. It's a fair question — frameworks genuinely do get you to a working demo faster. Here's the actual reasoning, not the defensive version.

The abstraction always leaks eventually

The bugs that have taught me the most this year — a stale pointer in a BST deletion, a state machine with no timeout, a ring buffer's count function underflowing — all happened underneath whatever abstraction I thought I was working at. A framework would have hidden the tree, hidden the UART state machine, hidden the ring buffer, right up until one of them broke in production. At that point the only people who can actually fix it are the ones who understand the layer the framework was built on top of. I want to be one of those people, not one of the people waiting on them.

Debugging is the actual skill

Nobody hires a junior engineer because they can import the correct library. They hire someone who can sit with a bug that doesn't make sense yet and figure out which of their assumptions is wrong. That skill barely exists at the framework layer, where most failures are configuration mistakes with a Stack Overflow answer already written. It exists constantly at the C layer, where the compiler will happily let you shoot yourself in the foot and the only feedback you get is a program that's subtly wrong. I'd rather build that muscle now, deliberately, on small projects, than build it for the first time on a production incident.

It compounds with the hardware side

I'm not learning C in the abstract — I'm using it to write the same libraries (ring buffers, protocol parsers, checksum routines) that end up running on the Arduino projects. That's the actual point: C is the language where "software" and "the physical thing on my desk" are the same project. A framework doesn't get me closer to understanding why a UART line drops bytes under vibration. Writing the parser by hand, and then watching it fail in exactly the way a dropped byte predicts, does.

This doesn't mean frameworks are wrong

This isn't an argument against frameworks in general — it's an argument for order. Learn what a hash table, a tree, and a state machine actually cost before adopting a library that gives you all three behind one friendly function call. When the day comes that the friendly function call breaks at 2am, I want the C underneath it to already feel familiar, not foreign.

This post is filed under General — for the "what actually happened and how I fixed it" version of this philosophy, see the Mistakes category.

← The Format Specifier That Hid My Own Bug From MeThe Pointer I Never Touched Was Still Undefined Behavior →

Notes from readers

Comments — via GitHub