In our last chapter we talked about how JCR Licklider changed history by convincing people that computers had a much bigger future than anyone imagined.
But Lick's dream of an Intergalactic Computer Network had one major problem.
How do you build a communications system that doesn't stop working every time something breaks? This is where the famous “survive a nuclear war” story begins.
The reality is a little more interesting.
The real goal was much simpler: build a network that could keep communicating even when part of it failed.
And the solution was brilliant.
Instead of sending data in one fragile stream, break it into small packets that can each find their own way through the network before being reassembled at the destination.
One of the first goals in designing the Internet was simple: build a communications system that could survive failure. Not just heavy traffic. Not just a broken wire. A system that kept going even when parts of it went down. And from that challenge came one of the most important ideas in computing history, packet switching.
Before we get to the forgotten engineer behind it, let’s break down the concept.
The old telephone system worked like this: if I wanted to talk to you, the network created one dedicated path between us. One wire. One circuit. One fragile connection. If that path failed, the conversation ended. Researchers needed something smarter.
So instead of sending one continuous stream of data, they broke every message into small pieces called packets.
Each packet carried its own destination address — like putting an address on every page of a letter. And here’s the clever part: the packets don’t all have to travel the same route. If one path is busy or broken, they simply take another. When they arrive, the receiving computer puts them back together in the right order.
Packet switching also made communications more efficient. Instead of reserving an entire circuit for one conversation, thousands of users could share the same communication lines, each sending tiny bursts of data whenever they needed.
It made the network more reliable, more efficient, and capable of supporting thousands, eventually millions, of users at once.
And one of the earliest minds behind this idea in the United States was Paul Baran.
Once you understand the importance of packet switching, it’s easier to appreciate why Paul Baran matters. He wasn’t just solving a technical problem. He was solving a survival problem.
Paul Baran was born in 1926 in Poland, the youngest of three children. His family fled to the United States in 1928, escaping the rising instability in Europe.
Baran grew up in Philadelphia, worked in his father’s grocery store, and like a lot of future engineers spent his free time tinkering with radios and electronics. He wasn’t a polished academic. He was a hands on problem solver.
After earning an engineering degree from Drexel, Baran worked at Hughes Aircraft, where he learned radar, microwave systems, and the gritty realities of real world communication hardware. That practical mindset is what made him so dangerous later he didn’t think like a theorist. He thought like someone who had seen systems fail.
In 1959, Baran joined the RAND Corporation, a Cold War think tank advising the U.S. military. RAND originated as Project RAND“ from the phrase “research and development” in the post-war period immediately after World War II. RAND was full of mathematicians, economists, and strategists.
Baran was the radio engineer in the corner asking annoying questions like: “What happens if the network breaks?”
And during the Cold War, that wasn’t a hypothetical. If the U.S. ever faced a nuclear attack, the first thing to go would be the communications network. One bomb could wipe out the central switching stations that kept military commanders connected.
Baran’s assignment was brutal:** Design a communications system that could keep working even if large parts of it were destroyed.**
Between 1960 and 1964, Baran wrote a series of RAND reports titled On Distributed Communications. These weren’t just academic papers, they were blueprints for a new kind of network. Baran proposed a decentralized system with no single point of failure. Instead of relying on one fragile path, information would be broken into small packets and routed dynamically across many possible paths.
If one route disappeared, the packets would simply go another way.
It was a radical idea at the time. Most communication systems were built around central control. Baran was proposing a network that behaved more like an organism — adaptive, resilient, and capable of surviving damage. And here’s the part history often forgets: Baran’s work wasn’t immediately embraced. Many engineers thought it was too chaotic, too unpredictable, too weird. Baran spent years fighting to get people to take distributed networking seriously.
When ARPA began designing the first large scale computer network, Baran’s reports were among the key documents on the table. His ideas didn’t create the Internet by themselves, but they provided one of its essential building blocks: the concept of routing information around failure instead of stopping dead.
Paul Baran wasn’t just an engineer, he was famously blunt, sarcastic, and allergic to bureaucracy. He didn’t play politics. He didn’t care about credit. He cared about solving the problem.
Baran didn’t become a household name. He didn’t get rich. He didn’t become a Silicon Valley celebrity. But his work helped make the modern Internet possible, and that’s why Paul Baran deserves to be remembered as one of the forgotten engineers who changed the world.