In a 1999 interview with IEEE Computer, Ken Thompson was asked how he finds abstractions that are simple yet powerful. His answer is the most honest thing I've read about design talent:
"I am a very bottom-up thinker. If you give me the right kind of Tinker Toys, I can imagine the building... The converse is true, too. I can't from the building imagine the Tinker Toys. When I see a top-down description of a system or language that has infinite libraries described by layers and layers, all I just see is a morass. I can't get a feel for it."
Then the line that reframes it: "Maybe I do what I do because if I built anything more complicated, I couldn't understand it. I really must break it down into little pieces."
That's not a humblebrag. It's a design constraint stated plainly. Unix's simplicity may be a consequence of its author's limits.
Coherence is a social artifact
The interview's best institutional observation is about why Plan 9 and Inferno use "a small number of abstractions" so aggressively. Thompson says it's "the direct result of a very small number of people who interact closely during the implementation. It's not a committee where everyone is trying to introduce their favorite thing."
The mechanism he describes is not a process. Teams form like water molecules: you finish something, you're bored, you latch onto someone else, you say "I have an idea for a language," someone asks about networking, someone else has a model, and a team of two or three forms. Rarely above five or six.
You can't copy that by writing it in a strategy doc. And he's explicit that the same people produce bad ideas at the same rate as good ones: "I have certainly generated as many bad ideas as I have good ones." The filter is that ideas are tried, not argued.
How arguments actually get resolved
His answer on technical disputes is refreshingly unmanagerial: "You say, 'I am right, the hell with you.' And, of course, the person who has been 'to helled with' wants to prove his point, and so he goes off and does it. That's ultimately the way you prove a point."
Two conditions make that work: low ego, and the ability to throw away a failed experiment. "If it's a failure you come back and say, 'Do you have another idea?'" He notes this is hard to do in a product-development environment, which is a polite way of saying most organizations can't.
The Unix mistake
The most technically interesting passage is his account of Unix's "glaring error": it didn't separate local from remote I/O. open/close/read/write was one group of interfaces, with no concept of remoteness. "It was a glaring omission and was the reason that some of the awful things came into Unix like ptrace and some of the system calls. Every time I looked at later versions of Unix there were 15 new system calls, which tells you something's wrong."
That's a durable lesson about abstractions: the one you don't design becomes the one you bolt on. Plan 9's answer was to make everything a file and export that interface over the network, so remoteness stopped being a special case.
The prediction, and what aged
Thompson's closing assessment of computer science is famously gloomy: it's entering middle age, becoming a commodity, and "computing is a finite field and it's reaching its apex and we will be on a wane after this."
The mechanism he gives for why nothing displaces incumbents has aged better than the conclusion. The entry fee is too high: a new operating system has to carry "a thousand staff-years worth of applications that you can't obtain the source for." Microsoft won't give you Office, and re-engineering it gets you sued. "Nothing was going to topple IBM until something came along that made them irrelevant."
He also said: "Anybody who says there's no more innovation in the world is doomed to be among the last 400 people who have stated this since the birth of Christ."
My take
The interview is worth reading for three things, in descending order of usefulness.
The constraint is the style. Simplicity as a personal necessity, not a virtue. That's a better model for design than "simplicity is good," because it explains why the taste is hard to teach: it's the shape of a person's cognitive budget.
Abstractions you don't design become system calls. Unix's missing remoteness is a case study in debt that compounds through version numbers.
Incumbents are displaced by irrelevance, not competition. That's the most useful sentence for anyone building a platform today. You don't beat the incumbent at its game; you make the game not matter.
The gloomy conclusion is the part I'd discount. He was right that the commodity phase arrived, and right that the entry fee is brutal. But "the apex" assumed the field's boundaries were fixed. The last few years have been a decent argument that they weren't.