Why Regulators Should Care About C Programming Skills

Dr. Jonas Birch spent nearly three hours building a file compressor from scratch in C, narrating every pointer allocation and sorting function to an audience that likely numbers in the hundreds. The video has racked up modest views since posting. No one will call it viral. But buried in those 167 minutes of code is something regulators consistently fail to grasp: what software actually does.

I've spent years translating tech policy for people who need to understand it—from Senate staffers drafting bills to readers trying to figure out what Congress just voted on. The persistent problem isn't that lawmakers lack good intentions. It's that they're legislating systems they fundamentally don't understand at the implementation level. Watching Birch work through the mechanics of data compression makes that gap uncomfortably visible.

The Abstraction Problem

Birch's compressor divides files into 32-bit integers, builds a list of unique entries, then swaps each 32-bit block for a 16-bit index. "We'll go through the entire file four bytes at a time and process every four byte block as an integer," he explains, walking through the logic of counting occurrences and removing duplicates. It's methodical work—the kind that requires understanding memory allocation, file I/O, and data structures at a granular level.

This matters for policy because compression isn't just a technical curiosity. It's how encrypted messaging apps reduce data transmission. It's how cloud storage providers minimize their infrastructure costs while handling your files. It's embedded in every privacy-preserving technology we depend on, and most proposals to regulate those technologies come from people who couldn't explain what a 32-bit block is or why it matters that you're swapping it for a 16-bit index.

The EU's proposed Chat Control legislation, which would mandate client-side scanning of encrypted messages, demonstrates this technical illiteracy at scale. Lawmakers want to preserve encryption while also scanning message content—a logical impossibility that reveals they don't understand what encryption actually does at the implementation layer. You can't have it both ways, but the bills keep getting drafted as if you can.

What Gets Lost in Translation

When Birch builds his search function, he's specific about data structures: "We're going to have an AMT list which is a list. This is the haystack and the int32 is a needle that we want to find." He allocates memory, handles errors, sets upper bounds on file sizes. These aren't abstractions. They're the actual constraints that determine what's technically possible.

Regulators operate several layers removed from these constraints. They know they want "safer" platforms or "more private" data handling or "accountable" algorithms. They rarely know whether the technical architecture can support what they're mandating. The result is legislation that either can't be implemented as written or creates perverse incentives when companies try to comply.

Consider the current push for algorithmic transparency requirements. Multiple proposed bills would mandate that platforms explain how their recommendation systems work. Reasonable goal. But when you're dealing with neural networks processing millions of parameters, there's no straightforward "explanation" that both satisfies the technical reality and makes sense to a non-technical audience. The gap between what lawmakers want (clear, understandable disclosures) and what's technically feasible (mathematical descriptions of weighted functions) doesn't get resolved by writing it into a bill.

Birch's compression work illustrates this friction. When he processes the /bin/ls program and discovers "all zeros—we have 16,000 of these," he's observing actual data patterns. Real software contains massive amounts of repetition, null bytes, predictable structures. Any regulation touching how that software gets stored, transmitted, or analyzed needs to account for these technical realities, not just the policy objective.

The Lobbying Advantage

Here's where the technical knowledge gap becomes a democratic problem. When tech companies lobby against regulation, they can marshal engineers who actually understand implementation details. They can explain—accurately or otherwise—why a proposed requirement is technically infeasible or would compromise security or necessitates collecting more user data, not less.

Lawmakers, lacking that technical foundation, can't effectively evaluate these claims. Is the company genuinely describing a technical constraint, or are they inflating difficulties to avoid compliance costs? Without engineers on staff who can assess the underlying code architecture, legislators are negotiating blind.

The recent fight over Section 230 reform exemplified this dynamic. Platforms claimed that holding them liable for user content would require either prohibitively expensive human moderation or privacy-invasive automated scanning. Maybe true, maybe not—but few lawmakers had the technical background to evaluate whether these were real trade-offs or strategic exaggerations. The bills that emerged reflected that asymmetry.

What Technical Literacy Actually Requires

I'm not suggesting every regulator needs to code in C. But there's a minimum threshold of technical understanding required to legislate effectively in this space, and we're consistently falling short. You need to understand what encryption actually prevents (and allows). You need to grasp how data compression affects what can be reconstructed from compressed files. You need to know the difference between client-side and server-side processing, between hashing and encryption, between training data and model parameters.

Birch's tutorial isn't policy-relevant because file compression is under regulatory scrutiny (though it should be, given how it intersects with data retention requirements and privacy law). It's relevant because it demonstrates the level of technical specificity that software engineering requires—and that policy currently lacks.

When he writes "maybe we can set an upper limit at 4 billion bytes" for maximum file size, he's making a design choice with implications. That limit affects what files his compressor can handle, which affects what use cases it serves, which affects who benefits from the tool. Every technical decision is also a values decision. Regulators making those calls for entire platforms, affecting millions of users, should understand the technical terrain at least as well as someone building a hobby project.

The Path Forward

Some jurisdictions are starting to address this gap. The EU hired technical experts for its AI Act implementation. California's Privacy Protection Agency includes staff with engineering backgrounds. But these remain exceptions. Most tech policy gets drafted by lawyers and political staffers with liberal arts degrees—smart people who simply lack the technical foundation to evaluate what they're regulating.

The alternative isn't to hand tech policy over to engineers (who have their own biases and blind spots). It's to require that policy teams include people who can read code, understand system architecture, and assess technical feasibility claims. When industry says "this is impossible," someone in the room should be able to pull up the codebase and check.

Birch's compressor will sort 70,000 entries in 0.06 seconds. That's an implementation detail, but it's also a fact about computational feasibility that should inform data retention mandates, processing limitations, and privacy-by-design requirements. Good regulation accounts for these constraints. Bad regulation pretends they don't exist.

The technical knowledge gap isn't a minor oversight in tech policy—it's the structural problem underlying most regulatory failures in this space. Until lawmakers can distinguish between what companies claim is technically impossible and what actually is, every bill will be negotiated on terms that favor whoever can deploy more engineers to the lobbying effort. That's not a regulatory framework. That's just corporate self-regulation with extra steps.

Samira Okonkwo-Barnes is Buzzrag's tech policy and regulation correspondent.