Building a Bitmap in C and Who Really Needs This

There's a specific feeling you get watching a tutorial made by someone who actually knows what they're doing versus someone performing the act of knowing. The pacing is different. The mistakes are real. The throat-clearing is unrehearsed. When something goes wrong—a wrong cast, a forgotten include—they don't cut away. They just fix it, out loud, while you watch.

That's the texture of Coding a Bitmap in C, a recent video from Jonas Birch, who runs the YouTube channel dr Jonas Birch. It's beginner-friendly by his own description, but it doesn't feel like the kind of beginner-friendly that's been sanded smooth by a course platform's UX team. It feels more like pair programming with someone who has thought carefully about memory layout and is happy to think out loud with you.

The tutorial covers something genuinely foundational: how to build a bitmap data structure from scratch in C. A bitmap, as Birch explains it, is "a long string of bits, ones and zeros, where ones means a true value and zero means a false value." The pitch for using one is efficiency—if you need to store an array of boolean values, allocating a full byte (or worse, a word) per value is wasteful. A bitmap packs eight booleans into a single byte. At scale, that matters.

The video walks through three milestones: a constructor (make_bitmap) that allocates and zeroes the right number of bytes, a get_bit function that extracts a specific bit using division and modulo to locate the right byte and bitwise masking to pull the value, and a set_bit function that uses OR operations to set a bit and AND with an inverse mask to clear one. Birch closes with a working demo—set bit 9, read it back, get 1; unset bit 9, read it back, get 0—and a genuine-sounding "We got a one, ladies and gentlemen."

Done in, as he puts it, "less than an hour."

What the Tutorial Actually Teaches

The technical content is clean and the pedagogy is honest. There's a moment early on where Birch starts drafting a zero function with a source parameter, stops himself—"now wait a minute, we don't really need a source because we are not copying anything"—and backs up. That's not a mistake the video hides. It's a demonstration of how working programmers actually think: you sketch, you catch yourself, you revise.

The bit manipulation section is where the tutorial earns its keep for people who haven't internalized this yet. The logic is: to get bit number N, divide by 8 to find which byte it's in, take N mod 8 to find its position within that byte, shift a 1 left by that position to create a mask, AND the mask against the byte, then shift back right to get a clean boolean. To set a bit, OR the byte with the mask. To clear it, AND the byte with the bitwise inverse of the mask.

This is undergraduate systems programming. It also isn't taught everywhere, and it isn't taught well everywhere it is taught. The uses Birch gestures toward—image files encoding pixels, memory allocators tracking block availability—are real. Bitmaps show up in filesystems, in networking, in graphics pipelines, in schedulers. The pattern of "pack many booleans, address them by index" is one of those recurring idioms that, once you've internalized it, you start seeing everywhere.

The Bigger Question the Video Raises Without Knowing It

Here's what I actually find interesting about this, and it's not the bit manipulation.

Someone with a doctorate—the channel name isn't decorative—sat down to produce a careful, unhurried YouTube tutorial on building a bitmap in C, published it publicly, and labeled it beginner-friendly. No MOOC infrastructure. No credentialing pathway. No Coursera cohort. No certificate at the end. Just: here is the thing, here is how you build it, here is the code.

Who does that? And more importantly: who needs it enough that it exists?

I think about this in the context of the communities I cover. Open source is full of people who came up without formal CS education, or whose CS education was heavy on algorithms and light on systems, or who are making a mid-career pivot toward lower-level work because something in the stack they depend on keeps going wrong and they finally want to understand why. Bootcamp graduates who can ship a React app but don't know what malloc does. Self-taught developers who've been writing Python for a decade and are now staring at a C codebase for the first time because a project they care about is written in C.

These aren't edge cases. They're a substantial portion of the actual developer population building and maintaining open source software right now. And the institutional pipeline—universities, formal curricula—isn't serving them. The credentialing apparatus doesn't have a module for "you are 34 years old, you work full-time, you need to understand bitmaps by Thursday."

YouTube does. Or rather, YouTube hosts people like Birch who fill that gap on their own initiative, on their own time, for free.

The irony is that this kind of knowledge transmission—informal, unaccredited, personal—is actually how systems programming knowledge has always primarily spread. The C programming tradition runs on books like K&R that were written by practitioners for practitioners, on mailing lists, on Usenet, on IRC, now on YouTube. The formal academy was always a secondary channel. What's changed is the scale and visibility: a video like this can reach a developer in Lagos or Lahore who has no university systems course available to them, who is trying to contribute to infrastructure software, who needs exactly this explanation.

That's not a small thing.

Why C, Still, in This Particular Moment

The choice of C as the teaching language isn't neutral and Birch doesn't explain it—it doesn't need explaining to his audience—but it's worth naming.

C persists not because of inertia alone, though there is plenty of that. It persists because it is the lingua franca of the open source toolchain. The kernel, system libraries, compilers, interpreters, embedded firmware—C is where the foundations live. If you want to understand what your software is actually doing at the level where it touches hardware, you have to be able to read C. If you want to contribute to any of the foundational open source projects that the rest of the ecosystem sits on, you will encounter C.

There is a generation of developers who are being told, correctly, that memory-safe alternatives to C exist and matter. Rust is real, and its momentum in the kernel and in systems-adjacent projects is real. But the transition is slow, the codebases in C are enormous and aren't going anywhere on any timeline that matters to someone trying to contribute to them today, and the conceptual literacy that C teaches—how memory works, what a byte actually is, why pointer arithmetic does what it does—transfers directly to the new languages.

Teaching someone to build a bitmap in C isn't teaching them a dead skill. It's teaching them to think at the level of abstraction where the interesting problems in open source infrastructure still live.

Birch mentions, in passing, that bitmaps appear in memory allocators "where each bit means a block of memory that has been allocated or not." He says it quickly, as an example, and moves on. But that's a thread that runs through nearly every foundational open source system a developer is likely to encounter. The people who need to understand that—who are looking at codebases they didn't write, trying to understand systems they depend on—are watching videos like this one.

The question isn't whether this tutorial is good. It's good. The question is what it tells us that this is how the knowledge gets there.

Dev Kapoor covers open source software and developer communities for Buzzrag.