The Pragmatic Engineer
@Pragmatic_Eng • 48,173 subscribers
Big Tech and startups, from the inside. The #1 technology newsletter on Substack. Sign up at https://t.co/MPNdQSVnwV. Podcast: https://t.co/nVOulBGYoh
Shorts
Videos
What it’s like to receive a job offer directly from Satya Nadella. Kelsey Hightower, former Google Distinguished Engineer, on the Microsoft offer that revealed a pay tier he didn't know existed: “I got this email from Satya, the CEO of Microsoft. He wrote this nice email: 'Kelsey, heard you had a good experience with the team' - remember I did the interview at the Microsoft headquarters - “heard really good things from the team, just wanted to let you know, you're going to be respected here. We're going to support you as a team.” I'm like, damn, support as a team? Coming from the CEO? So, number one, what an honor. This is the CEO of Microsoft. He has so many more important things to be doing than to be emailing me about a role. I opened the PDF - not very often in your career does a zero get added to the equation. And so you're looking at this like, I didn't even know that they do that. We know that it happens. But the person that graduated from high school in 1999, that chose the A+ Certification didn't know that was available. Even while I was at Google having all the success. Google paid me pretty well too, but I didn't know you can add another zero still. And I'm like, wow. I showed my wife and she was the one that said you should just go interview, like put your ego to the side and let's go see what's out there, so shout out to my wife. And so I get the PDF, and I'm like, okay, this number is perfect. Honestly, I don't know what to say, but let’s just find out, is this really the only number? So I remember giving a counter: you know what, I think it should be this. The funny thing is, Microsoft countered back higher, like we're not playing around. I'm like, oh, whoa. Now I understand that I don't understand this part of the game.”
The Pragmatic Engineer556,044 次观看 • 1 个月前
Author of Designing Data-Intensive Applications, Martin Kleppmann, on why engineers don't get to ignore ethics just because the work is technical — a theme he felt strongly enough about to address in both editions: “I felt that ethics had been quite ignored as a concern during my time in industry. Especially in startups, people were very focused on building a product that their customers would love and deprioritized ethical questions in the process. For example, with consumer facing products, it might be that the products are very much geared towards essentially data harvesting, collecting behavioural data, because that's what can be monetized in the form of advertising. There seemed to be very little reflection on what was good and bad about these sorts of things. I really wanted to encourage a bit of thinking there. I didn’t want to prescribe a particular approach, but to point out there is this thing such as data protection legislation now, which we do have to think about in the architecture of our data systems and there is an ethical responsibility.”
The Pragmatic Engineer783,831 次观看 • 2 个月前
Devs will “cash in” AI gains as time. Dax Raad(dax), creator of OpenCode, on the incentive problem most companies are ignoring: “We forget how big the software engineering industry is. Every company in the world employs software engineers to some degree. The majority of these environments aren't like the most motivating, exciting environments. Most people there are trying to do their job, go home to their kids, have a reasonable life. You give them a button that lets them do their work faster. The natural place for them to go is to hit that button as much as possible, do the same amount of work and just cash in that extra time, right? Which makes total sense. If you have no reason to be above and beyond motivated, you're not going to really use that to push your organization harder. Yeah, these tools may make you more productive, but be really realistic about your employees. Where are they going to cash in those gains? Obviously some companies are not like that. Employees are motivated. They have good reason to be. They're compensated in a way that makes sense, but most places aren't like that. The problem with that is usually in those environments there will be a couple people that are irrationally motivated because they love the work they do, et cetera, even though the rest of the company isn't as motivated. They're usually the ones that are trying to make sure everything is good quality, trying to push everyone to try harder. They're all now overwhelmed by slop PRs. And we've had a few people on our team that have joined and their previous company was like this. They were the person that still cared. The rest of the organization just hits the button and gets their tasks done and they're drowning in just garbage and they're getting burnt out and they're leaving.”
The Pragmatic Engineer315,268 次观看 • 1 个月前
AI agents keep placing “landmines” in the code. Dax Raad(dax), creator of OpenCode, on why the human feedback loop kept code quality high: Dax: "We're shipping way more hacks in places where we should have just rethought the whole system from ground up or redesigned it and refactored it to make it more flexible. So I think our judgment is just off." Gergely: "Does this have to do that when I’m making a hack as an engineer, pre-AI, I know I'm making a hack. I'm thinking about it, I feel bad about it... there's kind of like a little bit of prickle there. Is it just that the agents just do it? They don't have feelings and they also suppress the effort, suppress the thinking.” Dax: "Yeah, exactly. I think the way you put it is exactly right, that prickle, that feeling that you get, it's muted now because it's kind of like you've made someone else deal with the problem. The problem is still there and the landmines are still going to blow up on you eventually, but you don't feel that bad feeling as much anymore. So your judgment is skewed. You're not getting that feedback loop."
The Pragmatic Engineer236,973 次观看 • 1 个月前
OpenCode operates in an AI-native space but, as co-founder Dax Raad(dax) tells us, no one is using AI so well that they’re crushing the competition: “In the past six months, we operated very differently than we ever have. A lot of stuff went wrong because of that. So now we're pulling back and figuring out, okay, what from the old world still makes sense? We're figuring out what we should be doing and I definitely don't feel like, oh yeah, we're killing all our competitors, we're using AI so much better than everyone else. And by the way, none of our competitors are crushing us either. No one out there is using AI so well that we can't even compete. 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 a huge gap, but there just isn't.”
The Pragmatic Engineer211,072 次观看 • 1 个月前
TypeScript was inspired by a strange ask from the outlook team. Anders Hejlsberg(Anders Hejlsberg) - creator of C#, TypeScript, Turbo Pascal & Delphi - tells us how TypeScript was born: “The world started building larger and larger applications in JavaScript. We saw that externally, but also internally. One of the trigger events was when the outlook team came to see the C# team and asked us whether we would pretty please productize this thing called Script#. And we go, well, what is Script#? It's this cross compiler that allows you to cross compile C# into JavaScript such that you can basically treat JavaScript as an instruction language and run your C# apps in a browser. Why would anyone want to do that? Well, because then you can get a grownup programming language with grownup tooling. You can use Visual Studio, you can have projects. You can do all of these wonderful things that you can't do with JavaScript because JavaScript is just the scripting language with shitty tooling. And we thought, well, perhaps a better approach would be to fix JavaScript. I mean, surely you're not going to be best of breed in the JavaScript ecosystem by telling people to write in a different programming language”
The Pragmatic Engineer116,193 次观看 • 1 个月前
In Rust, error handling is opt-out, not opt-in. Alice Ryhl (Rust for Android at Google, Rust language advisor & Tokio maintainer) explains: “The other thing I think is quite good is error handling. So on one hand, Rust doesn't really use exceptions, so it actually returns the error as a value. So you return a value that's, using an enum, either the result or the error. And the way this is done is that there's an operator `?` - so you write: my_function and then a question mark at the end - which means if this function fails, return the error. So it's really easy to handle errors but it's not serial characters like it is with exceptions, so it's explicit. On the other hand, if you forget to put the question mark, that's a compilation error. So you have to check it, and of course you can also have it manually, but the point is it's this idea of there are these things where you write some code and there's some implicit error condition you didn't think of and now you just took down your server or something.”
The Pragmatic Engineer52,059 次观看 • 1 个月前
![Anyone who thinks software engineering is ‘going away’ doesn’t understand the job. Kent Beck 🌻, creator of XP and TDD, on why Dario has it wrong: [Gergely: Dario said, I quote, ‘coding is going away first, then all of software engineering’. ] “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, even if it takes up a fair amount of time. You're building confidence, you're building connections with other people, you’re building your own understanding. All those things are happening while you're coding. And coding's actually a great way to cement understanding. The more you program, the more you understand the domain that you're working in. And so to say, well, we're just going to pass all that off to a machine. Well, that's not all there is to it. A couple of days ago I saw a phrase, and it really hit me, that we're accumulating code faster than we're accumulating trust now. And that sense of trust comes from me struggling to understand some domain concept, ah, I get it! I represented it in the code. I write tests that demonstrate that I really did understand it and now, I trust my program. If we're programming together, that act of programming together means that we trust each other more. And none of that can be automated. None of that occurs. If we prompt, we get the finger guns, the genie goes, yeah, it's all finished, boss. And it is like, well, hang on, finished. What's finished?”](https://image.24vids.com/tw-2072667110380122433/ext_tw_video_thumb/2072666701913567232/pu/img/LSn2x7T0Y5Grrsgs.jpg)
Anyone who thinks software engineering is ‘going away’ doesn’t understand the job. Kent Beck 🌻, creator of XP and TDD, on why Dario has it wrong: [Gergely: Dario said, I quote, ‘coding is going away first, then all of software engineering’. ] “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, even if it takes up a fair amount of time. You're building confidence, you're building connections with other people, you’re building your own understanding. All those things are happening while you're coding. And coding's actually a great way to cement understanding. The more you program, the more you understand the domain that you're working in. And so to say, well, we're just going to pass all that off to a machine. Well, that's not all there is to it. A couple of days ago I saw a phrase, and it really hit me, that we're accumulating code faster than we're accumulating trust now. And that sense of trust comes from me struggling to understand some domain concept, ah, I get it! I represented it in the code. I write tests that demonstrate that I really did understand it and now, I trust my program. If we're programming together, that act of programming together means that we trust each other more. And none of that can be automated. None of that occurs. If we prompt, we get the finger guns, the genie goes, yeah, it's all finished, boss. And it is like, well, hang on, finished. What's finished?”
The Pragmatic Engineer20,322 次观看 • 20 天前
Pi was built when there were already agent harnesses around. Here’s why Mario Zechner(Mario Zechner), found them suboptimal and built Pi, a minimalist self-modifying agent: #1 - Mario initially was a believer in Claude Code: "I was a believer in Claude code because they were the first that packaged agentic search up in a really compelling package. And at the time that fit my workflow really well. Everything around the LLM was kind of nice and tidy and easy to understand. I was super happy. I was proselytising Claude code." #2 - Reverse engineering Claude Code highlighted the degradation that Mario felt as a user: "I personally like simple tools that are stable and that I can rely on. Even if they have non-deterministic parts, all the deterministic parts should be as stable as possible. That was just not the experience with Claude Code around summer 2025. They would take away your control of the context. They would inject stuff behind your back, which is bad. Then, your workflows stopped working because there's now a system reminder that you don't even see in the UI that would modify the behaviour of the model. They would also do this to the system prompt. I built a little service where I can track the progression or evolution of the system, prompt and tool definitions and, with every release, it was messing with stuff. That just messed with my workflows and I don't appreciate that." #3 - PI was built with an appreciation for simple and reliable tools: "If I commit to a development tool, I want it to be a stable, reliable thing like a hammer. I don't want my hammer to break a different spot every day. That's terrible. We need somebody who goes the full velocity kind of way. But I don't want to work with a tool like that."
The Pragmatic Engineer62,825 次观看 • 2 个月前
![How Jan Koum (WhatsApp cofounder and CEO) operated: "Jan said no a lot. Almost 99% of the time, he would say 'no.' As a young engineer, I was very confused. Because when you look at all these other apps, like WeChat, is notorious for having everything, right? They have so many features. And I was so confused: why don't we build all these features? These are the newest, coolest things that we should have. All the cool features were missing, in my mind. And that was by design. Because what we really wanted to prioritize was the quality of [the experience of] a grandma in a remote town being able to use our app at any given time."](https://image.24vids.com/tw-2037285099658424683/amplify_video_thumb/2037283290730708993/img/HUxZr-T_mk8NUxGI.jpg)
How Jan Koum (WhatsApp cofounder and CEO) operated: "Jan said no a lot. Almost 99% of the time, he would say 'no.' As a young engineer, I was very confused. Because when you look at all these other apps, like WeChat, is notorious for having everything, right? They have so many features. And I was so confused: why don't we build all these features? These are the newest, coolest things that we should have. All the cool features were missing, in my mind. And that was by design. Because what we really wanted to prioritize was the quality of [the experience of] a grandma in a remote town being able to use our app at any given time."
The Pragmatic Engineer88,362 次观看 • 3 个月前
Why did Uber have 5,000+ microservices, a few years into the company being started? Thuan Pham, Uber's first CTO, who oversaw this massive boom: "None of us wanted to go through that extreme of thousands of services. But when you are under a lot of pressure, and no time to react other than just survive to scale, you have to make a decision that increases speed and velocity! Because this speed and velocity allows us to build things quickly enough to survive. We knew that backend (called "API" at the time), a monolith: this will prevent speedy development from happening. So we made a declaration: anything that is NEW needs to be built outside of that (the "API"), as a microservice. Then there's a team that's dedicated to decomposing that monolith into a bunch of services. This project (to decompose the monolith) was called Darwin. The philosophy we operated with, at the time, was that no team should be blocking anybody else. (...) So that's how it came up to thousands of microservices. It was out of necessity ,so that we can just fan out and solve every problem all at once. After things stabilized and the business became more mature, and growth was not as violent as that anymore, then the team, we actually had a project called Arc, to rationalize services."
The Pragmatic Engineer68,272 次观看 • 3 个月前
AI is changing the software engineering craft. Anders Hejlsberg (Anders Hejlsberg) - creator of C#, TypeScript and industry legend - on why code review needs to get more enjoyable in response: #1 - AI is shifting the craft from writing code, to reviewing code: "In a sense, we're all turning into project managers. We can have an army of junior programmers, called agents, that will just spit out reams of code but someone's got to have the big picture and review all of that. And so, increasingly, our craft is going from one of writing the code, to one of reviewing the code and building the architecture of the code and overseeing the work. It's a different kind of craft. It's a different kind of enjoyment. I've always liked writing the code. To me that was the fulfilling part, seeing it work. In a way, AI robs a little bit of that, because I am less interested in reviewing code." #2 - The code review experience should be improved: "I think we could also make the process of reviewing code much more interesting than it is today. I mean, today, you see a list of diffs in alphabetical order and now it's up to you to make heads or tails of it. There are more pedagogical ways of presenting that. And you could have commentary generated by the AI that tells you what the changes are and whatever, and then tries to guide you along. So that symbiotic relationship, I think we need to work on that more and to keep the enjoyment in there."
The Pragmatic Engineer39,011 次观看 • 2 个月前
Author of Designing Data-Intensive Applications, Martin Kleppmann, gives us a peek into "The Troubles with Distributed Systems" and why you can't assume things behave well in distributed systems: "The whole idea is that in distributed system theory, there are certain things that we tend to assume. For example, we just assume that there's no upper bound on how long it might take for a message to go over the network. So when you send a message, it might arrive within a hundred microseconds, or it might take 10 years, and distributed system theory just doesn't make any assumptions about that sort of timing if we can avoid it. Or rather, some theory does make those assumptions, but it's a dangerous assumption to make because occasionally the network delay does become much higher than what is typical. Another thing is about crashes. Distributed system theory just says nodes can crash, but what does that actually mean? What in practice does it mean for a node to become unavailable? Because it might be a software crash, but it might be a hardware failure. It might be somebody unplugging the power cable. It might be that the node is actually still running, but it's just become disconnected from the network. And so, the point of this book chapter really is to defend and justify the theoretical models that we use for analysing distributed systems and to give a lot of stories and case studies to show that, actually, tonnes of stuff does go wrong. Don't believe anyone who says, 'Oh, failures are rare. Don't worry about it. It's fine’. Actually, no. If you want to make things reliable, you really do have to worry about a whole bunch of weird, unusual, but certainly possible edge cases. Timing is another one of those things. It's very easy to assume that your clocks are correct, and most of the time the clocks are pretty correct, but we just can't rely on it because actually they're just not precise enough on the whole. It's very tempting to make certain assumptions that things are well behaved and in distributed systems, we just have to try to get away from those assumptions if we want the systems to work reliably, even in the face of things going wrong."
The Pragmatic Engineer50,567 次观看 • 3 个月前
Whoa: WhatsApp grew to 450M monthly users with no code reviews in place. Jean Lee, engineer #19 at the company: "WhatsApp was the ultimate lean company. By the time we were acquired by Meta, we only had fewer than 30 engineers serving 450 million monthly active users. We didn't have code reviews. The only time I got my code reviewed was the first time I made a commit. Brian asked to take a look at it before I committed it, and he asked me a bunch of questions, which I had to think through a lot, but that was it. After this first time, we didn't really have a formal code review. Everyone was trusted. All engineers just pushed their code to production without a review. It was trusted that they would ask if they were unsure."
The Pragmatic Engineer45,175 次观看 • 3 个月前
Old software engineering patterns are coming back because of coding agents. Dax Raad(dax), co-founder of AI coding agent OpenCode, on why DDD is becoming more relevant and less painful: “I think it's the same problem as always, which is how do you make code bases that are easy to work in, scalable, that can flex to new requirements. A lot of the old patterns for me are coming back. We've always been a big domain-driven design company. We did it in a very light way. We're now doing it in a much heavier way because we find that these, kind of boring, enterprisey patterns end up being pretty useful because you have a bunch of idiots on your team now. Coding agents are a bunch of idiots. They are going to work 24/7 and they're going to ship a lot of stuff so you need way more guardrails than you used to. What's nice is some of these old patterns we hated because they were very verbose, they produced reliable code that was modular and safe but they were very verbose and annoying to type out… you're not typing it out anymore. Now you can get the benefits of these patterns without the downsides."
The Pragmatic Engineer20,866 次观看 • 1 个月前
Here’s DHH (Creator of Ruby on Rails & Omarchy, cofounder of 37 Signals) on why using AI agents does not feel like being a Project Manager: “When I was on that Lex interview last summer, I was saying: I don't want to be a project manager for agents because I had the mental model of a project manager of humans, and that's not what I enjoy. I don't want to be that far away from the production. I want to be in the mix. I want to have my hands in the code. What I failed to realise at the time was that running a bunch of agents feels less like being a project manager for agents and more like stepping into this super mech suit, where suddenly I don't just have two arms, I have 12. I can now look at seven screens at the same time, running five keyboards. I'm still the one doing it, even if I'm not typing ‘this’ as a keyword in a program. I have been hyper accelerated as a programmer. It's a different kind of programmer, but it still has the same affinity to aesthetics, at least when I'm producing Ruby code, and I'm able to combine that while being vastly more productive on a bunch of things.”
The Pragmatic Engineer29,308 次观看 • 3 个月前
Why did so many languages copy async/await from C#? Anders Hejlsberg(Anders Hejlsberg) - creator of TypeScript, C# & Turbo Pascal - on what they got right with the design: #1 - async/await was designed to solve a common problem in the event-loop model: "A lot of languages are built around cooperative multitasking in the sense that they have an event loop that sits and dispatches events. Then you handle the event and then you yield back to the event handler loop. And it all runs in a single thread cooperatively. The problem with that is if you then want to do some long running work: how do I stop in the middle of this piece of long running work and yield back to the event loop cooperatively? And then when my result is ready, I can come back and continue executing here." #2 - state machines are the solution, but hard to build: "Well, in order to do that in an inverted architecture like that, you have to build a state machine. State machines are notoriously hard for people to implement because you've got to move all of your state off of the stack into objects. And then you have this big case statement that envelopes your entire logic. It's a nightmare to figure out. But, the transformation from serially executing code into a state machine, its continuation-passing-style translation is actually one that you can do in a machine-based fashion." #3 - compilers are good at writing state machines: "You can have the compiler write the state machine if you introduce syntax that allows you to indicate where you want to yield. And that's what await is. Await is basically saying, I want to yield here, and I want to yield this promise, and then when the promise completes, I want you to come back here and continue executing. Then the compiler writes a state machine around it and it actually turns it into this big switch statement and moves all of the state that survives across the await into something that's heap allocated. So it can be brought back. And doing all of that work is something that compilers are great at. And so that was sort of the idea that we have this new style of programming where we're using promises or the equivalent of promises and the ability to yield and then we have callbacks. But trying to write your program in that style, that's also what JavaScript suffered from a lot. It's like all this callback style stuff. With Async and Await, you get the illusion that you're just writing normal sequential code and then the compiler does the painful transformation for you. That turns out to be really useful."
The Pragmatic Engineer13,258 次观看 • 1 个月前
How Mitchell Hashimoto (Mitchell Hashimoto, creator of Ghostty, founder of HashiCorp) got good at using AI tools for coding + work: "I was forcing myself to figure out how to prompt the agent to produce the same quality result as mine. Even though I was working much slower because it was more than double the work."
The Pragmatic Engineer35,119 次观看 • 4 个月前
Creator of C#, Anders Hejlsberg(Anders Hejlsberg), on the design goals that shaped the language and why standardisation was a goal from the beginning: “The overarching thing was this power and productivity of C++ with the ease of use of Visual Basic. We knew we wanted to build an object oriented language. We wanted managed code or byte code so we could target different runtime environments. We wanted garbage collection and exception handling, but also things like a unified object system where, and that's true in C#, anything can be assigned to an object. If it's a value type, we box it. And it's a self-describing object. So, reflection: you can ask an object, ‘what are you’? And you can get all of the facts about it at runtime, and you can dynamically manipulate it in ways that just don't exist in a lot of other environments. We wanted a language that made this new model of properties, methods and events first class because that was how components were built as opposed to just sort of functions and procedures and even objects. And we wanted to create a language that was standardised. We wanted to give this language to a standardisation committee and try to level the playing field there. And all of those things were sort of like what was rolled up in C#”
The Pragmatic Engineer18,332 次观看 • 2 个月前
Author of Designing Data-Intensive Applications, Martin Kleppmann, on why scaling down is just as challenging as scaling up: “Part of what is interesting about modern cloud services, and backend services in general, is how they've introduced the idea of horizontal scalability and shared nothing systems. We can build systems that are able to cope with very high load, even if the individual components are just fairly cheap commodity machines. The scalability story is not just scaling up, but scaling down as well. How do you run a service in such a way that if it has a very small amount of load, it's really cheap to run? That's sort of the same question as ‘how do you continue running a service if it has a very high load?’ Generally, you want 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. That's not necessarily a given. It's something that is hard with on-premises software because if you've got a physical machine, that is a unit of deployment. Yes, you could carve it up into two dozen virtual machines, but it still requires some sort of resource allocation. And so, part of what's interesting about some serverless systems, is their ability to scale down and say ‘okay, if you're going to handle just three requests per day, that's just fine as well’”.
The Pragmatic Engineer21,239 次观看 • 2 个月前