Gergely Orosz
@GergelyOrosz • 336,731 subscribers
Writing @Pragmatic_Eng, the #1 software engineering newsletter on Substack. Author of @EngGuidebook. Formerly Uber & Skype.
Videos
Kelsey Hightower has one of the most inspiring stories in tech: he went from a technician installing DSL modems, through self-directed study and very hard work, to one of the very few Distinguished Engineer at Google whom Satya Nadella personally persuaded to join Microsoft. Timestamps: 00:00 Intro 03:34 Kelsey’s first job at McDonald’s 05:04 His non-traditional path into tech 11:45 Landing his first tech job with an A+ certification 15:33 His entrepreneurial years 19:45 Joining Google as a data center technician 27:48 Learning automation at a Rackspace spinoff 33:26 Moving into financial services 50:00 Building a reputation through open source 53:55 From configuration management to containers 1:08:20 The rise of Kubernetes 1:25:05 Why he almost joined NASA instead of Google 1:29:20 Defining DevRel at Google 1:38:20 Demonstrating impact at Google 1:41:20 Microsoft's offer 1:55:20 Learning how to slow down 2:06:39 Advising and investing 2:15:03 A people-first view of GenAI 2:24:27 Using AI with guardrails 2:28:26 Matching AI to the task 2:36:06 Staying relevant in the AI era Brought to you by outstanding teams building products I love: • 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 • Buildkite: CI software built to absorb whatever your coding agents throw at the build queue. OpenAI, Anthropic, Uber and others are customers: Three interesting learnings from Kelsey: 1. Side hustles and doing your own thing teach you business like no IC job can. Before becoming a software engineer at Google, Kelsey was a manager for his comedian friend, operated a computer store, and did IT contracting. These gigs taught him logistics, planning, and about money. All this helped him be far more effective at talking with executives and acting as an executive sponsor inside Google. 2. Can you explain what your startup does without mentioning AI? When Kelsey researches startups seeking his advice, he challenges founders to not say “AI” once. This means that they must explain the actual value their company creates. One unexpected benefit of this is that it often reveals there are easier, cheaper ways to achieve a goal than with AI. 3. It’s very rare to get an extra zero put on your compensation figure – but it happened. Kelsey was a successful, well-paid Google engineer when Microsoft made him an offer that 10x’d his salary (!!). When Kelsey told Google he was planning to take the offer, it matched the offer, proving that his market value had massively increased. It shows that being well paid doesn’t necessarily mean you’re being paid at the correct market rate.
Gergely Orosz52,763 Aufrufe • vor 1 Tag
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 Orosz227,094 Aufrufe • vor 9 Tagen
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 Orosz128,169 Aufrufe • vor 22 Tagen
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 Orosz327,463 Aufrufe • vor 1 Monat
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 Orosz488,957 Aufrufe • vor 3 Monaten
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 Orosz171,637 Aufrufe • vor 1 Monat
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,761 Aufrufe • vor 4 Monaten
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,103 Aufrufe • vor 1 Monat
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 Orosz111,437 Aufrufe • vor 2 Monaten
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 Orosz205,995 Aufrufe • vor 7 Monaten
Why did Uber build thousands of microservices? No better person to answer than Uber's first CTO, Thuan Pham. Timestamps: 00:00 Intro 05:32 Getting into tech 16:09 The dot-com bust 20:42 VMware 26:29 Getting hired by Travis at Uber 33:22 Early days at Uber and scaling challenges 40:57 Uber’s China launch 47:12 The platform and program split 50:26 From monolith to microservices 53:38 Internal tools at Uber 57:05 Helix: Uber’s mobile app rewrite 59:55 Thuan’s email about naming 1:02:03 Org structure changes under 1:06:34 Thuan’s work philosophy 1:12:23 The “three tours of duty” at Uber 1:15:37 Why Thuan left Uber 1:17:34 Coupang and Nubank 1:21:59 Faire 1:25:31 How Faire uses AI 1:28:24 AI’s impact on software engineering 1:31:09 The role of the CTO 1:35:13 Career advice Brought to you by: • Statsig – The unified platform for flags, analytics, experiments, and more. • WorkOS – Everything you need to make your app enterprise ready. • Sonar – The makers of SonarQube, the industry standard for automated code review. Check out SonarQube Advanced Security: Three interesting parts from this conversation: 1. The program/platform split came before microservices. The concept of cross-functional “program” teams and dedicated “platform” teams became necessary because an org split across backend, frontend and mobile engineers slowed down in execution speed when Uber grew to around 100 engineers. Every feature required negotiating bandwidth across the mobile, backend, and dispatch teams. Thuan, Travis Kalanick, and Jeff Holden literally used color-coded sticky notes with people’s names to reorganize into self-sufficient teams. We cover more about this split in this The Pragmatic Engineer deepdive, The Platform and Program split at Uber: 2. Expect multiple rewrites during hypergrowth. The right architecture depends on how fast a product and company are growing. At Uber, repeated rewrites were common because each one “bought” another window of survival for the company. Thuan’s recommendation is to understand that a rewrite simply means a company is outrunning its existing architecture: this is not necessarily a bad thing! 3. Uber is the only major company that had a “Senior 1” and “Senior 2” level – and Thuan is unapologetic. Thuan introduced the Senior 1 (L5A) and Senior 2 (L5B) levels because the jump from senior (L5) to Staff (L6) became very big, and larger than between previous levels. One problem this split level created was that Uber’s L5B was akin to Google’s and Facebook’s L6/E6. Thuan resisted the title inflation of just renaming L5B to ‘Staff’.
Gergely Orosz69,256 Aufrufe • vor 2 Monaten
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 Orosz133,489 Aufrufe • vor 4 Monaten
What if we're actually in the middle of the third golden age of software engineering? This is what Grady Booch sees happening. If you are anxious about the state of the industry, you want to watch/listen to Grady's longer-term perspective and stories. Watch the full episode here: 00:00 Intro 01:58 The first golden age of software engineering 18:59 The software crisis 33:01 The second golden age of software engineering 42:21 Y2K and the Dotcom crash 45:47 Early AI 47:34 The third golden age of software engineering 51:48 Why software engineers will very much be needed 58:46 Grady responds to Dario Amodei 1:06:54 New skills engineers will need to succeed 1:10:04 Resources for studying complex systems 1:14:33 How to thrive during periods of change 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. Join me online at the Sonar Summit on March 3rd, where I talk about practical tactics for the AI era. • WorkOS – Everything you need to make your app enterprise-ready.
Gergely Orosz86,822 Aufrufe • vor 4 Monaten
How has the day-to-day workflow of Mitchell Hashimoto (Mitchell Hashimoto) changed, thanks to AI tools? Timestamps: 00:00 Intro 07:19 HashiCorp origins 18:22 The 2010s startup scene in SF 23:11 Funding HashiCorp 25:23 The "Hashi stack" 38:28 The open-core pivot 48:08 Taking HashiCorp public 51:58 The almost-VMware acquisition 59:10 Mitchell’s take on AWS, GCP and Azure 01:06:02 AI’s impact on open source 01:07:00 Ghostty 01:19:13 How Mitchell uses AI 01:28:36 Open source + AI 01:31:46 The problem of Git and monorepos 01:39:57 Mitchell’s hiring practices 01:47:52 Mitchell’s AI adoption journey 01:50:41 Advice to future founders 01:55:03 Closing Also on YouTube, Spotify and Apple (see the next tweet) 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. Join me online at the Sonar Summit on March 3rd: • WorkOS – Everything you need to make your app enterprise ready.
Gergely Orosz59,544 Aufrufe • vor 3 Monaten
It's always energizing to do a podcast with Steve Yegge (Steve Yegge, engineer+author, formerly at Amazon+Google, creator of Gas Town). Timestamps: 00:00 Intro 01:43 Steve’s latest projects 02:27 Important blog posts 04:48 Shifts in what engineers need to know 10:46 Steve’s current AI stance 13:23 Steve’s book Vibe Coding 18:25 Layoffs and disruption in tech 31:13 Gas Town 40:10 New ways of working 51:08 The problem of too many people 54:45 Why AI results lag in business 59:57 Gamification and product stickiness 1:04:54 The ‘Bitter Lesson’ explained 1:07:14 The future of software development 1:23:06 Where languages stand 1:24:47 Adapting to change 1:27:32 Steve’s predictions 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 thoughts from Steve that we talked about in this conversation: 1. Reading ability is becoming a blocker for wider AI adoption. Some struggle with walls of text that current AI tools produce, and Steve predicts that in the very near future, most people will program by talking to a visual avatar, not reading terminal output because he observes that five paragraphs is already a lot to read for many devs. 2. What software engineers need to know keeps changing. In the 1990s, any decent software engineer knew Assembly, and today almost no decent developer knows it because Assembly has long been superseded by technical progress. What engineers “need” to know these days is different from the ‘90s and that process continues with AI, changing the parts of the craft that are essential for devs. We grumble about this but that won’t change anything by itself. 3. There’s a “Dracula Effect” where AI-augmented work drains engineers faster than traditional work. This is because AI automates the easy tasks, meaning that engineers are stuck doing high-intensity thinking all day. Steve says you may only get three daily productive hours at max speed, but during that time, you could produce 100x more output than before.
Gergely Orosz38,047 Aufrufe • vor 2 Monaten
Linear is a startup that punches well above its weight in the speed and quality of shipping, and supporting a large number of customers (10,000+ companies) with a small engineering team (25 devs). I sat down with Linear's first engineering manager, Sabin Roman. Our discussion: We covered: • No email. How Linear handles internal communications • Quality. The “goalie” program to address customer concerns and Linear’s zero bug policy • Full remote. How Linear keeps teams connected despite working entirely remotely • Getting stuff done. An in-depth, step-by-step walkthrough of a project at Linear • Creativity + QA. Linear’s focus on quality and creativity over fash shipping • Career ladders. Titles at Linear, Sabin’s learnings from Uber Brought to you thanks to our wonderful sponsors: 🌟LaunchDarkly — a platform for high-velocity engineering teams to release, monitor, and optimize great software 🌟 Sevalla — Deploy anything from preview environments to Docker images 🌟WorkOS — The modern identity platform for B2B SaaS Watch it on: • YouTube: • Spotify: • Apple: • Web:
Gergely Orosz139,252 Aufrufe • vor 1 Jahr
Why did Amazon move from being a monolith, splitting up into services, despite obsessing about response latency? Turns out it was "software physics:" the monolith crossed the 4GB size that could be deployed in one go. Steve Huynh (Steve Huynh) joins me on The Pragmatic Engineer Podcast to talk about this, and many more learnings about being a Principal Engineer at Amazon - the place where being promoted to this level might be more difficult than at other, similarly large companies. Watch or listen: • YouTube: • Spotify: • Apple: Brought to you by: • Statsig — The unified platform for flags, analytics, experiments, and more • Graphite — The AI developer productivity platform • Augment Code — AI coding assistant that pro engineering teams love
Gergely Orosz79,836 Aufrufe • vor 11 Monaten
Why does "vibe coding" not lead to anything productive, for the most part? A great person to answer is Addy Osmani: he has been working on Chrome for 10+ years, and has just published his new book: Beyond Vibe Coding. 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.
Gergely Orosz51,789 Aufrufe • vor 7 Monaten