Brought to You By: •⁠ Statsig ⁠ — ⁠ The unified platform for flags, analytics, experiments, and more. Statsig built a complete set of data tools that allow engineering teams to measure the impact of their work. This toolkit is SO valuable to so many teams, that OpenAI - who was a huge user of Statsig - decided to acquire the company, the news announced last week. Talk about validation! Check out Statsig. •⁠ Linear – The system for modern product development. Here’s an interesting story: OpenAI switched to Linear as a way to establish a shared vocabulary between teams. Every project now follows the same lifecycle, uses the same labels, and moves through the same states. Try Linear for yourself. — The Pragmatic Engineer Podcast is back with the Fall 2025 season. Expect new episodes to be published on most Wednesdays, looking ahead. Code Complete is one of the most enduring books on software engineering. Steve McConnell wrote the 900-page handbook just five years into his career, capturing what he wished he’d known when starting out. Decades later, the lessons remain relevant, and Code Complete remains a best-seller. In this episode, we talk about what has aged well, what needed updating in the second edition, and the broader career principles Steve has developed along the way. From his “career pyramid” model to his critique of “lily pad hopping,” and why periods of working in fast-paced, all-in environments can be so rewarding, the emphasis throughout is on taking ownership of your career and making deliberate choices. We also discuss: • Top-down vs. bottom-up design and why most engineers default to one approach • Why rewriting code multiple times makes it better • How taking a year off to write Code Complete crystallized key lessons • The 3 areas software designers need to understand, and why focusing only on technology may be the most limiting  • And much more! Steve rarely gives interviews, so I hope you enjoy this conversation, which we recorded in Seattle. — Timestamps (00:00) Intro (01:31) How and why Steve wrote Code Complete (08:08) What code construction is and how it differs from software development (11:12) Top-down vs. bottom-up design approach (14:46) Why design documents frustrate some engineers (16:50) The case for rewriting everything three times (20:15) Steve’s career before and after Code Complete (27:47) Steve’s career advice (44:38) Three areas software designers need to understand (48:07) Advice when becoming a manager, as a developer (53:02) The importance of managing your energy (57:07) Early Microsoft and why startups are a culture of intense focus (1:04:14) What changed in the second edition of Code Complete  (1:10:50) AI’s impact on software development: Steve’s take (1:17:45) Code reviews and GenAI (1:19:58) Why engineers are becoming more full-stack  (1:21:40) Could AI be the exception to “no silver bullets?” (1:26:31) Steve’s advice for engineers on building a meaningful career — The Pragmatic Engineer deepdives relevant for this episode: • What changed in 50 years of computing • The past and future of modern backend practices • The Philosophy of Software Design – with John Ousterhout • AI tools for software engineers, but without the hype – with Simon Willison (co-creator of Django)  • TDD, AI agents and coding – with Kent Beck — Production and marketing by ⁠⁠⁠⁠⁠⁠⁠⁠https://penname.co/⁠⁠⁠⁠⁠⁠⁠⁠. For inquiries about sponsoring the podcast, email [email protected].

Get full access to The Pragmatic Engineer at newsletter.pragmaticengineer.com/subscribe

Supported by Our Partners •⁠ WorkOS — The modern identity platform for B2B SaaS. •⁠ Statsig ⁠ — ⁠ The unified platform for flags, analytics, experiments, and more. •⁠ Sonar — Code quality and code security for ALL code. — Steve Yegge⁠ is known for his writing and “rants”, including the famous “Google Platforms Rant” and the evergreen “Get that job at Google” post. He spent 7 years at Amazon and 13 at Google, as well as some time at Grab before briefly retiring from tech. Now out of retirement, he’s building AI developer tools at Sourcegraph—drawn back by the excitement of working with LLMs. He’s currently writing the book Vibe Coding: Building Production-Grade Software With GenAI, Chat, Agents, and Beyond. In this episode of The Pragmatic Engineer, I sat down with Steve in Seattle to talk about why Google consistently failed at building platforms, why AI coding feels easy but is hard to master, and why a new role, the AI Fixer, is emerging. We also dig into why he’s so energized by today’s AI tools, and how they’re changing the way software gets built. We also discuss:  • The “interview anti-loop” at Google and the problems with interviews • An inside look at how Amazon operated in the early days before microservices   • What Steve liked about working at Grab • Reflecting on the Google platforms rant and why Steve thinks Google is still terrible at building platforms • Why Steve came out of retirement • The emerging role of the “AI Fixer” in engineering teams • How AI-assisted coding is deceptively simple, but extremely difficult to steer • Steve’s advice for using AI coding tools and overcoming common challenges • Predictions about the future of developer productivity • A case for AI creating a real meritocracy  • And much more! — Timestamps (00:00) Intro (04:55) An explanation of the interview anti-loop at Google and the shortcomings of interviews (07:44) Work trials and why entry-level jobs aren’t posted for big tech companies (09:50) An overview of the difficult process of landing a job as a software engineer (15:48) Steve’s thoughts on Grab and why he loved it (20:22) Insights from the Google platforms rant that was picked up by TechCrunch (27:44) The impact of the Google platforms rant (29:40) What Steve discovered about print ads not working for Google  (31:48) What went wrong with Google+ and Wave (35:04) How Amazon has changed and what Google is doing wrong (42:50) Why Steve came out of retirement  (45:16) Insights from “the death of the junior developer” and the impact of AI (53:20) The new role Steve predicts will emerge  (54:52) Changing business cycles (56:08) Steve’s new book about vibe coding and Gergely’s experience  (59:24) Reasons people struggle with AI tools (1:02:36) What will developer productivity look like in the future (1:05:10) The cost of using coding agents  (1:07:08) Steve’s advice for vibe coding (1:09:42) How Steve used AI tools to work on his game Wyvern  (1:15:00) Why Steve thinks there will actually be more jobs for developers  (1:18:29) A comparison between game engines and AI tools (1:21:13) Why you need to learn AI now (1:30:08) Rapid fire round — The Pragmatic Engineer deepdives relevant for this episode: •⁠ The full circle of developer productivity with Steve Yegge •⁠ Inside Amazon’s engineering culture •⁠ Vibe coding as a software engineer •⁠ AI engineering in the real world •⁠ The AI Engineering stack •⁠ Inside Sourcegraph’s engineering culture— See the transcript and other references from the episode at ⁠⁠https://newsletter.pragmaticengineer.com/podcast⁠⁠ — Production and marketing by ⁠⁠⁠⁠⁠⁠⁠⁠https://penname.co/⁠⁠⁠⁠⁠⁠⁠⁠. For inquiries about sponsoring the podcast, email [email protected].

Get full access to The Pragmatic Engineer at newsletter.pragmaticengineer.com/subscribe

Supported by Our Partners •⁠ WorkOS — The modern identity platform for B2B SaaS. •⁠ Modal⁠ — The cloud platform for building AI applications. •⁠ Cortex⁠ — Your Portal to Engineering Excellence. — Kubernetes is the second-largest open-source project in the world. What does it actually do—and why is it so widely adopted? In this episode of The Pragmatic Engineer, I’m joined by Kat Cosgrove, who has led several Kubernetes releases. Kat has been contributing to Kubernetes for several years, and originally got involved with the project through K3s (the lightweight Kubernetes distribution). In our conversation, we discuss how Kubernetes is structured, how it scales, and how the project is managed to avoid contributor burnout. We also go deep into:  • An overview of what Kubernetes is used for • A breakdown of Kubernetes architecture: components, pods, and kubelets • Why Google built Borg, and how it evolved into Kubernetes • The benefits of large-scale open source projects—for companies, contributors, and the broader ecosystem • The size and complexity of Kubernetes—and how it’s managed • How the project protects contributors with anti-burnout policies • The size and structure of the release team • What KEPs are and how they shape Kubernetes features • Kat’s views on GenAI, and why Kubernetes blocks using AI, at least for documentation • Where Kat would like to see AI tools improve developer workflows • Getting started as a contributor to Kubernetes—and the career and networking benefits that come with it • And much more! — Timestamps (00:00) Intro (02:02) An overview of Kubernetes and who it’s for  (04:27) A quick glimpse at the architecture: Kubernetes components, pods, and cubelets (07:00) Containers vs. virtual machines  (10:02) The origins of Kubernetes  (12:30) Why Google built Borg, and why they made it an open source project (15:51) The benefits of open source projects  (17:25) The size of Kubernetes (20:55) Cluster management solutions, including different Kubernetes services (21:48) Why people contribute to Kubernetes  (25:47) The anti-burnout policies Kubernetes has in place  (29:07) Why Kubernetes is so popular (33:34) Why documentation is a good place to get started contributing to an open-source project (35:15) The structure of the Kubernetes release team  (40:55) How responsibilities shift as engineers grow into senior positions (44:37) Using a KEP to propose a new feature—and what’s next (48:20) Feature flags in Kubernetes  (52:04) Why Kat thinks most GenAI tools are scams—and why Kubernetes blocks their use (55:04) The use cases Kat would like to have AI tools for (58:20) When to use Kubernetes  (1:01:25) Getting started with Kubernetes  (1:04:24) How contributing to an open source project is a good way to build your network (1:05:51) Rapid fire round — The Pragmatic Engineer deepdives relevant for this episode: •⁠ Backstage: an open source developer portal •⁠ How Linux is built with Greg Kroah-Hartman •⁠ Software engineers leading projects •⁠ What TPMs do and what software engineers can learn from them •⁠ Engineering career paths at Big Tech and scaleups — See the transcript and other references from the episode at ⁠⁠https://newsletter.pragmaticengineer.com/podcast⁠⁠ — Production and marketing by ⁠⁠⁠⁠⁠⁠⁠⁠https://penname.co/⁠⁠⁠⁠⁠⁠⁠⁠. For inquiries about sponsoring the podcast, email [email protected].

Get full access to The Pragmatic Engineer at newsletter.pragmaticengineer.com/subscribe

Supported by Our Partners •⁠ Modal⁠ — The cloud platform for building AI applications •⁠ CodeRabbit⁠⁠ — Cut code review time and bugs in half. Use the code PRAGMATIC to get one month free. — What happens when LLMs meet real-world codebases? In this episode of The Pragmatic Engineer,  I am joined by Varun Mohan, CEO and Co-Founder of Windsurf. Varun talks me through the technical challenges of building an AI-native IDE (Windsurf) —and how these tools are changing the way software gets built.  We discuss:  • What building self-driving cars taught the Windsurf team about evaluating LLMs • How LLMs for text are missing capabilities for coding like “fill in the middle” • How Windsurf optimizes for latency • Windsurf’s culture of taking bets and learning from failure • Breakthroughs that led to Cascade (agentic capabilities) • Why the Windsurf teams build their LLMs • How non-dev employees at Windsurf build custom SaaS apps – with Windsurf! • How Windsurf empowers engineers to focus on more interesting problems • The skills that will remain valuable as AI takes over more of the codebase • And much more! — Timestamps (00:00) Intro (01:37) How Windsurf tests new models (08:25) Windsurf’s origin story  (13:03) The current size and scope of Windsurf (16:04) The missing capabilities Windsurf uncovered in LLMs when used for coding (20:40) Windsurf’s work with fine-tuning inside companies  (24:00) Challenges developers face with Windsurf and similar tools as codebases scale (27:06) Windsurf’s stack and an explanation of FedRAMP compliance (29:22) How Windsurf protects latency and the problems with local data that remain unsolved (33:40) Windsurf’s processes for indexing code  (37:50) How Windsurf manages data  (40:00) The pros and cons of embedding databases  (42:15) “The split brain situation”—how Windsurf balances present and long-term  (44:10) Why Windsurf embraces failure and the learnings that come from it (46:30) Breakthroughs that fueled Cascade (48:43) The insider’s developer mode that allows Windsurf to dogfood easily  (50:00) Windsurf’s non-developer power user who routinely builds apps in Windsurf (52:40) Which SaaS products won’t likely be replaced (56:20) How engineering processes have changed at Windsurf  (1:00:01) The fatigue that goes along with being a software engineer, and how AI tools can help (1:02:58) Why Windsurf chose to fork VS Code and built a plugin for JetBrains  (1:07:15) Windsurf’s language server  (1:08:30) The current use of MCP and its shortcomings  (1:12:50) How coding used to work in C#, and how MCP may evolve  (1:14:05) Varun’s thoughts on vibe coding and the problems non-developers encounter (1:19:10) The types of engineers who will remain in demand  (1:21:10) How AI will impact the future of software development jobs and the software industry (1:24:52) Rapid fire round — The Pragmatic Engineer deepdives relevant for this episode: • IDEs with GenAI features that Software Engineers love • AI tooling for Software Engineers in 2024: reality check • How AI-assisted coding will change software engineering: hard truths • AI tools for software engineers, but without the hype — See the transcript and other references from the episode at ⁠⁠https://newsletter.pragmaticengineer.com/podcast⁠⁠ — Production and marketing by ⁠⁠⁠⁠⁠⁠⁠⁠https://penname.co/⁠⁠⁠⁠⁠⁠⁠⁠. For inquiries about sponsoring the podcast, email [email protected].

Get full access to The Pragmatic Engineer at newsletter.pragmaticengineer.com/subscribe

Supported by Our Partners • WorkOS — The modern identity platform for B2B SaaS. • The Software Engineer’s Guidebook: Written by me (Gergely) – now out in audio form as well • Augment Code — AI coding assistant that pro engineering teams love — Not many people know that I have a brother: Balint Orosz. Balint is also in tech, but in many ways, is the opposite of me. While I prefer working on backend and business logic, he always thrived in designing and building UIs. While I opted to work at more established companies, he struck out on his own and started his startup, Distinction. And yet, our professional paths have crossed several times: at one point in time I accepted an offer to join Skyscanner as a Principal iOS Engineer – and as part of the negotiation, I added a clause to my contrac that I will not report directly or indirectly to the Head of Mobile: who happened to be my brother, thanks to Skyscanner acquiring his startup the same month that Skyscanner made an offer to hire me. Today, Balint is the founder and CEO of Craft, a beloved text editor known for its user-friendly interface and sleek design – an app that Apple awarded the prestigious Mac App of the Year in 2021. In our conversation, we explore how Balint approaches building opinionated software with an intense focus on user experience. We discuss the lessons he learned from his time building Distinction and working at Skyscanner that have shaped his approach to Craft and its development. In this episode, we discuss: • Balint’s first startup, Distinction, and his time working for Skyscanner after they acquired it • A case for a balanced engineering culture with both backend and frontend priorities  • Why Balint doesn’t use iOS Auto Layout • The impact of Craft being personal software on front-end and back-end development • The balance between customization and engineering fear in frontend work • The resurgence of local-first software and its role in modern computing • The value of building a physical prototype  • How Balint uses GenAI to assist with complicated coding projects  • And much more! — Timestamps (00:00) Intro (02:13) What it’s like being a UX-focused founder  (09:00) Why it was hard to gain recognition at Skyscanner  (13:12) Takeaways from Skyscanner that Balint brought to Craft  (16:50) How frameworks work and why they aren’t always a good fit (20:35) An explanation of iOS Auto Layout and its pros and cons  (23:13) Why Balint doesn’t use Auto Layout  (24:23) Why Craft has one code base  (27:46) Craft’s unique toolbar features and a behind the scenes peek at the code  (33:15) Why frontend engineers have fear around customization  (37:11) How Craft’s design system differs from most companies  (42:33) Behaviors and elements Craft uses rather than having a system for everything  (44:12) The back and frontend architecture in building personal software  (48:11) Shifting beliefs in personal computing  (50:15) The challenges faced with operating system updates  (50:48) The resurgence of local-first software (52:31) The value of opinionated software for consumers  (55:30) Why Craft’s focus is on the user’s emotional experience (56:50) The size of Craft’s engineering department and platform teams (59:20) Why Craft moves faster with smaller teams (1:01:26) Balint’s advice for frontend engineers looking to demonstrate value  (1:04:35) Balint’s breakthroughs using GenAI (1:07:50) Why Balint still writes code (1:09:44) Rapid fire round — The Pragmatic Engineer deepdives relevant for this episode: • The AI hackathon at Craft Docs • Engineering career paths at Big Tech and scaleups • Thriving as a Founding Engineer: lessons from the trenches • The past and future of modern backend practices — See the transcript and other references from the episode at ⁠⁠https://newsletter.pragmaticengineer.com/podcast⁠⁠ — Production and marketing by ⁠⁠⁠⁠⁠⁠⁠⁠https://penname.co/⁠⁠⁠⁠⁠⁠⁠⁠. For inquiries about sponsoring the podcast, email [email protected].

Get full access to The Pragmatic Engineer at newsletter.pragmaticengineer.com/subscribe

Supported by Our Partners • Swarmia — The engineering intelligence platform for modern software organizations. • Graphite — The AI developer productivity platform.  • Vanta — Automate compliance and simplify security with Vanta. — On today’s episode of The Pragmatic Engineer, I’m joined by Chip Huyen, a computer scientist, author of the freshly published O’Reilly book AI Engineering, and an expert in applied machine learning. Chip has worked as a researcher at Netflix, was a core developer at NVIDIA (building NeMo, NVIDIA’s GenAI framework), and co-founded Claypot AI. She also taught Machine Learning at Stanford University. In this conversation, we dive into the evolving field of AI Engineering and explore key insights from Chip’s book, including: • How AI Engineering differs from Machine Learning Engineering  • Why fine-tuning is usually not a tactic you’ll want (or need) to use • The spectrum of solutions to customer support problems – some not even involving AI! • The challenges of LLM evals (evaluations) • Why project-based learning is valuable—but even better when paired with structured learning • Exciting potential use cases for AI in education and entertainment • And more! — Timestamps (00:00) Intro  (01:31) A quick overview of AI Engineering (05:00) How Chip ensured her book stays current amidst the rapid advancements in AI (09:50) A definition of AI Engineering and how it differs from Machine Learning Engineering  (16:30) Simple first steps in building AI applications (22:53) An explanation of BM25 (retrieval system)  (23:43) The problems associated with fine-tuning  (27:55) Simple customer support solutions for rolling out AI thoughtfully  (33:44) Chip’s thoughts on staying focused on the problem  (35:19) The challenge in evaluating AI systems (38:18) Use cases in evaluating AI  (41:24) The importance of prioritizing users’ needs and experience  (46:24) Common mistakes made with Gen AI (52:12) A case for systematic problem solving  (53:13) Project-based learning vs. structured learning (58:32) Why AI is not the end of engineering (1:03:11) How AI is helping education and the future use cases we might see (1:07:13) Rapid fire round — The Pragmatic Engineer deepdives relevant for this episode: • Applied AI Software Engineering: RAG https://newsletter.pragmaticengineer.com/p/rag  • How do AI software engineering agents work? https://newsletter.pragmaticengineer.com/p/ai-coding-agents  • AI Tooling for Software Engineers in 2024: Reality Check https://newsletter.pragmaticengineer.com/p/ai-tooling-2024  • IDEs with GenAI features that Software Engineers love https://newsletter.pragmaticengineer.com/p/ide-that-software-engineers-love — See the transcript and other references from the episode at ⁠⁠https://newsletter.pragmaticengineer.com/podcast⁠⁠ — Production and marketing by ⁠⁠⁠⁠⁠⁠⁠⁠https://penname.co/⁠⁠⁠⁠⁠⁠⁠⁠. For inquiries about sponsoring the podcast, email [email protected].

Get full access to The Pragmatic Engineer at newsletter.pragmaticengineer.com/subscribe

Supported by Our Partners • Formation — Level up your career and compensation with Formation.  • WorkOS — The modern identity platform for B2B SaaS • Vanta — Automate compliance and simplify security with Vanta. — In today’s episode of The Pragmatic Engineer, I’m joined by Jonas Tyroller, one of the developers behind Thronefall, a minimalist indie strategy game that blends tower defense and kingdom-building, now available on Steam. Jonas takes us through the journey of creating Thronefall from start to finish, offering insights into the world of indie game development. We explore: • Why indie developers often skip traditional testing and how they find bugs • The developer workflow using Unity, C# and Blender • The two types of prototypes game developers build  • Why Jonas spent months building game prototypes in 1-2 days • How Jonas uses ChatGPT to build games • Jonas’s tips on making games that sell • And more! — Timestamps (00:00) Intro (02:07) Building in Unity (04:05) What the shader tool is used for  (08:44) How a Unity build is structured (11:01) How game developers write and debug code  (16:21) Jonas’s Unity workflow (18:13) Importing assets from Blender (21:06) The size of Thronefall and how it can be so small (24:04) Jonas’s thoughts on code review (26:42) Why practices like code review and source control might not be relevant for all contexts (30:40) How Jonas and Paul ensure the game is fun  (32:25) How Jonas and Paul used beta testing feedback to improve their game (35:14) The mini-games in Thronefall and why they are so difficult (38:14) The struggle to find the right level of difficulty for the game (41:43) Porting to Nintendo Switch (45:11) The prototypes Jonas and Paul made to get to Thronefall (46:59) The challenge of finding something you want to build that will sell (47:20) Jonas’s ideation process and how they figure out what to build  (49:35) How Thronefall evolved from a mini-game prototype (51:50) How long you spend on prototyping  (52:30) A lesson in failing fast (53:50) The gameplay prototype vs. the art prototype (55:53) How Jonas and Paul distribute work  (57:35) Next steps after having the play prototype and art prototype (59:36) How a launch on Steam works  (1:01:18) Why pathfinding was the most challenging part of building Thronefall (1:08:40) Gen AI tools for building indie games  (1:09:50) How Jonas uses ChatGPT for editing code and as a translator  (1:13:25) The pros and cons of being an indie developer  (1:15:32) Jonas’s advice for software engineers looking to get into indie game development (1:19:32) What to look for in a game design school (1:22:46) How luck figures into success and Jonas’s tips for building a game that sells (1:26:32) Rapid fire round — The Pragmatic Engineer deepdives relevant for this episode: • Game development basics https://newsletter.pragmaticengineer.com/p/game-development-basics  • Building a simple game using Unity https://newsletter.pragmaticengineer.com/p/building-a-simple-game — See the transcript and other references from the episode at ⁠⁠https://newsletter.pragmaticengineer.com/podcast⁠⁠ — Production and marketing by ⁠⁠⁠⁠⁠⁠⁠⁠https://penname.co/⁠⁠⁠⁠⁠⁠⁠⁠. For inquiries about sponsoring the podcast, email [email protected].

Get full access to The Pragmatic Engineer at newsletter.pragmaticengineer.com/subscribe

Supported by Our Partners • DX — DX is an engineering intelligence platform designed by leading researchers.  • Vanta — Automate compliance and simplify security with Vanta. — In today’s episode of The Pragmatic Engineer, I catch up with one of the best tech recruiters I’ve had the opportunity to work with: Blake Stockman, a former colleague of mine from Uber. Blake built a strong reputation in the recruiting world, working at tech giants like Google, Meta, and Uber. He also spent time with Y Combinator and founded his agency, where he helped both large tech companies and early-stage startups find and secure top talent. A few months ago, Blake did a career pivot: he is now studying to become a lawyer. I pounced on this perfect opportunity to have him share all that he’s seen behind-the-scenes in tech recruitment: sharing his observations unfiltered. In our conversation, Blake shares recruitment insights from his time at Facebook, Google, and Uber and his experience running his own tech recruitment agency. We discuss topics such as: • A step-by-step breakdown of hiring processes at Big Tech and startups• How to get the most out of your tech recruiter, as a candidate• Best practices for hiring managers to work with their recruiter• Why you shouldn’t disclose salary expectations upfront, plus tips for negotiating• Where to find the best startup opportunities and how to evaluate them—including understanding startup compensation• And much more! — Timestamps (00:00) Intro (01:40) Tips for working with recruiters (06:11) Why hiring managers should have more conversations with recruiters (09:48) A behind-the-scenes look at the hiring process at big tech companies  (13:38) How hiring worked at Uber when Gergely and Blake were there (16:46) An explanation of calibration in the recruitment process (18:11) A case for partnering with recruitment  (20:49) The different approaches to recruitment Blake experienced at different organizations (25:30) How hiring decisions are made  (31:34) The differences between hiring at startups vs. large, established companies (33:21) Reasons desperate decisions are made and problems that may arise (36:30) The problem of hiring solely to fill a seat (38:55) The process of the closing call (40:24) The importance of understanding equity  (43:27) Tips for negotiating  (48:38) How to find the best startup opportunities, and how to evaluate if it’s a good fit (53:58) What to include on your LinkedIn profile (55:48) A story from Uber and why you should remember to thank your recruiter (1:00:09) Rapid fire round — The Pragmatic Engineer deepdives relevant for this episode: • How GenAI is reshaping tech hiring https://newsletter.pragmaticengineer.com/p/how-genai-changes-tech-hiring • Hiring software engineers https://newsletter.pragmaticengineer.com/p/hiring-software-engineers  • Hiring an Engineering Manager https://newsletter.pragmaticengineer.com/p/hiring-engineering-managers • Hiring Junior Software Engineers https://newsletter.pragmaticengineer.com/p/hiring-junior-engineers — See the transcript and other references from the episode at ⁠⁠https://newsletter.pragmaticengineer.com/podcast⁠⁠ — Production and marketing by ⁠⁠⁠⁠⁠⁠⁠⁠https://penname.co/⁠⁠⁠⁠⁠⁠⁠⁠. For inquiries about sponsoring the podcast, email [email protected].

Get full access to The Pragmatic Engineer at newsletter.pragmaticengineer.com/subscribe

Supported by Our Partner DX⁠ → DX is an engineering intelligence platform designed by leading researchers — In today’s episode of The Pragmatic Engineer, I’m joined by Sean Goedecke, Staff Software Engineer at GitHub. Sean is widely known for his viral blog post, “How I ship projects at big tech companies.” In our conversation, he shares how to successfully deliver projects in large tech companies.

Drawing from his experiences at GitHub and Zendesk, Sean reflects on key lessons learned, and we discuss the following topics:  • Why shipping cannot exclude keeping management happy • How to work on stuff the company actually values • Why you should take on extra responsibility to get projects done • Why technical skills are still more important than soft skills • Soft skills you should learn: including learning the “management lingo” • First-hand remote work learnings: advantages, disadvantages, and how to thrive in this setup • … and much more! — Timestamps (00:00) Intro (01:50) An explanation of shipping (05:35) Reasons management may choose to ship something customers don’t love (09:20) A humbling learning from Sean’s time at Zendesk (13:27) The importance of learning which rules need to be broken for good business outcomes (15:28) Common obstacles to shipping (18:13) DRI: Directly responsible individual (23:06) The value of strong technical skills and why moving fast is imperative (28:44) How to leverage your technical skills the right way (32:16) Advice on earning the trust of leadership (36:10) A time Gergely shipped a product for a political reason  (38:30) What GenAI helps software engineers do more easily  (41:08) Sean’s thoughts on GenAI making engineers more ambitious  (43:20) The difficulty of building AI tools (46:10) Advantages of working remotely and strategies for making it work (52:34) Who is best suited to remote work (54:48) How the pandemic provided a remote work trial for Sean (56:45) Rapid fire round — The Pragmatic Engineer deepdives relevant for this episode: • Software Engineers Leading Projects ⁠https://newsletter.pragmaticengineer.com/p/engineers-leading-projects⁠ • Shipping to production ⁠https://newsletter.pragmaticengineer.com/p/shipping-to-production⁠ • Paying down tech debt ⁠https://newsletter.pragmaticengineer.com/p/paying-down-tech-debt⁠ — See the transcript and other references from the episode at ⁠⁠https://newsletter.pragmaticengineer.com/podcast⁠⁠ — Production and marketing by ⁠⁠⁠⁠⁠⁠⁠⁠https://penname.co/⁠⁠⁠⁠⁠⁠⁠⁠. For inquiries about sponsoring the podcast, email [email protected].

Get full access to The Pragmatic Engineer at newsletter.pragmaticengineer.com/subscribe