The Pragmatic Engineer Podcast

Hosted by Gergely Orosz · 441 korrents · 19 episodes · 19 guests · 2 turns · newsletter.pragmaticengineer.com ↗

Gergely Orosz did not write this page.

Each episode below lists what its guest said, quoted word for word from the transcript the show publishes and linked to the second it was said, so you can hear it rather than take our word for it. The sentence on each line is our reading of the claim, not their wording. Nothing the host ASKED is here, on any line: a question is not a belief, however confidently it is phrased. Where Gergely Orosz asserts something in their own voice it is on their own page, never counted against a guest.

19 guests

Kent Beck 38 Kelsey Hightower 28 Anders Hejlsberg 26 Casey Muratori 26 Charity Majors 26 Dex Horthy 26 Martin Kleppmann 26 Steve Yegge 25 Dax Raad 24 Hillel Wayne 24 Thuan Pham 24 Alice Ryhl 23 Addy Osmani 22 David Heinemeier Hansson 22 NeetCode 21 Nicole Forsgren 18 Simon Willison 18 Chip Huyen 14 Martin Fowler 10

Everything they said, in one feed →

Filter & sortNewest first

About Everything coding agents 67 software quality 24 AI and jobs 23 LLMs 19 vibe coding 19 design 18 software performance 17 AI agents 14 hiring 13 code generation 12 developer tools 11 ambition 10 compilers 10 AI and human skill 9 formal proof 9 management 8

Episodes Newest first Oldest first Most korrents

Hide the quotationsShow the quotations

Casey MuratoriGame and engine programmer, creator of Handmade Hero and of the Computer Enhance course on performance-aware programming, and a long-standing critic of object-oriented design orthodoxy. He worked on the user interface of Jonathan Blow's The Witness, which is the codebase his writing on compression-oriented programming draws its examples from.26 Aug 2026 · 1h 53m · 26 korrentsOn software performance, compilers and video games

Why performant code matters (but gets widely ignored), with Casey Muratori

Casey Muratori

Our page for this episode →Watch on youtube.com ↗

Our reading — their words are on the recording

0:18:28
Our reading
Performance cannot win a market on its own: against an incumbent held up by network effects, being far more responsive is a nice plus and nothing more.
Their wordsmaybe performance could be part of a package where you try to take on one of those players. like, hey, look at how much more responsive our thing is than theirs. Might be a nice plus, but that's not going to be sufficient.
software performance
0:19:45
Our reading
A decade of arguing that software is too slow has started to work: new products are now attacking established categories on a performance pitch alone, and getting traction.
Their wordsI also see people attacking major product categories now with performance-based pitches. Things like File Pilot or the Blick video editor, like things like this that have been coming out lately where it's like, oh, really performant software to try to take on uh incumbents in a space and they've been getting traction.
software performance
0:20:51
Our reading
A 300-millisecond response budget is not an achievement but an admission: 300 milliseconds is an eternity in computing, and a product pitching it shows how far the bar has fallen.
Their words300 milliseconds is like an eternity in computing, right? And so if you're talking about like our pitch is that we're not more than 300 milliseconds, that just shows you how the bar was so far past where it probably should have been for something.
software performance
0:21:36
Our reading
The software industry is massively underperforming its hardware, by factors of ten to a hundred, and people refuse to believe the numbers when you say them.
Their wordsIt's just like we are massively underperforming and people don't believe it when you say 10x 100x but it's actually true and we've seen a lot of proof of it as you point out.
software performance
0:24:09
Our reading
Optimization means measuring the gap between your code and what the hardware could theoretically do, not making changes and checking whether the statistics improved.
Their wordsWhat is the underlying hardware capable of doing at its theoretical peak? And then you measure the delta between that theoretical maximum and what you have achieved.
software performance
0:27:37
Our reading
Source code in any language tells you nothing about what the CPU is actually asked to do; only the compiler's assembly output does, and reading it is a skill every serious programmer should have.
Their wordsIf I look at the assembly language output from that compiler, I know exactly what the CPU is being asked to do. And it's not that hard to be able to learn to read assembly language so that you can see very quickly is the CPU being asked to do the things that I think it should be asked to do them.
compilers

All 26 from this episode, along the running time →

Addy OsmaniEngineering leader and author who spent 14 years at Google, most of it on Chrome and Chrome DevTools, rising from software engineer to director of engineering, and who created TodoMVC and helped push Core Web Vitals.19 Aug 2026 · 1h 32m · 22 korrentsOn coding agents, design and AI agents

From Chrome DevTools to AI Engineering, with Addy Osmani

Addy Osmani

Our page for this episode →Watch on youtube.com ↗

Our reading — their words are on the recording

0:14:00
Our reading
Computing is an onion, and the more layers of it you can peel back and understand, the better you can build for the constrained machines real people are using.
Their wordsif you treat computing as this onion where you just keep peeling back the layers, there's always something interesting behind the scenes. And the more of those layers that you can peel back and understand, I think in some ways the better you can optimize for that world.
software performance
0:29:39
Our reading
Very few developers understand memory management, and that is why the state of the art in memory debugging has barely moved in years.
Their wordsI would say, sometimes, I don't know if it's controversial, that very few developers understand memory management. And that makes it even harder to debug memory problems. And so the state of the art around memory debugging hasn't evolved all that much over the years.
0:37:10
Our reading
Performance work used to mean half a day reading traces before writing a single fix, and language models have collapsed that step to minutes.
Their wordsI remember anytime I would work with a big site on their performance problems, uh you could easily spend half a day, um you know, just looking at traces before you've even written any fixes at all. And now that we have LLMs, it's very quick to like reason through massive stack traces and actually be able to get down to fixes you can make.
LLMs
0:41:46
Our reading
"Is the page loaded?" was never a real question, and web performance only became measurable once it was broken into the distinct moments a user actually notices.
Their wordsI think for a very long time we had this this almost nebulous way of thinking about page load times. And the team felt like it was finally time to come up with a more nuanced perspective around how we reason about performance.
software performance
0:43:29
Our reading
People treat an unresponsive interface exactly the way they treat a slow pedestrian crossing: they keep hitting the button.
Their wordsHumans are humans are are shockingly simple, you know, uh, if you think about the experience you have with somebody that's just trying to cross the street, if, uh, you know, if the light doesn't turn, you know, doesn't say they can walk fast enough, they'll just keep hitting that button. That's the same experience they have on the internet.
design
0:44:05
Our reading
A site's need to monetise is not a defence of an experience that shifts the page under the reader; those are separate questions.
Their wordseven if you set aside, you know, maybe there's some validity around a business needs to monetize, those things shouldn't cause a really bad experience.
design

All 22 from this episode, along the running time →

Charity MajorsCo-founder and CTO of Honeycomb, previously an infrastructure engineer at Parse, Facebook and Linden Lab. Co-author of "Database Reliability Engineering" and "Observability Engineering". Writes at charity.wtf about on-call, hierarchy, hiring and the engineer/manager pendulum.12 Aug 2026 · 1h 26m · 26 korrentsOn code generation, vibe coding and coding agents

Stop being skeptical about AI for development with Charity Majors

Charity Majors

Our page for this episode →Watch on youtube.com ↗

Our reading — their words are on the recording

0:07:24
Our reading
Team output is still what matters, however hard the industry pushes to measure individual output.
Their wordsI also believe that, you know, there's been this whole push towards individual output, but teams are still what matter. Teams output.
0:08:01
Our reading
Equating better with faster is a very immature description of what better means.
Their wordsWe can go fast. Let's do same thing faster, you know, just boom. And I've come to feel like that is a very immature description of what better is.
0:10:31
Our reading
The step change in AI coding in 2025 came from the harnesses and the tooling around the models, not from the models themselves.
Their wordsAnd it wasn't actually the models. It was the harnesses. It was all the tooling.
coding agents
0:12:04
Our reading
There is no point arguing about whether or when engineers will ship code they have not read; the only useful question is what it would take.
Their wordsWhat I was saying in that piece though was, I think we were right to be skeptical that time. But now, I see the same thing playing out with would you be willing to ship it some code you didn't read? There's no point in arguing about if it will happen or when it will happen. Talk about what it would take.
vibe coding
0:14:55
Our reading
You can now generate ten thousand variants of a function faster than you could write it once, and that economics pushes software towards replacement rather than repair.
Their wordsI mean, if you if you think about it, you could generate 10,000 variants of a function faster than you could write it once.
code generation
0:17:03
Our reading
Lines of code are the wrong artifact to review; what we should be storing and reviewing is an architecture that generates the code to spec.
Their wordsLike that just does not seem like the ideal artifact. We should be able to store them somewhere. We should be able to have architecture diagrams that we can review and discuss that generate that code to spec.
code generation software quality

All 26 from this episode, along the running time →

Hillel WayneWriter and consultant on formal methods, testing and software correctness, author of Logic for Programmers and Practical TLA+. He ran the Crossover Project, interviewing seventeen people who worked as traditional engineers before becoming software developers, to settle by evidence whether software engineering is engineering.29 Jul 2026 · 1h 24m · 24 korrentsOn formal proof, LLMs and mathematics

Formal methods with Hillel Wayne

Hillel Wayne

Our page for this episode →Watch on youtube.com ↗

Our reading — their words are on the recording

0:07:09
Our reading
Every branch of engineering hates waterfall, not just software.
Their wordsIf I had to summarize what I found in general, I'd put it like this. Everybody hates waterfall.
0:07:18
Our reading
The core tension of all engineering is between how expensive a mistake is and how quickly you can iterate, and that alone decides how much planning a field does.
Their wordsThe core tension of engineering is between how expensive it is to make a mistake and how quickly you can iterate. The faster you can iterate, the less planning you need to do before you iterate, and the more expensive it is, the more planning you need to do.
0:08:30
Our reading
Software did not invent iterative development: mining engineers had their Agile revolution in 1960.
Their wordsAnd the first thing he pointed out to me was that they had their Agile revolution in 1960.
0:12:11
Our reading
Software is the only field of human labour with practitioner conferences and freely shared knowledge; every other field has only academic conferences and trade shows.
Their wordsSoftware is kind of unique in having the third kind of the practitioner conference where we are just meeting to get better at what we do. We also are really the only kind to really focus heavily on like open source in making our knowledge freely available.
0:15:07
Our reading
Version control is the one thing every traditional engineer wishes their old field had.
Their wordsYeah, I interviewed like 20 people on this. I think all 20 mentioned version control as the thing they wish they had in their old field.
developer tools
0:15:54
Our reading
Software iterates better than every other engineering field and plans worse than all of them.
Their wordswhile we are a lot better at iterating than other fields, we're worse at the planning part. Like we still need to do some kind of planning before we iterate and we just aren't as good as those other fields.

All 24 from this episode, along the running time →

Dex HorthyFounder of the agent company HumanLayer, author of the 12-factor agents principles, and the engineer who put the name "context engineering" on the practice.15 Jul 2026 · 1h 33m · 26 korrentsOn coding agents, LLMs and software quality

Context engineering with Dex Horthy

Dex Horthy

Our page for this episode →Watch on youtube.com ↗

Our reading — their words are on the recording

0:21:28
Our reading
Every abstraction in agentic programming — RAG, memory, agentic history, structured output — is just a different way of passing tokens into a model, and understanding that beats learning any of them.
Their wordsAnd at the end of the day, they're all like different ways to pass tokens into a model and ask it to produce usually some structured output. And understanding that is a lot more powerful than trying to learn memory and trying to pick some agent framework off the shelf and some memory framework off the shelf.
LLMs coding agents
0:26:43
Our reading
Harness engineering is raising the floor: optimising the environment a coding agent runs in so that the results of every single turn are as good as possible.
Their wordsWell, harness engineering just is like how do I raise the floor so that every single turn of this thing, the results are as good as possible.
coding agents
0:27:52
Our reading
Context engineering has stayed relevant for a year because it is grounded in how transformer attention works, and it will matter to anyone building on AI until post-transformer models arrive.
Their wordsI think context engineering has been so long lived because it's it's grounded in the fundamentals of how transformer attention works and until we have post transformer models or linear attention or whatever it is which who knows when that's going to happen context engineering will be interesting and important to anyone building on AI
transformers LLMs
0:29:05
Our reading
A bigger context window does not give you a smarter model; the intelligence of the model is what decides how much of that window it can actually attend to.
Their wordsYou're not actually getting a like smarter model. like the intelligence of the model is is what drives its ability to attend to all of the tokens in the context window to figure out on the next turn which parts of this 100k or 200k context window are the most relevant to making the decision of like what is the next tool we call and doing that over and over again in a loop.
LLMs
0:30:15
Our reading
Context has two budgets, not one: the information budget everyone thinks about, and an instruction budget, where conflicting instructions cost the model real computation to ignore.
Their wordsBut it's also your instruction budget is like if you give the model too many instructions and especially too many conflicting instructions and that's in your initial prompt and also like if you have a conversation you start going down a path and then you change your mind and you start going down a different you actually I don't want to do any of that I want to do this. It's like a it's a lot of computation the model has to do to notice that it has to ignore that whole thing.
LLMs
0:32:15
Our reading
The engineering intuition that matters cannot be taught from a textbook — you know bad patterns in software because you have debugged them at three in the morning.
Their wordsthere's a different kind of intuition that you that you develop over years as a software engineer and uh there's many categories of it but the one I'll I'll call attention to that is like a thing that you cannot teach you cannot do you cannot learn in a textbook. The only way to learn it is like I know bad patterns in software because I have debugged them at three in the morning.
software quality

All 26 from this episode, along the running time →

Kent BeckCreator of extreme programming and test-driven development, an original signatory of the Agile Manifesto, and the author of Test-Driven Development: By Example and Tidy First?1 Jul 2026 · 2h 28m · 28 korrentsOn software quality, coding agents and design

How Kent Beck shapes the software engineering industry

Kent Beck

Our page for this episode →Watch on youtube.com ↗

Our reading — their words are on the recording

0:04:00
Our reading
Saying that coding will be automated away first betrays a misunderstanding of software engineering, because coding is only a small part of the work.
Their wordsMy response is that that's a statement by someone who doesn't understand software engineering. Coding is part of what you're doing, but it's only a small part of what you're doing.
AI and jobs
0:05:08
Our reading
The industry is now accumulating code faster than it is accumulating trust, and trust only comes from having struggled to understand the domain yourself.
Their wordswe're accumulating code faster than we're accumulating trust and that sense of trust comes from me struggling to understand some domain concept I get it. I represent it in the code. I have I write tests that demonstrate that I really did understand it. And now I trust my program.
code generation software quality
0:07:42
Our reading
Engineers were promised that understanding the computer would be enough, and the human skills they were told they could skip turn out to be the hard part.
Their wordsSo I was promised just understand the computer and then just kidding understand people from a position where I was already 10 years behind.
0:23:57
Our reading
Letting non-programmers build their own unmaintainable software is still a large step forward, because the alternative was a thousand-page requirements document and an eight-year wait.
Their wordsYou look under the underneath though at the code and it was just a horrible unmaintainable mess. But the fact that people could program the programs that they wanted was a a significant step forward as opposed to I'm going to write a thousandpage requirements document and then wait 8 years and not get what I want which was the alternative that we were offering at the at the time.
0:37:05
Our reading
Programs exist to communicate intent to other people and now to models as well, and we do not understand at all how to communicate effectively to models.
Their wordspart of the goal of programs is to communicate intent to other human beings and now to models as well which which is a much more open-ended problem. We understand a lot more about how to communicate to other human beings whether we apply that understanding or not. We don't understand at all how to communicate effectively to models
LLMs
0:43:00
Our reading
An outside expert's understanding of somebody else's problem is bounded, because they do not have to live with the design after they leave.
Their wordsYour understanding of somebody else's problem is bounded because you're not in the middle of it. You don't have the same skin in the game. If you're not semiconductor test engineer, you don't have as much skin in the game as somebody who is because they're going to have to be using this interface for a long time after you're gone.
design

All 28 from this episode, along the running time →

NeetCodeNaveed Singh, the software engineer behind NeetCode, the coding-interview preparation site and YouTube channel; formerly at Amazon and Google.24 Jun 2026 · 1h 29m · 21 korrentsOn hiring, code generation and coding agents

Tech interviews with NeetCode

NeetCode

Our page for this episode →Watch on youtube.com ↗

Our reading — their words are on the recording

0:04:26
Our reading
The data-structures-and-algorithms interview never tested a skill that transfers to the job; what it tested was whether somebody can think.
Their wordsAnd DSA interviews were never the best for that. Well, thinking, sure. But in terms of like does that skill translate to what you're doing on the job? It never really translated to that. It was more about evaluating like does somebody think?
hiring
0:04:41
Our reading
The coding interview has survived because companies have no idea how to evaluate candidates, and they probably never did.
Their wordsAnd the second reason that's stayed sticky is that companies just have no idea how to evaluate. Like And they probably never did.
hiring
0:05:45
Our reading
What blocks big companies from changing their interview process is interviewer training: most interviewers are not good at interviewing and hate doing it.
Their wordsThe training is really hard to get to get down cuz it's like interviewers are just not good. Like the most interviewers do not like interviewing. They hate it.
hiring
0:06:29
Our reading
New interview formats are coming, but the transition away from the coding interview will be slower than most people think.
Their wordsI think we probably will see different interview formats introduced. I just think it is going to be a slower transition than most people think.
hiring
0:11:29
Our reading
Nobody should still be learning the CAP theorem, because the theorem that replaced it is more complete, no more complicated, and simpler to understand.
Their wordsI don't understand why anybody would learn the CAP theorem when that theorem exists because it's just more complete. It's not that much more complicated. I think it's more simple to understand.
0:21:42
Our reading
Promotion at a big company is mostly about landing the right team and the right project: a 100x engineer put on easy work has no hard problem to point at.
Their wordsit's just right team, right project, cuz if you don't get the right project, there's no way you can prove yourself. You could be a 10x, 100x engineer, and if you're working on relatively easy stuff, you can't really say that you solved like a really hard problem.

All 21 from this episode, along the running time →

Kelsey HightowerSelf-taught software engineer, formerly a distinguished engineer at Google Cloud and one of the most visible voices in the Kubernetes community; retired from full-time work in 2023 and now advises and invests.3 Jun 2026 · 2h 52m · 28 korrentsOn AI and human skill, AI and jobs and design

Kubernetes and retiring at the top with Kelsey Hightower

Kelsey Hightower

Our page for this episode →Watch on youtube.com ↗

Our reading — their words are on the recording

0:18:52
Our reading
Entrepreneurship is over-glorified: a parts-and-service business has none of the upside people imagine, because it does not grow the way a software company does.
Their wordsand it turns out people kind of over glorify entrepreneurship. I think a lot of people believe there is tremendous upside, right? the type of entrepreneurship we talk about with software companies, the the upside is crazy. But when you're doing like selling parts or service business, unless you plan to open lots of stores and you know grow a larger employee base, it's not the same growth trajectory as software companies.
startups
0:32:22
Our reading
Being an all-star at the activity is not impact: the measure is whether the team's queue is empty, not how many calls you personally took.
Their wordsAnd it's the first time I learned the difference between activities and impact. activity is you being an all-star answering a bunch of calls, but the ticket queue for the team is still high.
1:01:56
Our reading
Every talk you give is a job interview, because an audience is reading what you are as much as what you are saying.
Their wordsAnd what I learned from the puppet days, every presentation is an interview. I don't think a lot of people think about it that way cuz people are looking at you on stage and they get to see what you're about.
hiring
1:16:31
Our reading
Kubernetes won because Docker had already won: it inherited the one container runtime the whole industry had agreed on, instead of shipping another.
Their wordsI think the number one success criteria was docker so remember there was mos and msosphere and they had their own runtime corp had come out with nomad and they had their own runtime but the biggest runtime that had already got global consensus was docker
1:16:56
Our reading
Docker Swarm lost because it stretched a single-node API across a cluster, and no amount of bolted-on storage and networking could repair that choice.
Their wordsThey tried to take the Docker API which worked really well for one node and expand it across multiple systems and it was not the right API to scale to another type of thing that we needed. And so they kept trying. They tried to add storage. They tried to add networking but the Docker API was never meant for that.
1:19:51
Our reading
The real shift Kubernetes made was from infrastructure as code to infrastructure as data: you declare the object and control loops reconcile it, instead of running a program.
Their wordswe went from infrastructure is code to infrastructure is data and infrastructure is code is like if this do that um bring in this module for loops all this stuff and Kubernetes is like no no no you have to specify exactly the containers you want how much memory that they need and then we have the status field to tell you if they were running or not
infrastructure

All 28 from this episode, along the running time →

Dax RaadBuilds developer tools — SST, and now OpenCode at Anomaly. Co-hosts the How About Tomorrow? podcast with Adam Elmore.27 May 2026 · 1h 21m · 24 korrentsOn product management, coding agents and AI and jobs

Building OpenCode with Dax Raad

Dax Raad

Our page for this episode →Watch on youtube.com ↗

Our reading — their words are on the recording

0:04:58
Our reading
Before product-market fit, coding faster does not help: it is better to think a lot than to swing a lot, and AI does not speed up the thinking.
Their wordsBut I've always thought it's better to think a lot instead of swinging a lot. I think you could you can eliminate a lot of ideas or directions just by, you know, spending a lot of time in your head and with your team talking. Um, obviously AI doesn't speed that part up.
product management ideas vs execution
0:05:41
Our reading
Answering every problem, competitor and user request with one more shipped feature does not add up to a good product; it adds up to a horrible one.
Their wordsIf you add that up, you think, "Oh, we shipped a thousand features. Now that adds it to a good product." It actually adds it to a horrible product.
product management
0:05:52
Our reading
Shipping ten times as much is not an advantage, because the moment you ship something you are stuck supporting it forever and every later feature has to interact with it.
Their wordsThe moment you ship something, you're stuck supporting it forever. And by supporting, it means any future feature you build is going to like interact with it. So you still have to be very conservative with what you put out there. It's hard to undo anything. Just cuz we can ship 10 times more doesn't mean we have 10 times as many good ideas to ship out there.
product management
0:06:44
Our reading
Nobody in the coding-agent market is using AI so much better than everyone else that their competitors cannot keep up — the gap you would expect to see simply is not there.
Their wordsnone of our competitors are crushing us either. Like no one out there is using AI so well that they just like we can't even compete, right? Um, and we're in the coding agent space. All our competitors are super into AI. So you would think in our space there would be like uh a huge gap, but there there just isn't.
coding agents
0:18:32
Our reading
In every developer-tool category — databases, compilers, whatever — the open source option eventually becomes the default option.
Their wordsevery single dev tool we use whether it's databases, compilers, whatever eventually the open source option becomes a default option, right?
open source developer tools compilers
0:25:18
Our reading
A small company's most reliable play is to pick one temporary bad guy and galvanise all of their competitors into pushing something forward against them.
Their wordsthe strategy that we know how to play really well is to pick one temporary bad guy and then galvanize all their competitors to push something forward against them.

All 24 from this episode, along the running time →

Alice RyhlSoftware engineer on Google's Android Rust team, a core maintainer of the Tokio async runtime and an adviser to the Rust language team.20 May 2026 · 1h 05m · 23 korrentsOn Linux, compilers and cybersecurity

Why Rust is different, with Alice Ryhl

Alice Ryhl

Our page for this episode →Watch on youtube.com ↗

Our reading — their words are on the recording

0:05:24
Our reading
Rust's defining experience is that once the code compiles it works — not literally true, but true often enough that people keep saying it.
Their wordsI think part of what I liked about Rust is this feeling that as you write the code when it compiles it works. I mean this has to be in quotes right because obviously it's possible that there are bugs but this is something a lot of people say about Rust and there's a reason people say it even though it's not necessarily literally true.
0:05:48
Our reading
A language can only give you the feeling that compiling means working if it has a type system — that is where it all starts.
Their wordsI think to have a language that feels this way you have to have a type system. That's where it all starts.
0:08:06
Our reading
For a TypeScript team, Rust belongs on the backend — API servers — and not in the front end.
Their wordsBut okay, so to begin with, I think when it comes to TypeScript, Rust fits in as the backend language. That's where I would put it. I wouldn't use it in the front end. I think it's a pretty good fit for backends, API servers.
TypeScript
0:10:12
Our reading
Examples in documentation should be compiled and run as tests, so that changing the code breaks the docs instead of quietly outdating them.
Their wordsNow the thing is you can of course write examples in your documentation and Rust makes all examples into tests. This means that if you change the underlying code now your test fails. And so this means that you can't even you can't forget to update your examples in your documentation.
documentation
0:12:15
Our reading
A compiler that names every place a change breaks turns refactoring into fixing errors until the compiler stops shouting.
Their wordsI think this is kind of leads to another way that Rust really helps with reliability, which is that if you're refactoring, I think Rust is really good at telling you all the places you need to update. I've done this sometimes where I would refactor something. I change the code. I change the return type or whatever it is, and then I just fix the compiler errors and until the compiler stops shouting. And then once I've done that, I've updated every place I need to update.
compilers
0:13:47
Our reading
The case for Rust is stronger against C++ than against JavaScript, because in C++ an ordinary mistake is usually a security vulnerability.
Their wordsSo, here I actually think it's even stronger. The thing with C++ is that if you make a mistake, right, in in JavaScript, maybe you take down your server, which is already bad enough, but in C++ when you make a mistake there, now it's actually a security vulnerability most of the time.
JavaScript cybersecurity

All 23 from this episode, along the running time →

Anders HejlsbergDanish software engineer and Microsoft technical fellow, creator of Turbo Pascal and Delphi and lead architect of C# and TypeScript.13 May 2026 · 1h 16m · 26 korrentsOn JavaScript, TypeScript and coding agents

TypeScript, C# and Turbo Pascal with Anders Hejlsberg

Anders Hejlsberg

Our page for this episode →Watch on youtube.com ↗

Our reading — their words are on the recording

0:09:10
Our reading
A programming language is not a compiler but an experience: editing, running, debugging and the runtime library all have to fit together as one cycle.
Their wordsThat was always the idea, and that that goes back even to the predecessor of Turbo Pascal, this idea that it's not just a compiler. It's an experience, right? I mean, you don't just compile your programs. You also edit them. You also run them. You also debug them. You also have a runtime library. It all has to like fit together.
compilers
0:11:17
Our reading
Turbo Pascal won because it was ten times better at a tenth of the price — faster, smaller, more interactive and cheaper at once.
Their wordsIt was just better than all the competition. It was faster. It was smaller. Um it was more interactive and it was also cheaper. So, it was like 10 times better at a tenth of the price of the of the competition, right?
0:17:39
Our reading
It is a bad strategy to bet your development platform on technology licensed from a competitor.
Their wordsAnd so, we kind of realized at that point, too, that maybe it's not a great strategy to to place your your development platform bet on on technology that's licensed from a competitor.
0:19:49
Our reading
C# exists because developers wanted both things at once: the power and productivity of C++ with the ease of use of Visual Basic.
Their wordsWell, like I said, I mean the the overarching thing was this: power and productivity of C++ with the ease of use of Visual Basic in a sense, right?
0:22:03
Our reading
A language should be designed by a small group of people rather than by one person.
Their wordsI think early on we decided that we want to have a team of people design this language, not just one.
0:22:41
Our reading
Language design is ninety per cent the same work every time and ten per cent new, which is why the experience carries from one language to the next.
Their wordsAnd quite honestly, language design is 90% the same and 10% new for for pretty much every language. Every language you build still has to have a compiler. Compiler is still built in a pretty much the same way.
design

All 26 from this episode, along the running time →

Martin KleppmannComputer science researcher at Cambridge, author of Designing Data-Intensive Applications, after a decade in industry at his own startups and LinkedIn.22 Apr 2026 · 1h 25m · 26 korrentsOn formal proof and the cloud

Designing Data-intensive Applications with Martin Kleppmann

Martin Kleppmann

Our page for this episode →Watch on youtube.com ↗

Our reading — their words are on the recording

0:23:17
Our reading
Reliability in a data system means fault tolerance above all: the system keeps working when a network link is cut or a node dies.
Their wordsfor me, reliability means fault tolerance primarily. So, meaning that a system should, on the whole, continue working even if like a network link is interrupted or a node crashes or something like that.
0:24:01
Our reading
Scalability is not a property a system has; it is the set of mechanisms it has for coping with a change in load.
Their wordsScalability is just like what mechanisms we have for dealing with changes in load. If load increases, how can we add computing capacity to a system, for example, so that the system still continues working?
0:25:37
Our reading
Scaling down is half of scalability: cost and capacity should track load in both directions, right down to a service that is nearly free to run.
Their wordsgenerally, like you just want the the cost and the computing capacity to be roughly proportional to the load that you have. And at the low end, that means actually being able to scale down to something that is extremely cheap to run.
0:29:38
Our reading
Building databases on object stores is a genuine architectural break, because replication moves out of the database and into the storage layer.
Their wordsAnd now suddenly people are building databases on top of object stores, for example. And now the replication happens at the object store level, no longer at the database level.
0:31:55
Our reading
An engineer writing business logic loses nothing by not understanding the layer underneath, exactly as they lose nothing by not managing memory.
Their wordsYou're building higher-level business logic, actually I think it's just fine for people not to care about memory management.
0:32:17
Our reading
Higher-level abstractions do not abolish low-level knowledge; they concentrate it in the smaller group of people who build the abstractions.
Their wordsBut, somebody still has to build those lower-level abstractions and from lower-level components. Somebody's got to implement the cloud services.

All 26 from this episode, along the running time →

David Heinemeier HanssonCreator of Ruby on Rails, CTO of 37signals, and creator of Omarchy.8 Apr 2026 · 1h 47m · 22 korrents · 2 turnsOn coding agents, AI and jobs and ambition

DHH’s new way of writing code

David Heinemeier Hansson

Our page for this episode →Watch on youtube.com ↗

Our reading — their words are on the recording

0:03:50
Our reading
Build the product for yourself first: if it truly serves you, plenty of other people like you will want it too.
Their wordsAnd whenever I build something that really just hits the spot for me personally, there are thousands of others just like me or close enough to what I like that they find the same pleasure and joy in it.
0:04:57
Our reading
Rails is having a renaissance because it is one of the most token-efficient ways to build a web app, which suits agents, for as long as that lasts.
Their wordsI think in some ways Ruby Rails is having a little bit of a renaissance now that it is one of the most token efficient ways of building web apps. It's ideally suited for the agent workflows we're dealing with now. We'll see how long that lasts.
Ruby on Rails coding agents
0:07:46
Our reading
For a web developer Linux is simply better than the Mac: closer to what you deploy on, with phenomenal tooling and a reproducible setup.
Their wordsanyone who's working with the web, who's working with Ruby, who's doing DevOps, they should be on Linux because first of all, that's closer to what we deploy.
Linux
0:09:46
Our reading
Basecamp was the best business idea he will ever have: lightning is not caught twice, and a founder's second idea is rarely as good as the first.
Their wordsAnd I have no shame in saying that Base Camp was the best idea objectively in terms of a business that we've ever had.
startups
0:23:27
Our reading
Designers should find what the spec should be and build it in HTML and CSS themselves, not make a product manager's spec look pretty.
Their wordsDesigners at 37 Signals are not just here to make a spec look pretty. They're here to find what the spec should be. They're product managers in many ways.
CSS design product management
0:28:33
Our reading
Aesthetics is truth: when something is beautiful it is likely to be correct, in code as in mathematics and physics.
Their wordsI mean, I think aesthetics is truth. When something is beautiful, it's likely to be correct. I think this is true in mathematics. This is true in physics. This is true in a lot of different domains that when you arrive at something that has the correct aesthetic quality.
taste mathematics physics

All 22 from this episode, along the running time →

Kent Beck, Martin Fowler& Kent Beck: Frameworks for reinventing software, again and again7 Apr 2026 · 32m · 20 korrentsOn coding agents and AI and jobs

Martin Fowler & Kent Beck: Frameworks for reinventing software, again and again

Kent Beck Martin Fowler

Our page for this episode →Watch on youtube.com ↗

Our reading — their words are on the recording

6:06
Our reading
For twenty-five years the senior people had the answers to hand, and what has changed is that at this moment nobody knows the answer to anything.
Kent Beck’s wordsAnd one of the things I noticed is for 25 years we've kind of had the answers. Somebody comes to us and says we have too many bugs or like, all right, well, here's how you write tests. Oh, I can't write tests. Well, here's how you design so you can write tests. It's just kind of press play uh on the recorder. And the thing that's changed is at this moment nobody knows the answers to anything.
7:11
Our reading
The job of senior people now is to demonstrate not how to use these tools effectively, but how to figure out how to use them, which is a different set of skills.
Kent Beck’s wordsSo, as seniors, I figure it behooves us to demonstrate not just how to use these tools effectively, but how to figure out how to use these tools effectively, cuz that's a whole different set of skills.
coding agents
7:54
Our reading
Nothing in a fifty-year career has hit the industry with the magnitude of AI; it is a whole size difference from anything before it.
Martin Fowler’s wordsWell, nothing has hit with the magnitude of AI. That's I mean, this is a a whole size difference from anything that we've faced before.
8:38
Our reading
Every earlier wave, the internet included, had to be argued for; AI is the first where nobody has to be persuaded that it matters.
Martin Fowler’s wordsbut the thing about AI is that, you know, all of many of these things we were talking about how important they were and how valuable were and trying to persuade people of the importance of them. Yes, even the internet. That may sound surprising, but there were people who would weren't thinking that was important. Um but AI, there's kind of no argument about how important it is. People can't can I mean, you cannot put blinkers on to deny the importance of this thing.
11:35
Our reading
Skepticism about a new technology only works if it is total enough to be turned on itself, which is what forces you to stay curious.
Martin Fowler’s wordsMy skepticism has to be absolute and total, which means I have to be skeptical about my skepticism. And that requires that curiosity.
11:58
Our reading
Asking what the smallest experiment is that would settle a claim to your own satisfaction has become a thousand times more valuable in the last year.
Kent Beck’s wordsYeah, what what's the smallest experiment I can run to verify to my own satisfaction and everybody's level of satisfaction is going to be different whether or not this claim is true. That's That's the skill that is suddenly in the last year become a thousand times more valuable is that skill of saying, "What's the least I can do to validate for my to my own satisfaction whether this claim is true?

All 20 from this episode, along the running time →

Thuan PhamUber's first Chief Technology Officer, from 2013 to 2020; later CTO of Coupang and of Faire.1 Apr 2026 · 1h 39m · 24 korrentsOn coding agents, design and hiring

Scaling Uber with Thuan Pham (Uber's first CTO)

Thuan Pham

Our page for this episode →Watch on youtube.com ↗

Our reading — their words are on the recording

0:11:21
Our reading
A technology being right is never enough on its own: whether it wins turns on whether the world is ready for it and whether the economics work at that moment.
Their wordsIt's not about just a technology. It's about whether the world is ready for it, whether it's economically feasible.
innovation
0:16:45
Our reading
Growth without profit is not yet a company: fast growth only makes a business durable once it has been converted into sustained profit.
Their wordsThere has to be sound business model that makes sustained profit, right? Growth and profit. Growth alone eventually burn, you know, money and that's not good.
0:17:41
Our reading
Today's AI boom will end the way the dot-com boom did — consolidation, a wave of failures and a few genuinely great companies — and customers, not argument, will decide which is which.
Their wordsThere may be a lot of AI things that's going on right now, right? Uh eventually some of these things will consolidate, some will go under, some will become really awesome solutions and all that stuff. And so, but the the market will sort it out.
0:26:48
Our reading
A career is not built by searching for jobs but by accumulating a reputation slowly, so that when you become available the opportunities come to you.
Their wordsif you try to do a really good job at every company you've been working well with all the people that you work with, including your own team, your peer, whatever it is. Over time, very slowly, you accumulate a decent reputation in people's mind.
0:36:58
Our reading
A technical leader should let engineers find the flaw in their own design through leading questions rather than announce it, because a discovered flaw is acted on and a reported one is argued with.
Their wordspretty soon by asking those leading question, the engineer now discovered a flaw that this thing would not scale,
design
0:37:48
Our reading
The right way to specify a rescue rewrite is a couple of scaling constraints and no new features at all, so that hardware can absorb the growth the team has no time to design for.
Their wordsNo new feature necessary. Just make sure that we can do that. And then that allow the business the company to just pour a whole bunch of hardware behind that and it will scale.
design

All 24 from this episode, along the running time →

Chip HuyenBuilding when it feels like there's nothing left to build - The Pragmatic SummitEngineer and writer on machine-learning systems; author of Designing Machine Learning Systems and AI Engineering.29 Mar 2026 · 20m · 14 korrentsOn vibe coding, AI agents and coding agents

Chip Huyen: Building when it feels like there's nothing left to build - The Pragmatic Summit

Chip Huyen

Our page for this episode →Watch on youtube.com ↗

Our reading — their words are on the recording

1:41
Our reading
Because anyone can now rebuild whatever you make, the ordinary incentive to build software has been knocked out from under us.
Their wordsI feel like now I can build anything I want. But at the same time, anyone can build anything I want. So, what is the incentive structure for me to do anything?
vibe coding
3:38
Our reading
Anything a person can describe, AI can now produce — software has reached the point image generation reached with style.
Their wordsif you can describe a style, AI can generate it. And the same with software. If you can describe a software, then AI can build it for you.
vibe coding
3:48
Our reading
Every product put into the world removes the need for imagination, because it becomes something anyone can point AI at and copy.
Their wordsAnd the more you build, right? The more you put things out there, you remove the need for imagination. You can say, "Okay, now I like that website. Do that for me."
vibe coding
4:46
Our reading
The reason to keep building is that building is practice at problem-solving, and the supply of problems will never run out.
Their wordsThe product you build is just solving a problem. So, is that like is the more you do that, the better you become at problem solving. And one thing I do believe that it will never change that there will always be problems to solve.
5:28
Our reading
Problems follow a long tail: AI will keep getting better at the common ones, and the edge cases will never go away.
Their wordsSo, I think of them as the top of the long long tail long tail problem. Like, something very common issues that a lot of people experience. AI will get really good at it. And over time AI will cover more more edge cases, but the edge cases will never go away.
coding agents
6:58
Our reading
The problems worth a small builder's time are the ones too small for a big AI company to be motivated to solve.
Their wordsLike if it's a big problem, like everyone can see, then all these big companies will get into it. But whereas it's like there are a lot of problems that's like smaller, then maybe OpenAI won't be motivated to solve it, but maybe I can like all a lot of people can.

All 14 from this episode, along the running time →

Nicole ForsgrenLeading high-performing engineering teams in the age of AI - The Pragmatic SummitResearcher of software delivery performance, co-author of "Accelerate" and of the DORA, SPACE and DevEx frameworks, and author of "Frictionless".22 Mar 2026 · 32m · 18 korrentsOn coding agents, AI agents and management

Nicole Forsgren: Leading high-performing engineering teams in the age of AI - The Pragmatic Summit

Nicole Forsgren

Our page for this episode →Watch on youtube.com ↗

Our reading — their words are on the recording

2:18
Our reading
AI did not create the bottlenecks in software delivery; it threw gas on processes everybody already knew were weak.
Their wordsThere were a handful of people probably managing a security review process or a launch process or a deployment process or, you know, sometimes reviews were a little slow and they got backed up. Well, now we just threw gas on the fire and so all of that is a problem.
coding agents
2:42
Our reading
AI sped up the part of software work we could see, and it is the delivery systems downstream that are now being overwhelmed.
Their wordsAnd so, like in the immediate term, yeah, we were getting more out, but now our systems, whether technology systems or human systems or processes, are really kind of getting overwhelmed.
coding agents
3:17
Our reading
Review became a worse bottleneck under AI, because companies removed the review automation they had once AI started writing the code.
Their wordsAnd not only that, but like humans were already a bit of a bottleneck in the review process. Now it can be worse because things that we fairly straightforward changes that some companies had automation around reviewing, they've removed that reviewing because if AI is involved and they're worried about the verifiability or the reliability of the code.
coding agents
3:51
Our reading
Release management is human group sense-making, and it does not scale to the volume of change AI now produces.
Their wordsso many times that process has been managed by humans because you're selecting the right candidate build and you're verifying it and you're thinking, you know, you're figuring out cherry picks and then you like rebundle and then you send it out and that doesn't scale if you have one or two or a handful of people trying to make group decisions and do group sense making.
coding agents
5:22
Our reading
The processes organisations build to make work uniform are usually the same processes that slow the work down.
Their wordsOr like all of the the things that we have structured process around to try to make things more uniform are often the things that slow us down.
management
5:41
Our reading
Delivery will keep being slow until companies apply AI to the human, business-process half of it, not just to coding.
Their wordsa lot of companies haven't started until now thinking about how we could apply AI to the very human, very business process part of it. And so, that will keep slowing us down until we find a way to to address it, right?
AI agents

All 18 from this episode, along the running time →

Simon WillisonEngineering practices that make coding agents work - The Pragmatic SummitCo-creator of Django and creator of Datasette; writes daily at simonwillison.net.19 Mar 2026 · 28m · 18 korrentsOn coding agents, prompt injection and LLMs

Simon Willison: Engineering practices that make coding agents work - The Pragmatic Summit

Simon Willison

Our page for this episode →Watch on youtube.com ↗

Our reading — their words are on the recording

4:07
Our reading
A team can stop reading the code it ships, but only by first working out how its agents are to prove that what they wrote actually works.
Their wordsit turns out you can do this if you think really hard about okay, how do I have agents prove to me that the stuff they've written works?
coding agents vibe coding
4:43
Our reading
Trusting model-written code you have not read became defensible only with Opus 4.5, and only for classes of problem you have already watched a model handle.
Their wordsI think Opus 4.5 was the first one that earned my trust. Like I'm very confident now that for classes of problems that I've seen it tackle before, it's not going to do anything stupid.
Anthropic vibe coding
5:55
Our reading
Test-driven development matters more with coding agents than it ever did with people, because its real effect is stopping the agent writing more code than the task needs.
Their wordsthe key thing about TDD is that it means that the agents won't write more than they need to.
coding agents
6:41
Our reading
Writing code with a coding agent and no tests at all is indefensible, because the old objection to testing — that it is extra work you then have to maintain — no longer applies.
Their wordsI think I see people who are writing code with coding agents and they're not writing any tests at all. That's a terrible idea.
7:16
Our reading
A passing test suite is not evidence that the software works, so an agent must also be made to start the thing and exercise it the way a person would.
Their wordsjust cuz the test suite passes doesn't mean that the web server will boot. You know, there's there's always a chance that when you actually try in the real world, something's not going to work.
software quality
8:37
Our reading
A language-agnostic conformance suite is the most powerful thing you can hand a coding agent, because the whole instruction becomes: write code until these tests pass.
Their wordsAnd what you can do if you've got one of these conformance suites is you can give it to a a good agent and say, "Write code until this test suite passes." And it kind of will.

All 18 from this episode, along the running time →

Steve YeggeSoftware engineer of four decades who spent years at Amazon and Google, wrote the Stevey's Blog Rants essays, and co-authored the book Vibe Coding with Gene Kim.11 Mar 2026 · 1h 32m · 25 korrentsOn AI and jobs, coding agents and innovation

From IDEs to AI Agents with Steve Yegge

Steve Yegge

Our page for this episode →Watch on youtube.com ↗

Our reading — their words are on the recording

0:06:38
Our reading
Deep compiler knowledge is still interesting, but it is no longer useful to a working engineer in any meaningful sense.
Their wordsI had a lot of my own ego and identity wrapped up in my sort of compiler background. It's all It's interesting, right? But it's it's not useful in any meaningful sense anymore.
compilers
0:18:08
Our reading
The engineers laid off in AI's name will mostly not find jobs again, they are the first of many, and nobody has a plan for them.
Their wordsI'm mad at Amazon for laying off 16,000 people and blaming AI without an AI strategy for it. Those people are not going to be able to find jobs, by and large, and they're the first of many to come and nobody has a plan for this.
AI and jobs
0:18:44
Our reading
A company must cut half its engineers to pay for the other half's tokens, and that is what the layoffs are actually about.
Their wordsBecause they're all starting to spend their own salaries in tokens. And so, at least for a while, if you want your engineers to be as productive as possible, you're going to have to get rid of half of them to make the other half maximally productive.
AI and jobs
0:19:01
Our reading
Big companies will lose about half of their engineers, because that is where everybody is setting the dial.
Their wordsAnd so, what's happening is everybody on average is setting that dial to about 50% and we're going to lose about half the engineers from big companies, which is scary.
AI and jobs
0:19:23
Our reading
Groups of two to thirty people will produce output that rivals what the big companies produce.
Their wordsit's also enabling engineers who have seen the light and believe the curves are going to continue to go up to actually get together in groups of two and five and 10 and 20 and 30 people and start to do things that rival the output of these big companies that are tripping over themselves.
team size
0:20:17
Our reading
Being anti-AI in 2026 is like being anti-the-sun: the people who stay that way will have to go live underground.
Their wordsI think a lot of the people coming out of knowledge work are just anti-AI. And those people are going to struggle. I'm sorry, but if you're anti-AI at this point, it's like being anti-the the sun. You're going to have to go live underground, right?
AI and jobs

All 25 from this episode, along the running time →