Legendary Programmers - the messiahs, madmen, and makers behind your favorite tools

Prefer watching instead of reading? You can watch the full walkthrough below, or keep scrolling to read the complete article.

Linus Torvalds - the Finnish right-click that changed the world

Linus Torvalds. A Finnish man born in the Australian summer of 1969. Nice. If you write code that goes anywhere near a server, there is a better-than-not chance that your bits passed through something Linus touched. He is responsible for the kernel that runs most of the internet, your routers, your TVs, your NAS, your Android phone, and that lab server you swear you did not root as a prank. He also made the tool you use to push your awful code. Yes, I am talking about Git, the thing you pretend to understand while Googling how to undo a rebase for the third time this week.

What he built and why it matters

Linux started as a hobby project in 1991, hacked together by a university student who wanted a free Unix-like system for his 386. Today, it is the backbone of modern computing. The kernel is a beast that handles scheduling, memory management, filesystems, device drivers, and all the internal plumbing you only notice when it breaks. It is not just that Linux runs on servers - it runs on everything from supercomputers to wristwatches. The breadth is wild, and the reason is clear: a clean architecture, relentless iteration, and a community that Linus shepherded with a mix of brutal honesty and real engineering standards.

Git, meanwhile, might be the most influential tool in a developer’s life. Born in 2005 after a licensing fallout, Linus built Git in weeks and accidentally invented the modern workflow of software collaboration. Commits, branches, merges, pull requests, distributed version control - all the verbs in your daily standup descend from a tool Linus designed to be fast, simple at the core, and unapologetically powerful. If you have ever bisected a bug with surgical precision, you have touched the original intent of Git: speed and truth. If you have ever merged main at 4:59 pm on a Friday, you have touched its chaos.

The mailing list energy

We cannot talk about Linus without mentioning the mailing list rants. The Linux kernel mailing list is where code goes to be judged. It is the Colosseum for patches. Linus is famous for plain talk, which sometimes reads like a flamethrower aimed at your feelings. But behind the bark is a clear philosophy: correctness over comfort, clarity over confusion, and quality over politeness. Does it sting to be told your code is bad? Yes. Does it make the code better? Also yes, most of the time. His directness shaped a culture where technical arguments win, not titles or vibes.

What you can steal from Linus

• Build tools you need, and build them well, even if you have to invent new concepts to do it.
• Keep the core simple and the edges extensible.
• Feedback should be honest, not cruel. And if it gets cruel, own it and fix it.
• Write for performance, but measure everything.

Related topic: How Git actually works

Richard Stallman - the printer jam that turned into a movement

Richard Matthew Stallman, the MIT hacker who got mad at a printer and changed software forever. The story is legend. There was a printer in the MIT AI Lab that kept jamming. RMS wanted to fix the driver so the printer would notify users when the queue was stuck. A simple tweak. Except the printer driver was closed. No source. No fix. So instead of shrugging and walking away, he decided that software should be free to study, change, and share, and then proceeded to dedicate his life to that idea with the stubbornness of a mountain goat.

GNU, the GPL, and the soul of free software

Stallman launched the GNU Project in 1983 to build a free Unix-like operating system. He wrote core tools like GCC and Emacs, which you can still install right now and use to ruin your wrists with key chords. The GNU General Public License, or GPL, is his big stick. It says you can use, study, modify, and share the code, but if you distribute your version, you must also share your changes under the same terms. That one idea reshaped the software world. It protected communities from code hoarding and turned open code from a hobby into a serious way to build.

The reason you can read code, learn from it, and build on top of it is because someone drew a line and said free means free. Combine GNU userland with Linus’s kernel and you get a family of operating systems we call Linux distributions. Ubuntu, Debian, Arch, Fedora - pick your poison. None of them exist as we know them without RMS drawing that boundary around freedom.

Warnings and footnotes

Here is my caution: use Stallman’s ideas to guide your work, but know the man is... intense. His personal writings and takes can be a lot. You do not need to model the vibe to respect the work. Focus on the GPL, the ethics of sharing code, and the idea that a community can produce better tools when everyone has the right to see how it is built.

John Carmack - the wizard who made 3D games a thing

Without John Carmack, your GPU would be bored and your childhood would be quieter. Carmack helped invent the idea of fast 3D on consumer hardware, co-founded id Software, and shipped games like Wolfenstein 3D, Doom, and Quake that did not just sell copies - they taught the world what a first person shooter is. If you ever fragged someone in a LAN party or got motion sick from a CRT at 90 frames per second, you have felt his influence.

Tech breakthroughs you actually use

Carmack’s genius is not just code volume. It is the way he picks the right trade-offs. He popularized techniques like binary space partitioning for fast rendering, invented new ways to light scenes in real time, and made networked multiplayer workable on the internet we had at the time, not the one we wished for. He is the kind of engineer who reads research papers for breakfast and then ships a playable build by dinner. Quake’s engine architecture influenced a generation of game engines. The famous fast inverse square root trick is part of the culture, not just a micro-optimization. Even if your code has nothing to do with graphics, the mindset is contagious: find the bottleneck, do the math, make it fast.

And then he went into VR. As CTO at Oculus, he pushed mobile VR from toy to real-time marvel, squeezing every cycle from a phone SOC like it owed him money. His talks are master classes in trade-offs, latency budgets, prediction, and raw engineering honesty. You want to see a brain that thinks in 3D and shipping dates at the same time? Watch Carmack riff on frame timing for 90 minutes without a single slide.

The Carmack approach

• Know the hardware. Not vaguely. Intimately. Caches, pipelines, memory bandwidth.
• Measure everything. Guessing makes pretty graphs and ugly products.
• Ship code and iterate. Theory is fuel, not a destination.
• Write the minimum that achieves the effect, then polish loops until they sparkle.

As a side joke, yes, Doom runs on calculators, ATMs, and probably your toaster. It is not a meme by accident. It is because the engine design is elegant and the community is rabid. If a device has a screen and a CPU, someone will port Doom to it by sheer cultural pressure.

Fabrice Bellard - the quiet polymath behind FFmpeg, QEMU, and tiny compilers

From France comes Fabrice Bellard, a developer whose Github graph should probably be a public monument. If you have ever watched a video online, there is a decent chance you touched FFmpeg, the suite that does format conversion, streaming, and transcoding like a Swiss Army chainsaw. If you have ever virtualized an OS for work or for fun, QEMU is likely running somewhere in the stack. And if you love compilers, TCC will make your jaw drop by compiling code at a speed that feels like a magic trick.

Things he built that you depend on

FFmpeg is the glue of internet video. It handles codecs, containers, filters, and all the weird edge cases your browser ignores until it does not. YouTube, streaming platforms, research labs, and your favorite meme generator rely on it to just work. When someone says a format is supported, someone like Bellard made it real in code.

QEMU is the emulator and virtualization workhorse that can emulate CPUs, boot operating systems, and let you test in environments you do not own. It is the tool you reach for when the hardware you need is imaginary or the OS needs a safe sandbox. Pair it with KVM and you get near native performance. It is hard to overstate how much this changed development and testing pipelines. You can boot a dozen virtual machines, experiment, snapshot, and move on without crying over a bricked laptop.

Tiny C Compiler, or TCC, is the sprinting goblin of compilers. It compiles fast, links fast, and boots fast enough in a special build that you can compile a Linux kernel in seconds. Not minutes. Seconds. That is not just a party trick. It is a reminder that compilers do not have to feel like grand pianos dropping on your build server. Speed is a design choice.

Oh, and the extras

Bellard did not stop there. He calculated a world record number of digits of pi. He built a complete PC emulator in JavaScript that boots Linux in the browser, just because Tuesday needed a puzzle. He created BPG, a high quality image format. His projects are a buffet of practical brilliance. None of this is gate-kept - it is all open source, which means you can read the code, steal the ideas, and fall into a productivity hole as you realize how much more you can learn.

Dennis Ritchie and Ken Thompson - the C and Unix tag team

New York gave the world many things, including Dennis Ritchie, one of the godfathers of modern software. If you use a programming language today, it probably owes a debt to C. If you use an operating system today, it probably owes a debt to Unix. Dennis, working with Ken Thompson, designed and built things so fundamental that you can draw a straight line from their 70s code to your 2025 stack. It is not an exaggeration to say they built the soil our field grows in.

C the language

C is tiny, dangerous, and beautiful. It gives you pointers, manual memory management, and a thin layer on top of machine code that says I trust you, do not betray me. It was designed to write operating systems, and it still does. It inspired C++, Objective C, C#, Java, JavaScript, Rust, Go, and basically every curly-braced thing you use to pretend you like semicolons. It is the language that shaped how we think about arrays, strings, structs, and the price of a stray pointer.

Dennis Ritchie’s book with Brian Kernighan, known as K and R, is still a rite of passage. It is short, clear, and opinionated in a way that modern books sometimes forget. Open it and you will learn syntax, yes, but you will also absorb a mindset: code should be simple, predictable, and respectful of the machine.

Unix the idea

Unix was not just an operating system. It was a philosophy. Do one thing well. Compose simple tools with pipes. Everything is a file. Build small programs that can be combined like Lego. This approach gave us shells, text processing pipelines, and an ecosystem that rewards clarity. Even if you do not run a pure Unix today, you live inside its descendants every time you grep, awk, sed, curl, or tail -f your way to enlightenment.

Ken Thompson, Dennis’s partner in crime, wrote the original Unix with Dennis and kept pushing. Later, at Google, Ken helped create the Go programming language with Rob Pike and Robert Griesemer. Go took the spirit of C and Unix - simple, fast, readable - and put it in a modern package with garbage collection and great tooling. Every time you ship a Go service in a container, you are walking a path that starts in Bell Labs.

Related topic: C vs C++ vs C#.

Kathleen Booth - assembly before assembly was cool

Before C and Unix and your fancy frameworks, there was assembly. And before assembly was a standard idea, there was Kathleen Booth. England’s computing history features a lot of early genius, and Booth is front and center. She co-designed early computers and created what is widely regarded as one of the first assembly languages, giving us an abstraction on top of raw machine code. That one step up is everything. It is the difference between flipping bits by hand and writing symbolic instructions like MOV and ADD that a human can reason about.

Why this matters to your daily coding

Assembly is the translator between you and the silicon. It is not a high level language, but it is a language. Without that layer, every program would be unreadable hex. Booth’s work made it possible to program faster, test faster, and share techniques with other humans without a migraine. The earliest computers were room-sized beasts with blinking lights and switch panels. When someone in a video points at a hulking machine and says she wrote code on this, picture paper tapes, patch cables, and early assemblers running on machines that would be laughed out of a thrift store today. That environment did not reward error. It rewarded precision.

Kathleen Booth’s contribution is not trivia. It is foundational. Every compiler you use emits assembly. Every performance bug you chase has assembly fingerprints. Every time you read disassembly to figure out why a function inlines funny, you are walking on a path she helped lay down. The concept of an assembler is so normal now that we forget it needed inventing. Someone had to say let us write human readable mnemonics and translate them to opcodes. That someone was Booth.

Terry A. Davis - TempleOS and the myth of the one-person OS

There are developers who just write code. Then there are developers who build their own world. Terry A. Davis built TempleOS, a complete operating system, compiler, and programming environment written largely by one person in around 100,000 lines of code. He wrote his own language, HolyC, designed for immediate, live coding in the OS. He picked a classic 640x480 resolution, a 16 color palette, and ring-0 execution for the entire environment. He set rules that made the computer feel like an old home micro, but with modern clarity. It is weird, it is brilliant, and it is open source.

What makes TempleOS special

TempleOS is not a Linux clone or a hobby UI on top of someone else’s kernel. It is the entire stack. The kernel, the compiler, the file system, the shell, the graphics, and the audio system all cohere. The OS boots into a REPL-like shell where you can write HolyC and execute it instantly. The compiler is built in, so the line between code and environment disappears. The holy in HolyC is part joke, part theme. The system includes a text mode aesthetic, a special font, and even a feature where you can generate text based on random input. It is a piece of software art that also happens to be technically surprising.

From a systems programming perspective, it is an education. You get a small, clean codebase that shows how a scheduler works, how a memory allocator works, how a filesystem is laid out, and how graphics can be driven without the layers of an industrial OS. If you have ever wanted to see an OS you can read end to end, TempleOS is the closest you will get without a time machine.

On the person behind it

Terry Davis struggled with mental illness. That is a fact that shaped his life and how people encountered his work. The respectful way to view TempleOS is to treat it as both a technical achievement and a personal expression. It does not fit the industry mold. It does not need to. If you are hungry to learn and willing to read code, you will find lessons in how much a single focused mind can build. You can honor that without making jokes at his expense. The code speaks loudly enough.

The thesis: a handful of people really did change everything

Let us be honest. Most of us write features on top of layers built by strangers. We tape libraries together, we configure YAML, we stare at CI logs that look like cursed ASCII art. But underneath every framework is a small group of minds who built the foundations: filesystems, compilers, kernels, game engines, window systems, protocol stacks. The legends in this article did not just ship code. They carved tunnels through mountains. They gave us a path where none existed.

What can we learn from them, besides the urge to drink black coffee and pace in socks while thinking about schedulers. A few patterns pop up across the board.

Patterns the legends share

• They build to scratch an itch. Linus wanted a Unix-like OS. RMS wanted a fixable printer. Carmack wanted real time 3D. When the itch is real, the project narrows itself.
• They ship and iterate. None of these projects were born perfect. They got better through use, feedback, and stubbornness.
• They pick simple cores. UNIX philosophy, HolyC immediacy, TCC speed-first design, Git’s content-addressed model - the core is simple and powerful.
• They share. Open source is not a trend for them. It is the default. Code out in the open attracts eyes, bugs, and brilliance.
• They fight for taste. Whether it is a coding standard, a license, a resolution, or a trade-off, taste shows up as consistency. Consistency scales.

Visuals you did not see, explained so you can picture them

When I say look at this, here is what I want you to imagine.

• For Kathleen Booth, picture a lab with cabinets the size of refrigerators. Panels with switches and patch cords. Paper tape feeding through a reader. A printer hammering out debug logs one character at a time. That is where assembly was born.
• For Linus’s mailing lists, picture a wall of plain text emails with code blocks and comments that cut through fluff. No pastel Slack flow. Just patches, diffs, and straight talk.
• For Carmack’s demos, picture a 90s beige PC roaring with a beefy fan, a CRT monitor flickering at high refresh, and a wireframe room spinning at 60 frames when the hardware spec sheet said 15.
• For Bellard’s FFmpeg, picture a timeline of video frames being decoded, filtered, and re-encoded like a conveyor belt at a factory staffed by robots who never sleep.
• For TempleOS, picture a boot to a clean, text-first UI with crisp colors. You type code. You run it instantly. The computer answers immediately, like an instrument instead of a bureaucracy.

So, how do you stop being awful

I cannot promise greatness. I can promise a path that moves you forward. Take a play from the legends. Pick a small project that hurts just enough to be fun. Build it in the open. Measure what matters. Learn your tools until they feel like extensions of your hands. Read source code from people better than you. Steal patterns. Question popular advice. And, yes, fix the printers in your life - the blockers that feel boring but shape everything else you do.

If you need a starting list, try these:

• Read the Git source code that implements commit objects. Just one file. See how simple the idea is.
• Write a toy assembler. Translate a tiny language to bytecode and run it in a small VM.
• Rebuild a simple software rasterizer. Draw a triangle on screen with barycentric coordinates. Feel the math.
• Use FFmpeg to transcode a video and chain three filters. Watch your CPU beg for mercy. Learn what each step does.
• Clone TempleOS and read a subsystem. Take notes on how the pieces fit.