by Richard Roberts
The Book That Let You Inside the Mind of the Builders
In 1986, a young editor at Microsoft named Susan Lammers did something quietly radical. She sat down with nineteen of the people building the software world from scratch and asked them not about their companies or their stock options, but about how they thought. The result was Programmers at Work — a 383-page window into the creative machinery of people like Bill Gates, Dan Bricklin, Gary Kildall, Jef Raskin, Andy Hertzfeld, John Warnock, and Jaron Lanier.
I remember reading it and coming away with something I hadn't had before: not a way to copy what these people had done, but a way to understand how they approached a problem — what they saw when the rest of us saw nothing, what they reached for when they were stuck, how they tolerated the ambiguity of making something that had never existed before.
That's the thing about the book that doesn't show up in any summary. The interviews aren't really about technology. They're about cognition and craft. They're about what it feels like to hold a complex system in your head long enough to actually understand it. They're about the moment an idea sketched on a napkin turns into a product millions of people use every day, without ever knowing who thought of it first.
I was a young programmer hungry to know if the way I was thinking was the right way to think. Programmers at Work told me there was no single right way — and that was exactly the right answer.
What Those Nineteen People Were Actually Doing
It's worth pausing on who these builders were and what they were building, because the context makes what comes next make sense.
Dan Bricklin and Bob Frankston had just invented VisiCalc — the first spreadsheet, the application that gave ordinary people a reason to buy a personal computer at all. Gary Kildall had built CP/M, the operating system that ran the early PC world before DOS arrived. John Warnock was at the early stages of what would become PostScript and then Adobe — the technology that would eventually give every desktop a printing press. Jef Raskin had conceived the original Macintosh project as a truly human-centered computer. Andy Hertzfeld had written the Mac's system software with an almost fanatical attention to elegance. Ray Ozzie, years before Lotus Notes or Azure, was already thinking about how software could connect people across distances and time.
These weren't celebrities when Lammers interviewed them. They were people who had looked at the landscape of what was possible and decided to build something in it. And they were doing it with tools that would seem almost medieval by today's standards — tight memory constraints, primitive debugging environments, no internet, no open source ecosystem, no Stack Overflow to catch them when they fell.
What strikes you reading the interviews today is the clarity of their thinking under those constraints. Every line of code they wrote was expensive, so every line had to carry weight. They had developed a kind of discipline around simplicity that grew directly from scarcity. They thought carefully before they typed.
The Patterns That Made Them
Across all nineteen interviews, certain patterns recur with remarkable consistency.
They played. Almost every programmer in the book describes an early period of pure exploration — not building products, not solving problems, just playing with what the machine could do. Bricklin sketched VisiCalc on a Harvard Business School chalkboard thinking about how a professor did financial projections. Hertzfeld was so consumed by the Mac's system code that he essentially lived inside it. The play came before the purpose.
They thought in systems. These weren't people who thought about features. They thought about the whole shape of a problem — the relationships between parts, the places where complexity lived, the points where a small architectural decision would echo for years. Butler Lampson, one of the great systems thinkers of the era, makes this almost explicit: good design is about finding the place where the problem wants to be simple and letting it be simple there.
They tolerated not knowing. Several of the programmers describe extended periods of confusion — of holding a problem that hadn't yielded yet, of trusting that if they kept turning it, something would eventually click. There's a peculiar kind of confidence required to stay in that state without panicking or giving up. These people had it.
They cared about the human on the other side. Jef Raskin's entire philosophy centered on the person sitting in front of the screen. He was almost allergic to the idea that users should have to adapt to machines. Bricklin tells a story about watching a professor laboriously update projections on a blackboard, erasing and recalculating, and thinking: a machine should do this, not a human. The empathy came first.
They learned from everything. Warnock came from mathematics. Lanier came from music and visual art. Kildall came from academia. They brought entire worlds of thinking with them and let those worlds collide with the problem of software. The cross-contamination of ideas was a feature, not a distraction.
Why We Need This Again — Right Now
Forty years have passed. The machines are unimaginably more powerful. The tools are incomparably richer. The ecosystem is vast and global and connected in ways those nineteen people could barely imagine.
And yet something important has quietly disappeared.
When you learn to build software today, you learn frameworks. You learn patterns. You learn the approved vocabulary of the current moment — the container orchestration tools, the machine learning pipelines, the cloud deployment workflows. This is not a criticism of those tools. They are the accumulated wisdom of decades of hard-won engineering knowledge and they are genuinely good.
But they can also stand between you and the actual problem. You can build sophisticated systems without ever developing the underlying intuition for why those systems work — the tradeoffs buried inside the abstractions, what you give up when you choose one architecture over another. The frameworks make you productive. They don't necessarily make you a builder.
More importantly: the moment of transition we're living through right now is exactly the moment when foundational thinking matters most.
We are at the beginning of something. Artificial intelligence — specifically the large language models and reasoning systems that have emerged in the last five years — has changed what software can do at a level as fundamental as the personal computer did in 1977, or as the internet did in 1993. The entire landscape of what's possible has shifted. New categories of software can be built now that simply could not have been built before. And the people who will define those categories are the people who understand the terrain well enough to see where the opportunities live.
That's the moment Programmers at Work was born into. That's the moment we're in again.
The Questions That Need to Be Asked Today
Lammers' genius was in the questions she asked. She wasn't interested in the products. She was interested in the minds building the products. Here is the equivalent set of questions for the builders of this era:
How do you think about the boundary between human intelligence and machine intelligence? The defining design challenge of this decade isn't which features to build — it's where to put the human in the loop, and why. The builders who are getting this right have a coherent philosophy about it. What is yours?
What have you built that surprised you? The most interesting systems always exceed the intentions of their designers. The spreadsheet gave rise to financial modeling at a scale Bricklin never imagined. The web page gave rise to the attention economy that Berners-Lee certainly never intended. What have you built that showed you something you didn't expect about the nature of the problem?
How do you know when a design is good? Not when it passes its tests. Not when it ships. When does it feel right — and what does that feeling actually tell you?
Where do you go when you're stuck? The debugging strategies of great programmers are a window into how they think about systems. Do you go for a walk? Do you write it out? Do you explain it to someone who doesn't understand it? Do you sleep on it? The answer reveals everything about where you locate intelligence in the process.
What do you think is about to become possible that isn't possible yet? This is the question that separates builders from maintainers. Bricklin saw the spreadsheet before it existed because he was watching a professor erase a chalkboard. What are you watching right now?
What is the craft element of what you do that you can't teach? Every great programmer I've ever known has something — some habit of mind or standard of judgment — that they arrived at through experience and can barely articulate. What is yours?
What do you wish you had known at the beginning? Not the technical knowledge — the conceptual framework. The thing that would have reoriented how you saw the problem from the start.
The New Builders
The people who need to answer these questions today aren't the same people who would have answered them in 1986. The field has expanded enormously, and so has the range of people building in it.
There are machine learning researchers at the frontier of what large models can do — people who live at the boundary between mathematics, neuroscience, and engineering and who are discovering things about intelligence itself in the process of trying to build better systems.
There are product builders who are taking the raw capabilities of these models and translating them into tools that ordinary people can actually use — the work that Bricklin did for the spreadsheet, that Raskin was trying to do for the personal computer. This translation work is harder than it looks and rarer than it should be.
There are domain specialists who are bringing their expertise — in law, medicine, agriculture, education, supply chain, construction, finance — to the problem of making AI systems that actually understand a field rather than merely imitating its surface. These people are building something genuinely new: software that encodes professional judgment, not just professional vocabulary.
There are infrastructure builders working on the layers below the visible surface — the systems that make reliable, cost-efficient, safe AI applications possible at scale.
And there are the people I find most interesting of all: the ones who are thinking about the second and third order effects. About what it means for human learning when AI can do more and more of what we used to use learning to develop. About what it means for organizations when the marginal cost of expertise approaches zero. About what it means for communities — for towns like McKeesport, for workers whose jobs are being remade or eliminated — when the productivity gains from these tools are not automatically shared.
All of these people are building the world. And almost none of them are being asked the questions that Susan Lammers thought to ask in 1986.
Everything Gets Built Again
Here is the core truth that Programmers at Work encodes, even though it never quite says it directly: everything gets built again.
VisiCalc was not the last spreadsheet. It was the first sketch of an idea that would be refined through Lotus 1-2-3, through Excel, through Google Sheets, through Airtable, through Notion, through a hundred other tools that each took one piece of the original insight and pushed it further. The spreadsheet is still being reinvented today because the underlying problem — helping humans organize and reason about structured information — is inexhaustible.
PostScript became PDF became the web became ePub became whatever comes after that. The operating system has been built and rebuilt a dozen times at different levels of the stack. Every major software category has been rebuilt multiple times as the underlying hardware, network, and human context shifted around it.
We are at the beginning of another complete rebuild of almost everything.
The document is being rebuilt — not as a container for static text but as a dynamic, AI-enhanced object that can generate, personalize, distribute, and collect responses at scale. The search engine is being rebuilt as a reasoning engine. The enterprise software suite is being rebuilt around natural language as the primary interface. The professional service — legal, medical, financial, educational — is being rebuilt as a collaboration between human judgment and machine capability.
Every one of these rebuilds will be done by someone who has studied the original enough to understand what made it good, and is creative enough to see how the new constraints and capabilities change what good looks like.
That's what Programmers at Work gave to the generation that read it. Not a blueprint, but a way of looking. A set of questions. A conviction that the craft mattered, that the mind of the builder was as interesting as the thing being built, and that understanding how the great ones thought was a legitimate path toward becoming one.
What Needs to Happen Now
We need a Programmers at Work for the AI era — and we need more than one.
We need it in the form of long-form interviews that take the time to go deep, that resist the pull toward the quotable sound bite and instead follow the thought wherever it leads. We need it in the form of documentation projects that capture not just what is being built but how the builder thinks about what they're building — the design journals, the architecture diagrams, the arguments that didn't win, the ideas that got cut. We need it in the form of communities where builders can share the actual texture of the work, not just the polished product.
We need it with a wider lens than Lammers had in 1986. The builders today include people from every country, every background, every discipline. The person reinventing agricultural supply chain management with machine learning in rural India is doing something as important as the person building a new programming language in San Francisco. The teacher figuring out how to use AI to reach the students who fell through the cracks is building something. The community organizer using data and automation to identify which vacant lots in a postindustrial city have the most potential for affordable housing is building something. We should be asking them all the same questions.
And we need to ask the questions with the same respect that Lammers brought — the respect of someone who genuinely believes that the way a person thinks is interesting, that craft is worth understanding, that the mind behind the work is as valuable as the work itself.
Because the thing that Programmers at Work understood, and that we tend to forget in the excitement of each new wave of capability, is that technology is not the story. The builders are the story. The moment of creation — when someone looks at a problem and sees a possibility that wasn't visible before — is the story.
That moment is happening thousands of times a day right now, all over the world, in languages and disciplines and contexts that the 1986 computing world would never have imagined. Most of those moments go undocumented. Most of those builders will never be interviewed. Most of what they know about how to think will die with them, or retire with them, or simply disappear into the noise.
We can choose not to let that happen.
A Starting Invitation
If you are building something at the intersection of artificial intelligence and human experience — whether you're a researcher, a developer, a domain specialist, a product designer, or simply someone who has looked at a problem in their field and decided that the new capabilities make it solvable in a way it never was before — I want to know how you think.
Not what you've built. Not your roadmap. Not your pitch.
How you think.
What questions do you keep coming back to? What surprises you? What does the craft of your work feel like from the inside? What do you know now that you wish you had known at the start?
The builders of this era deserve the same record that Lammers made for the builders of hers.
And the generations who come after us deserve to inherit it.
Richard Roberts is the founder of DataPublisher LLC and co-author, with Claude AI, of the five-volume series Building Intelligent Systems: A Pattern Language. He has spent thirty years building document automation systems and thinking about what it means to help human knowledge find the people who need it. He lives and works in McKeesport, Pennsylvania.