Gergely Orosz
@GergelyOrosz • 352,080 subscribers
Writing @Pragmatic_Eng, the #1 software engineering newsletter on Substack. Author of @EngGuidebook. Formerly Uber & Skype.
Videos
![If you’ve ever opened Chrome DevTools, or optimized a page for Core Web Vitals, you’ve used software built by Addy Osmani. Timestamps: 00:00 Intro 02:50 Addy’s current workflow 05:11 Addy’s path into tech 15:04 Addy’s work on jQuery 16:44 TodoMVC 21:44 Getting hired at Google and working on Chrome 27:17 Building dev tools 40:15 Core Web Vitals 45:42 Google’s engineering culture 51:03 Addy’s career trajectory at Google 57:55 The director role at Google 1:01:40 Cognitive debt and cognitive surrender 1:03:03 Working with agents 1:05:52 Loop engineering 1:12:55 The changing role of the software engineer 1:18:15 How Addy uses AI in writing 1:27:40 What’s next for Addy 1:28:47 Career advice Brought to you by: • Antithesis – verify your system’s correctness without human review or traditional integration tests – and avoid bugs or outages. Teams like Jane Street, and the etcd community use Antithesis to ship better code, faster. • Sentry – application monitoring software considered “not bad” by millions of developers. • Google Cloud Run – run untrusted agent code without the security anxiety. Cloud Run sandboxes deliver hyper-isolated, ephemeral execution environments that spin up in milliseconds. Check them out: Here's Addy's advice on where he believes engineers should invest efforts, in the coming years, in his words: “What we are very likely to see happen next with engineering careers (as well as product and other roles) is the unbundling of them, so that an engineer also has product sense, while a product person also has engineering sense, or UX sense. You should think about the non-engineering things if you don’t [usually] have the time to think about product or technical evangelism, or go-to-market approaches, or any other parts of how businesses are successful. If you can show employers that you are not just a builder, but someone that can help them as roles start to become a little bit fuzzier, then I think that you can be successful in these times. Don’t be just an engineer.”](https://image.24vids.com/tw-2090157324853711104/amplify_video_thumb/2090150304385826816/img/ASs7Kqxe2HIp5WNg.jpg)
If you’ve ever opened Chrome DevTools, or optimized a page for Core Web Vitals, you’ve used software built by Addy Osmani. Timestamps: 00:00 Intro 02:50 Addy’s current workflow 05:11 Addy’s path into tech 15:04 Addy’s work on jQuery 16:44 TodoMVC 21:44 Getting hired at Google and working on Chrome 27:17 Building dev tools 40:15 Core Web Vitals 45:42 Google’s engineering culture 51:03 Addy’s career trajectory at Google 57:55 The director role at Google 1:01:40 Cognitive debt and cognitive surrender 1:03:03 Working with agents 1:05:52 Loop engineering 1:12:55 The changing role of the software engineer 1:18:15 How Addy uses AI in writing 1:27:40 What’s next for Addy 1:28:47 Career advice Brought to you by: • Antithesis – verify your system’s correctness without human review or traditional integration tests – and avoid bugs or outages. Teams like Jane Street, and the etcd community use Antithesis to ship better code, faster. • Sentry – application monitoring software considered “not bad” by millions of developers. • Google Cloud Run – run untrusted agent code without the security anxiety. Cloud Run sandboxes deliver hyper-isolated, ephemeral execution environments that spin up in milliseconds. Check them out: Here's Addy's advice on where he believes engineers should invest efforts, in the coming years, in his words: “What we are very likely to see happen next with engineering careers (as well as product and other roles) is the unbundling of them, so that an engineer also has product sense, while a product person also has engineering sense, or UX sense. You should think about the non-engineering things if you don’t [usually] have the time to think about product or technical evangelism, or go-to-market approaches, or any other parts of how businesses are successful. If you can show employers that you are not just a builder, but someone that can help them as roles start to become a little bit fuzzier, then I think that you can be successful in these times. Don’t be just an engineer.”
Gergely Orosz398,385 просмотров • 2 месяцев назад
What do developer tools look like inside Uber, today? They are very different from what you would see at most places. We get a rare tour with one of Uber's longest-tenured engineers, Uday Kiran Medisetty (Uday Kiran Medisetty) - who was at Uber already when I joined in 2016! Timestamps: 00:00 Intro 02:48 Uday’s early days at Uber 05:40 Uber’s move to microservices 07:55 Uber’s engineering team, then and now 09:05 Developer tooling before AI 16:03 DevPods 19:28 Building for AI agents 29:27 MCP gateway 34:37 Agent Skills repo 38:46 The context graph and Cortana 47:54 PRD and ERD tool 50:45 Minion 54:46 Testing and code review with Bazel, Slate, and Capri 1:12:26 Edge Gateway, Shepherd, and Wisdom 1:21:33 The changing role of engineer and measuring productivity 1:30:40 Uday’s favorite new products Brought to you by: • turbopuffer – The tpuf eng team is rebuilding their storage architecture from first principles to make search faster, cheaper, and more reliable at scale. Follow along at • Linear – the product development system for teams and agents. Check out Linear Diffs: a new feature to review PRs inside of Linear, with all the context in one place. • WorkOS – how do you deal with agents and permissions? WorkOS built Airlock, the authorization layer for AI agents. Works with Claude Code, Codex and MCP gateways. Three things you probably did not know about Uber: 1. At Uber, cities are a first-class concept that go all the way down to physical infrastructure. One reason Uber had to build a lot of its custom tooling is how the concept of cities is a “basic primitive” that needs to be handled across systems like observability, feature flagging, deployments, and even service sharding. For example, in the early days, some services had their database sharded by cities. Even today, each city is pinned to a cloud region, and can fall over to another region at any time. 2. A single AI model gateway has paid lots of dividends. In 2023, Uber’s platform team made the decision that everything built with AI needs to be model- and harness-agnostic. They built Model Gateway to support switching between Anthropic, OpenAI, other vendor models, and now also supports open models they run. 3. Uber tags PRs by the type of work each of those PRs do. In the past, Uber measured “PR velocity:” how long it took for a PR (or, as Uber calls it: a “diff”) to get to production. With agents, doing so makes less sense, because it’s easy to create dozens or even hundreds of PRs, and many of those PRs might have no business impact on the product. So Uber now tags all PRs by type: feature, bugfix, maintenance, testing, or docs. They are seeing the percentage of “feature PRs” going up, and the percentage of “maintenance PRs” going down. I find this categorization to be a clever approach!
Gergely Orosz26,365 просмотров • 4 дней назад
Pretty incredible how the skills repo by Matt Pocock is only 6 months old, and has more stars than the React one. We had to sit down and talk. Timestamps: 00:00 Intro 05:48 How Matt got into tech 10:14 How Matt got into open source 12:58 Joining Vercel 18:39 Total TypeScript 23:21 AI’s impact on technical education 30:32 Building reusable skills for AI coding agents 40:46 The “smart zone” vs the “dumb zone” 45:02 The wayfinder skill 47:52 Why agents excel at software engineering 50:54 “Leading words” 1:01:10 Learning the fundamentals 1:09:17 Local vs. cloud agents 1:12:36 Planning vs. course-correcting 1:18:13 TDD and agents 1:23:06 Living in the UK 1:24:21 Teaching: the human part 1:28:36 Advice for junior engineers 1:31:07 Gardeners and great engineers 1:34:01 Book recommendation Brought to you by: • turbopuffer – vector and full-text search engine built on object storage. It’s fast, cheap, and extremely scalable. • Linear – the product development system trusted by 40,000+ teams to plan and ship. Get six months of Linear Business for free: • WorkOS – The fastest AI-native teams have to slow down for the hard problems. WorkOS makes sure auth, for your app and your agents, is never one of them. Thanks for the convo Matt Pocock!
Gergely Orosz133,493 просмотров • 1 месяц назад
What can us, engineers else learn from designers and design engineers? Turns out there’s lots, based on talking with one of the best design engineers in the industry, Maggie Appleton. Timestamps: 00:00 Intro 03:24 From anthropology to tech 10:18 What does a designer do? 18:23 How Maggie works 24:55 The case for planning with physical tools 31:53 Why Maggie is learning woodworking 33:13 Design engineers and engineering constraints 38:49 How Maggie uses Figma 40:30 Design at GitHub Next 45:12 How has AI changed design 50:37 When models design and why humans are still needed 53:30 UX and UI 58:29 Capability gaslighting 1:00:33 One Developer, Two Dozen Agents, Zero Alignment 1:07:21 Craft and AI tells 1:14:17 Visual gardens, home-cooked software, and barefoot developers 1:21:02 Advice for engineers and lessons from anthropology 1:25:34 Book recommendation Brought to you by: • turbopuffer – a vector and full-text search engine built on object storage. It’s fast, cheap, and extremely scalable. • Antithesis – verify your system’s correctness without human review or traditional integration tests – and avoid bugs or outages. • Entire – every agent prompt, tool call, stored in your repo, and mirrored. Set up with one click: Hope you enjoy this unusually visual episode - thanks again, Maggie!
Gergely Orosz68,140 просмотров • 25 дней назад
On Bending Spoons: I still think about when they bought Evernote in 2023, it had user data stored on 750 manually provisioned (!!) VMs on GCP, sharded, with ongoing performance + reliability issues, running a Java 11 monolith (!!!) Then they went ahead and fixed it in ~6 months
Gergely Orosz187,808 просмотров • 2 месяцев назад
What does it mean for software engineering when we no longer write the code? Here's the take from Boris Cherny (Boris Cherny), the creator of Claude Code. Timestamps: 00:00 Intro 11:15 Lessons from Meta 19:46 Joining Anthropic 23:08 The origins of Claude Code 32:55 Boris's Claude Code workflow 36:27 Parallel agents 40:25 Code reviews 47:18 Claude Code's architecture 52:38 Permissions and sandboxing 55:05 Engineering culture at Anthropic 1:05:15 Claude Cowork 1:12:48 Observability and privacy 1:14:45 Agent swarms 1:21:16 LLMs and the printing press analogy 1:30:16 Standout engineer archetypes 1:32:12 What skills still matter for engineers 1:35:24 Book recommendations Brought to you by: • Statsig — The unified platform for flags, analytics, experiments, and more. • Sonar – The makers of SonarQube, the industry standard for automated code review. Proactively find and fix issues in real-time with the SonarQube MCP Server: • WorkOS – Everything you need to make your app enterprise ready. Three interesting things from this conversation: 1. Boris automated himself out of code review well before AI. Boris was one of the most prolific code reviewers at Meta company. And he worked hard to minimize time spent on code review. His system::every time he left the same kind of review comment, he logged it in a spreadsheet. Once a pattern hit 3-4 occurrences, he’d write a lint rule to automate it away! 2. PRDs are dead on the Claude Code team: prototypes replaced them. Instead of writing Product Requirement Documents (specs), they build hundreds of working prototypes before shipping a feature. Boris: “There’s just no way we could have shipped this if we started with static mocks and Figma or if we started with a PRD.” 3. This is the year of the generalist (and maybe the year of those with ADHD) Boris’s work has shifted from deep-focus single-threaded coding to managing multiple parallel agents and context-switching rapidly. As Boris put it: “It’s not so much about deep work, it’s about how good I am at context switching and jumping across multiple different contexts very quickly.”
Gergely Orosz491,428 просмотров • 7 месяцев назад
If you use Codex, Tibo needs no introduction. We talked 100% about Codex (fun fact: he started building it!), and 0% about resets. Timestamps: 00:00 Intro 07:21 Working at Google 12:41 What drew Tibo to OpenAI 15:19 The early days of Codex 18:20 Why Codex was built in Rust 21:15 Why Codex is open source 25:50 Codex plays nice with other models: why? 32:09 How the harness works 36:44 Harness and model improvements 41:19 The SDLC behind Codex 46:39 Code reviews at Codex 52:09 Maintenance and architecture 56:43 How AI tools expand what engineers can do 1:02:30 The Merge: ChatGPT + Codex 1:07:16 How Tibo uses Codex and ChatGPT 1:10:44 Advice for engineers who want to work in AI Brought to you by: • turbopuffer – a vector and full-text search engine built on object storage. It’s fast, cheap, and extremely scalable. • Antithesis – verify your system’s correctness without human review or traditional integration tests – and avoid bugs or outages. • Entire – Git hosting, rebuilt for the agentic era. Entire hosts your code in-region, and is up to 89x faster than any other competitor. Oh, and to those still reading and wondering about resets: there was one yesterday already 😅
Gergely Orosz81,483 просмотров • 1 месяц назад
Few people care more about software performance than Casey Muratori. Give him a few minutes of your attention with this episode, and he'll convince you to learn to read Assembly (no, really, I finally started to read it, it's really not that scary, esp with an AI that can help explain the sequences). Timestamps: 00:00 Intro 05:17 Games at Microsoft 12:52 Building games 16:00 Why performance matters 27:12 Why you should learn to read assembly 30:36 Designing for optimization 42:51 How to get better at writing performant software 49:04 Understanding how the CPU works 55:53 Building games then and now 1:05:56 How game engines changed building games 1:10:48 Why new games compete with old games 1:13:25 GTA 6: why is it taking so long? 1:16:59 Casey's critique of clean code 1:21:48 Casey's take on TDD 1:24:30 What is good code? 1:27:32 What makes a good software engineer? 1:33:56 Why Casey doesn't code with AI 1:39:01 AI's impact on the game industry 1:44:43 AI and burnout 1:50:21 Why you should read papers Brought to you by: • Antithesis – verify your system’s correctness without human review or traditional integration tests – and avoid bugs or outages • Sentry – application monitoring software considered “not bad” by millions of developers • turbopuffer – a vector and full-text search engine built on object storage. It’s fast, cheap, and extremely scalable Three interesting things we talked about: 1. Is performance starting to matter to businesses? Enterprise software buyers care mainly about cost, compliance, and capabilities – but not performance. Even so, there are some products gaining major popularity and market share due to their performance, such as File Pilot (next-gen file explorer) and the Blick video editor. Is the tide turning? 2. Profiler-driven performance optimization is the wrong way to optimize The standard way of optimizing is to profile the application, tweak hotspots, then check if the stats have improved. But this only finds a local minimum; Casey says every engineer he’s worked with who was a great “optimizer” began by establishing what the hardware could theoretically do, and then did not stop until they’d closed the gap to that performance level. 3. Take a grain of salt with conventional wisdom that premature optimization is the “root of all evil” Many devs use it as an excuse to delay performance optimization, but Casey says that not optimizing in time could mean that only performance hotspots can be fixed later, and not the architectural issues that create poor performance. Architect your system to be performant, or you’ll have trouble solving problems without a rewrite!
Gergely Orosz98,888 просмотров • 1 месяц назад
Just six months ago, DHH (creator of Ruby on Rails and Omarchy) said how he doesn’t really use AI tools to write code, because they are not good enough. Things have changed, a lot. Timestamps: 00:00 Intro 02:11 Omarchy and Ruby on Rails 08:25 37signals overview 10:12 Launching HEY 18:38 Building HEY 22:47 Designers at 37signals 28:08 The craft of design 31:52 Why DHH now embraces AI workflows 39:45 The AI inflection point 44:23 DHH’s agent-first workflow 55:09 AI’s impact on junior developers 1:03:08 Developer experience with AI 1:16:43 What does AI mean for developers? 1:23:33 37signals teams and hiring 1:38:20 Work-life balance with AI 1:41:41 Why DHH keeps building 1:45:24 Closing Brought to you by: • Statsig – The unified platform for flags, analytics, experiments, and more. Stop switching between different tools, and have them all in one place. • WorkOS – Everything you need to make your app enterprise ready. WorkOS gives you APIs to ship enterprise features in days. Check out • Sonar – The makers of SonarQube, the industry standard for automated code review. See how SonarQube Advanced Security is empowering the Agent Centric Development Cycle (AC/DC) with new capabilities. Three interesting observations from this conversation: #1 DHH's philosophy on AI has not changed, but the available tools very much have. Autocomplete-style coding assistants were genuinely annoying for experienced developers six months ago. Things changed with the shift from tab-completion to agent harnesses, plus the emergence of powerful models like Opus 4.5 – when agents started producing code which DHH does want to merge with little to no alteration. #2 Beautiful code and products aren’t matters of vanity; they’re signals of correctness. Dipping into philosophy, DHH says: “When something is beautiful, it’s likely to be correct.” He argues that Steve Jobs wanted the inside of a computer to be beautiful because people who care about circuit board layout are also those who sweat on the details of the UI. #3 DHH’s development workflow, today: He runs tmux to have two models running, and neovim in the center. Specifics: - One fast LLM running (typically Gemini 2.5) in one split terminal - A slow but more powerful model in another terminal (usually Opus) - NeoVim for reviewing diffs via Lazygit
Gergely Orosz329,135 просмотров • 6 месяцев назад
Why is the creator of OpenCode pretty skeptical about AI productivity gains, and the hype around AI? A very conversation dax (and lots of truth bombs:) Timestamps: 00:00 Intro 07:03 Dax’s path into tech 09:04 Early startup experience 13:16 Getting involved with open source 16:13 OpenCode 23:17 Anthropic banning OpenCode 30:34 From terminal to GUI 32:34 OpenCode’s business model 36:33 Why inference is profitable 39:11 GPU bottlenecks 40:54 AI hype 45:50 AI spending 48:47 Dax’s memo 55:41 Dax’s skepticism of predictions 58:58 Engineering culture at OpenCode 1:02:38 How building works at OpenCode 1:05:36 Taste and quality 1:11:32 Dax’s work setup 1:12:35 The role of engineers and EMs 1:15:50 Advice for engineers 1:18:12 Book recommendation Brought to you by: • Antithesis – verify your system’s correctness without human review or traditional integration tests – and avoid bugs or outages • WorkOS – everything you need to make your app enterprise ready • turbopuffer – a vector and full-text search engine built on object storage. It’s fast, cheap, and extremely scalable Three interesting thoughts from Dax: 1. No AI-native coding agent company is “winning” by being better with AI. Dax says that none of OpenCode’s competitors are crushing them, and that nobody is using AI so well that others cannot compete. 2. Most software engineers profit from AI as time gained, not increased output — unless you change incentives! Dax says the natural way for software engineers to “cash out” their AI tooling gains is with time savings, by doing the same work as before, but faster. Until compensation and motivation structures change, most teams should expect output to stay flat while engineers go home earlier. There’s nothing wrong with this, but AI vendors sell a different outcome to CFOs: increased output. 3. AI code generation mutes the “guilt” of doing the wrong thing, but this builds up tech debt. Pre-AI, writing a hack felt bad, the second time it felt really bad, and by the third time you’d often just refactor in order to fix up the code. Now, the agent hides the hack, which skews devs’ judgment and results in less tech debt being cleaned up.
Gergely Orosz232,386 просмотров • 4 месяцев назад
When does it still make sense to use microservices, what are mental models to keep in mind when building resilient distributed systems, and how is much of the tech world fundamentally misunderstanding AI? With Sam Newman. Timestamps: 00:00 Intro 03:16 Sam’s path into tech 09:32 Thoughtworks 20:55 The rise of microservices 33:37 Are specs becoming more important than code? 45:22 Building Resilient Distributed Systems (Sam’s new book) 52:35 Three rules of distributed systems 56:16 Observability 1:02:20 Resilience tradeoffs 1:07:54 Idempotency 1:15:58 Thundering herds 1:21:03 Business context and resilience decisions 1:25:51 Resilience engineering: four concepts 1:32:42 AI and resilience 1:36:26 AI’s limitations and where to use it 1:40:06 Cognitive debt and cognitive surrender 1:45:02 Modular architecture and AI software factories 1:51:53 Resources for learning software architecture 1:55:30 Where to find Sam Brought to you by: turbopuffer - – vector and full-text search built on object storage: fast, 10x cheaper, and extremely scalable. Under the hood, the team are rewriting the tpuf storage engine. Follow along until it hits prod: Entire - Git hosting, rebuilt for the agentic era. Entire hosts your code in-region, and is up to 89x faster than any other competitor. Mirror from GitHub with a single click – I’ve already done so. Antithesis - Get a free introduction to property-based testing: through a rare, live webinar hosted by Hillel , author of Logic for Programmers. RSVP here: So, what does much of the tech world misunderstand about LLMs? Sam says: “I think the tech world in general is quite naive about AI and fundamentally misunderstands what an LLM is. For example: why did the LLM delete my database? Well, because it has no concept of causality. They have no concept that if I do A, B happens. LLMs are not world models. World models have been around for a long time. They predate LLMs. So if you had the appropriate model and the appropriate inputs, world models could at least get to the point of ‘if I do X, then Y happens and I’ve been told not to do Y.’ I think we expect LLMs to do more than they actually can do, because they seem so smart. This leads us to overestimate their capabilities a bit too much. But the nature of LLMs is why all the guardrails around LLMs are really not going to be the right long-term solution.”
Gergely Orosz21,480 просмотров • 11 дней назад
OpenClaw - the agentic software spreading like wildfire - was built on top of Pi, a minimalist, self-modifying agent. I sat down with Pi's creator, Mario Zechner and longtime Pi user (+ the creator of Flask) Armin Ronacher ⇌ to talk Pi, and their (very grounded!) takes on building with AI. Timestamps: 00:00 Intro 07:30 How Mario, Armin, and Peter Steinberger met 15:15 How 30 dev teams use AI agents: learnings 21:50 The importance of judgment 24:26 Challenges when non-engineers write code 28:30 Downsides of over-automation 32:18 Pi 48:09 OpenClaw + Pi 50:54 “Clankers” 57:32 Open source and AI 1:00:22 Complexity as the enemy 1:02:50 Building an AI-native startup 1:11:52 “Slow the F down” 1:16:40 MCPs vs. CLI 1:25:03 Predictions and staying up to date • YouTube: • Spotify: • Apple: Brought to you by: • Statsig – The unified platform for flags, analytics, experiments, and more. • Sonar — The makers of SonarQube, the industry standard for code verification and automated code review. Try it out for yourself. • WorkOS – WorkOS gives you APIs to ship enterprise features – SSO, directory sync, RBAC, audit logs – in days, not months. Visit learn more. --- Three parts I found especially interesting in this discussion: 1. New trend: AI makes it harder for senior engineers to reject pointless complexity. Historically, senior engineers kept software complexity at bay simply by saying “no” a lot. But Armin observes that these days, more junior engineers and product managers deploy agent-scripted counterarguments when a senior colleague kicks an idea to the curb. This makes decision-making exhausting, and more bad ideas make it into production as a result. 2. It should be MUCH easier to build specialized tools for specific tasks. Different projects need different harness types because, as Mario points out, the same hammer is not ideal for every single construction job. As such, Pi is built with the goal of allowing the creation of specialized harnesses. It can modify itself so that a user can create the bespoke harness needed for any task. Mario believes it’s a preview of how self-modifiable software might look in the future. 3. Automation bias is one of the biggest risks of working with AI agents. Once devs confirm that an AI agent can produce acceptable code, they start to review its output less often, even though agents can – and do! – produce slop. Mario advises being far more sceptical with agents, and cautions that the quality of their output isn’t guaranteed, however well they performed previously.
Gergely Orosz173,334 просмотров • 5 месяцев назад
No project has gotten more traction in such a short time than by Peter Steinberger 🦞 But how is he building it? Watch or listen: • YouTube: • Spotify: • Apple: Brought to you by: • Statsig — The unified platform for flags, analytics, experiments, and more. Join us at The Pragmatic Summit I’m hosting with Statsig, on 11 February: • Sonar – The makers of SonarQube, the industry standard for automated code review. Join me online at the Sonar Summit, on 3rd March: • WorkOS – Everything you need to make your app enterprise ready. If you're in SF on 9 February, stop by at the WorkOS AI Night with The Pragmatic Engineer (free to register):
Gergely Orosz225,804 просмотров • 8 месяцев назад
Anders Hejlsberg (Anders Hejlsberg) is a living legend: he created Turbo Pascal, Delphi, C# and TypeScript (and today TypeScript is the most-used programming language, globally, as per GitHub.) Timestamps: 00:00 Intro 02:48 How Anders got into programming 05:40 Building his first compiler 07:44 Turbo Pascal 12:25 Delphi 14:53 Joining Microsoft 19:41 Building C# 29:11 Async/await 34:01 The rise of JavaScript 37:52 Building TypeScript 42:58 How the TypeScript compiler works 48:30 JavaScript’s strengths and weaknesses 52:18 How Anders uses AI 56:03 What language features work well with AI 1:02:49 How software craftsmanship is changing 1:07:49 Performance and efficiency 1:09:29 Anders’ tool stack 1:11:30 A 30-year career at Microsoft 1:13:40 Book recommendation Brought to you by: Antithesis – verify your system’s correctness without human review or traditional integration tests – and avoid bugs or outages. WorkOS – Everything you need to make your app enterprise ready. turbopuffer – a vector and full-text search engine built on object storage. It’s fast, cheap, and extremely scalable. Four things that stood out to me: 1. “10x better for 1/10th of the price” is a proven winner. This is what Turbo Pascal did: it sold for $49.95 when competing compilers cost $500, and it was faster and more interactive than competitors’ products. Conveniently, the low price tag also killed off piracy 2. C# might have not existed without a famous court case. Microsoft originally hired Anders to architect its Java tools (Visual J++), but the Sun versus Microsoft lawsuit (1997-2001) meant Microsoft could not build on top of Java, as the company that owned Java’s IP (Sun) sued MS for alleged unauthorized changes to the Java language. Microsoft realized it had to build a new language that combined VB’s productivity with C++’s power. This led to C# and .NET. 3. TypeScript exists because Anders refused to build Script# for the Outlook .com team. Microsoft’s Outlook .com team asked Anders’ C# team to productize “ScriptSharp,” a language to cross-compile C# to JavaScript. Anders and the C# team pushed back, suggesting that a better approach was to fix JavaScript. Anders felt strongly that to be attractive to the best-of-breed developers in the JavaScript ecosystem, you want people to write JavaScript, and not another language like C#. 4. Designing a programming language is a 10-year play. As Anders puts it: “Version one is great, but has all sorts of issues. You’ve got to do version two, but it’s not until version three that it really starts to be great. Then you’ve got to convince people to adopt it.”
Gergely Orosz129,757 просмотров • 5 месяцев назад
Chris Lattner (Chris Lattner) is one of the most influential engineers of the past two decades. He created LLVM, Swift, contributed to TensorFlow, and created the Mojo programming language. What was the story about creating Swift - and why did he face resistance inside Apple when wanting to replace Objective C? What did he learn at Tesla, Google and CPU maker SiFive, that led him to working on Mojo at Modular? We cover these and many more in today's episode. Watch or listen: • YouTube: • Spotify: • Apple: Brought to you by: • Statsig — The unified platform for flags, analytics, experiments, and more. • Linear – The system for modern product development. My favorite quote from Chris in this episode: “I believe in the power of programmers. I believe in the human potential of people that want to create things. And that’s fundamentally why I love software is that you can create anything that you can imagine.”
Gergely Orosz206,271 просмотров • 11 месяцев назад
Knowing how LLM contexts work and how to work around context limitations – aka “context engineering” – is becoming so important. No better person to explain than dex Timestamps: 00:00 Intro 01:33 Dex’s path into tech 03:34 Early work in platform engineering 05:28 Replicated 11:24 Metalytics 12:36 12-factor agents 18:27 Context engineering 23:38 Harness engineering 26:11 Context overload 30:45 Loop engineering 44:34 Software factories before and after AI 50:33 Automation limits 55:18 Three options for automating 59:00 RPI framework 1:04:16 Intentional compaction 1:11:48 Token harder vs. token smarter 1:16:44 AI slop 1:19:15 HumanLayer 1:29:09 Book recommendation Brought to you by: • Antithesis — with Antithesis, you can use AI agents to work on critical systems without worrying about correctness. Teams like Jane Street, and the etcd community use Antithesis to ship better code, faster. • Buildkite — the CI orchestration platform built for reliable scale. Used by OpenAI, Anthropic, Cursor, Meta, Uber, Ramp, Nvidia, Airbnb and many more. • Sentry — application monitoring software built by developers, for developers. Check out their AI agent, Seer AI, and Sentry MCP. Three interesting learnings from this episode: 1. Lesson learned: Shipping unread code spells disaster within months. Dex experimented with having the model write the code and humans not reviewing anything in July 2025. Four months later, they shut things down and threw the whole system out. Production broke, and no matter how much the team prompted Opus 4.1, the model could not find the root cause. Once fixed, it took three weeks (!!) to re-onboard to a codebase no human had ever read 2. Context engineering 101: figure out where the “dumb zone” begins. As a rule of thumb, the less of the context window that is used, the better the outcomes are. This is because the attention mechanism is quadratic: the more that goes into the context window, the more compute is required to process it all. 3. “You’re completely right!” or “you’re right to push back on that” are phrases that mean it’s time to start a new session. These responses mean the LLM session is trajectory-poisoned, and you’re wasting time and tokens to continue. This is because models are autoregressive.
Gergely Orosz64,489 просмотров • 3 месяцев назад
How did a tiny team of 30 engineers build WhatsApp, more than a decade ago? From Jean Lee, engineer #19 at the company. Timestamps: 00:00 Intro 01:39 Early years in tech 06:18 Becoming engineer #19 at WhatsApp 13:53 WhatsApp’s tech stack 18:09 WhatsApp’s unique ways of working 25:27 Countdown displays and outages 27:07 Why WhatsApp won 28:53 The Facebook acquisition 33:13 Life after acquisition 39:27 Working at Facebook in London 44:07 Transitioning to management 47:27 Performance reviews as a manager 53:29 After Facebook 58:53 AI’s impact on engineering 1:02:34 Jean’s advice to new grads and startups 1:06:45 Empowering employees 1:08:17 Book recommendations Watch or listen: • YouTube: • Spotify: • Apple: Brought to you by: • Statsig – The unified platform for flags, analytics, experiments, and more. • Sonar – The makers of SonarQube, the industry standard for automated code review. • WorkOS – Everything you need to make your app enterprise ready Three interesting observations from this episode: 1. WhatsApp had no code reviews after in-place. WhatsApp cofounder, Brian Acton, reviewed the very first pull request of each new hire, and after that, there were no more code reviews. Jean recounts how Brian reviewed her debut PR in extreme detail. This first (and only!) review set the bar high, and she wrote code to that standard from then on. 2. WhatsApp had close to zero formal processes. WhatsApp had no Scrum, no Agile, no TDD (test driven development), and no formal code reviews beyond the first commit. In contrast, Skype had 1,000 engineers and mandatory Scrum training, but WhatsApp still outcompeted it and won. Jean’s response to hearing of all the formal processes Skype used in order to execute faster: “I’m surprised to hear they thought they were shipping faster because of it.” Perhaps process is often a substitute for trust, not quality?” 3. Saying “no” to features was a competitive advantage. WhatsApp’s CEO, Jan Koum, rejected 99% of feature requests from the team. While competitors shipped dozens of shiny, new features, WhatsApp ruthlessly prioritized reliability and simplicity. Jan repeatedly told the team what the mission was. “I want a grandma living in the countryside to be able to use our app”, he said.
Gergely Orosz112,027 просмотров • 7 месяцев назад
How is the world's largest storage system, AWS S3 built? I found the best person to talk about this: Mai-Lan Tomsen Bukovec, who has been heading up S3 for 13 years (!) S3's scale is something else (tens of millions of hard drives, eleven 9s of durability (!!) and heavy usage of formal methods, microservices dedicated to durability, amongst others.) Watch or listen: • YouTube: • Spotify: • Apple: Brought to you by: • Statsig — The unified platform for flags, analytics, experiments, and more. • Sonar – The makers of SonarQube, the industry standard for automated code review. Check out their latest State of Code Developer Survey report: • WorkOS – Everything you need to make your app enterprise ready.
Gergely Orosz134,110 просмотров • 9 месяцев назад
How have the fundamentals of building large, distributed software systems changed the last decade? A conversation with Martin Kleppmann (author of Designing Data-Intensive Applications) - given that the second, updated edition of the book was just released. Timestamps: 00:00 Early career 05:46 Building Rapportive 10:47 Working at LinkedIn 14:09 Writing Designing Data-Intensive Applications 23:00 Reliability, scalability, and repeatability 26:24 DDIA: the second edition 30:50 Tradeoffs of using cloud services 39:02 How the cloud changed scaling 42:53 The trouble with distributed systems 49:02 Ethics for software engineers 52:45 Formal verification 1:00:12 Academia vs. industry 1:03:50 Local-first software 1:09:50 Computer science education 1:18:32 Martin’s current research and advice Brought to you by: • Statsig – The unified platform for flags, analytics, experiments, and more. • Sonar – The makers of SonarQube, the industry standard for code verification and automated code review. Check out Sonar's new architecture management capabilities that ensure both humans and AI agents respect your system’s blueprint. • WorkOS – Ship enterprise features – SSO, directory sync, RBAC, audit logs – in days, not months. Three things worth considering, as discussed with Martin, in this episode: 1. Multi-region and multi-cloud are risk/cost trade-offs, not best practices. Martin does not believe that there is a “best practice” in deciding whether to go multi-region or multi-cloud. This decision is a tradeoff between risk and costs. It’s a business decision to be made. Designing Data-Intensive Applications gives engineers the vocabulary to articulate the tradeoffs, not to dictate answers. 2. Replication for fault tolerance is more relevant for most engineers these days than sharding. Though the book has a full chapter on sharding, Martin said that the cloud has reduced the need for manual sharding for the majority of teams. This is also because machines are increasingly bigger, and more workloads fit on a single machine. Sharding across machines is increasingly a specialist concern; replication for fault tolerance, however, is still relevant at every scale. 3. Knowing system internals as a superpower for application developers. Martin maintains that Designing Data-Intensive Applications is not a book for people who build databases or even infrastructure, but it’s helpful for application developers to develop an intuition for making good design decisions and debugging performance issues we will eventually encounter.
Gergely Orosz79,406 просмотров • 5 месяцев назад