The Pragmatic Engineer
@Pragmatic_Eng • 46,257 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
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 Aufrufe • vor 1 Monat
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 Engineer115,602 Aufrufe • vor 11 Tagen
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 Aufrufe • vor 12 Tagen
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,574 Aufrufe • vor 5 Tagen
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,545 Aufrufe • vor 1 Monat
![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 Aufrufe • vor 2 Monaten
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,173 Aufrufe • vor 2 Monaten
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,147 Aufrufe • vor 2 Monaten
Good engineers say 'no', a lot. Mario Zechner(Mario Zechner) and Armin Ronacher(Armin Ronacher ⇌) - creators of Pi and Flask - on complexity, agents, and why battle scars matter: Mario - saying ‘no’ keeps complexity down: “A good engineer is an engineer that says ‘no’ a lot, and ‘I don't need this’ a lot, because that keeps complexity down. If you're using agents, the exact opposite happens. You say, yes, I want this and I want this, because I don't have to type it myself. I don’t have to think about it. I just give the little machine a prompt and it'll spit out something that kind of looks like the thing I wanted. Good enough. And that's where all the problems start.” Armin - human-gained battle scars are foundational for teams to say no: “Good engineering is all about knowing the trade-offs that you have to make. I think Cal Henderson once said ‘you do the dumbest solution first until it doesn't work anymore', because there's so much to do that if you actually do the correct solution, you're creating the kind of complexity that kills you at scale. The engineer learns that — but if you don't have that battle scar, it's very hard for you to argue correctly, because it is this learning process that gives you the authority to then convince other engineers in the engineering org that you should be doing it this way.”
The Pragmatic Engineer17,284 Aufrufe • vor 26 Tagen
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,060 Aufrufe • vor 2 Monaten
AI agents don’t feel the pain that humans do. 3 takeaways from Mario Zechner(Mario Zechner), creator of Pi - the minimalist, self-modifying agent that OpenClaw is built on: #1 - Automation bias: agents quickly wow us and win false trust: “There are moments of brilliance in agents where they spit out perfectly fine simple code. As the steering engineer you can look at that and think: ‘Wow, this is amazing. I can just sit back and not care because it's doing the thing how I would do it.’ Two minutes later you have another agent running that spits out the worst, horrible, garbage code, but you might not notice because you have fallen into automation bias and think your agent is doing the job well.” #2 - Humans have a different capacity for learning than agents: “Agents don't learn. You can put as much stuff in your AGENTS.md, build a memory system, but it's not the same type of learning that a human does. Humans are failable as well, but they have some capability of learning.” #3 - Feeling pain is inherently human and drives us to make things well: “Humans feel pain. I think that's one of the defining things about humans. If the pain gets too big, you as a human are incentivized to fix the cause of your pain. In a code base, the cause is usually terrible interfaces and terrible complexity that you want to get rid of because you can no longer maintain that system.”
The Pragmatic Engineer11,237 Aufrufe • vor 1 Monat
Keine weiteren Inhalte verfügbar