I found these insights interesting:

"I know that most people won't believe it, but a 100x increase in income really didn't have that big of an impact on me as a person. It is certainly nice to be in a position where people can't exert any leverage on you, but it's definitely not the primary focus of my life. I get to drive a Ferrari in to work, but my day to day life is almost exactly the same as it was eight years ago. I get up, go in to work, hopefully do some good stuff, then go home. I'm still happy." [1]

[...]

"I feel bad for some companies out there. The founders, who are these incredible engineers, are now directors of their departments doing management rather than engineering. At the same time most of the people they are managing are nowhere near as good as they were at doing the actual work. That's what I hope never happens to me. I want to stay in the trenches working on the things all the time. There is some benefit to sitting back, reading and researching and getting some broader scope on it. But if you're divorced from the low level nuts and bolts of things, like how this actually applies to the real world, then you're just an academic. You get these huge disconnects between what an academic can do and what somebody in production can do." [2]

[1] Page 77

[2] Page 89

I liked this gamedev-specific insight:

"It is also a mistake to think that Id’s games ride on technology alone. DOOM and Quake aren’t just the minimum work required to make a 3d and networking engine a game – they are the right game elements as well."

This can't be overstated. Minecraft was successful because it was a fun game, not just because it was new technology. (And say what you will about the implementation, but voxels were extremely rare until Minecraft.)

The key is to find a good game designer, or to become one yourself. Then defer to them on every aspect of the game. Even if you disagree with it, trust them. They're in charge of making it fun.

Voxels may be uncommon, but they still weren't new. There's nothing technologically new in Minecraft. And that's fine.

Same for Quake. BSP tech came from the field of medicine, for example, and rasterization wasn't new. Quake just did it so much better than anyone else, along with a fun game. As with Minecraft.

BSPs weren't new to the Quake engine (Doom had them). Gouraud shading, lighting, and TCP/IP multiplayer are what made Quake revolutionary for the PC. These things existed on SGIs costing $100k for years before too. The optimizations to make this on a PC is why Carmack is genius.

Not to be pedantic but TCP or UDP? I always thought games preferred UDP as it's much more efficient if you don't care about a fraction of the packages being dropped?

UDP's main advantage is the ability to process out-of-order - by sending duplicate state (actually more wasteful in terms of raw bandwidth!) or allowing for a lossy stream of data, your latency won't spike (as much) waiting for previous packets to be retransmitted. This isn't so much about efficiency per se, so much as it is about minimizing response time (even if it is potentially more bandwidth, potentially more CPU, more code, etc.) which matters a lot for some twitchy competitive games.

It's also not going to have any real impact if you're not dropping packets, nor if you're building your own reliable in-order channels atop that (which even the twitchiest game will likely have for some things if they're not using TCP as well - things like in game chat, leaderboards, matchmaking info, telemetry, etc. - a large number of which might use a full HTTP stack these days, if only under the hood of some official SDK, because why not use the same leaderboard server for your game clients and your website?)

And there's the occasional router (edit: or firewall, or other network appliance) that's so terrible, it manages to ship without a properly tested UDP stack, so a full blown TCP fallback isn't the worst idea ever.

TL;DR: Heckin' trade-offs.