Fundamentals of Software Engineering

In this episode of Fundamentals of Software Engineering, Nate and I dig into a feeling almost every developer has right now: that everyone else is further ahead on AI. New models, agents and protocols seem to arrive every week, and between the two of us we make a lot of content about this stuff and still feel behind. We start with what I call social media driven development, the stream of posts about coding agents that cleared three issues overnight or SaaS apps built while someone slept, and why treating those as a benchmark will always leave you feeling behind. From there we talk about why this industry has always moved fast, why you cannot learn everything, and how setting career goals lets you work backwards to what actually deserves your time. We also get honest about burnout, time boxing your exploration, and why sometimes the right call is to close the laptop and go touch grass.Then we get practical. We cover prioritizing what your company asks you to learn, leaning on a network of people you trust, and taking AI doomsday headlines with a grain of salt. Nate explains how the Thoughtworks Technology Radar gets made, from blips submitted by technologists working with real clients to the debates that decide what makes the cut, and why Agile practices like testing and frequent check ins with your product owner matter even more when code can be generated this fast. I share a talk we saw at Commit Your Code from the PGA Tour, whose engineers started their agent on simple issue triage and only handed it harder tickets as their confidence grew. We finish on blast radius, why a startup and a Fortune 500 enterprise should not read the same amount of code, and why it is worth giving yourself some grace.__________________________________________________Key Highlights📱 Social media driven development: Posts about agents fixing issues overnight or apps built in your sleep are written for engagement. Measure yourself against them and you will always feel behind, when most of us are somewhere in the middle.📚 You cannot learn everything: Set career goals and work backwards to what deserves your time. Technologies are like buses: another one comes along in ten or fifteen minutes, so it is fine to let some waves go by.🔋 Burnout is real, so time box exploration: Every evening spent on a new LLM is time you cannot spend on something else. Sometimes the right choice is friends, family, or a walk.🤝 Let your network be the filter: Trusted friends and a daily AI news brief tell you what is worth a closer look, so you are not drinking from the fire hose or falling down every rabbit hole.📡 How the Thoughtworks Technology Radar is made: It starts as blips from technologists using things on real client work, then gets debated down twice a year. There is no pay to play, which is why it stays so objective.🏌️ The PGA Tour's agent earned its trust: Their engineers started the agent on issue triage, then low priority tickets, and only moved up to critical ones as confidence grew. None of it happened overnight.💥 Stakes decide how much code you read: A startup with six months of runway can move fast, but a core pricing engine deserves scrutiny on every line. Tests, build results and observability are how you read the rest.__________________________________________________Resources & Next Steps🌐 fundamentalsofswe.com for the book, the podcast and the YouTube channel📡 Thoughtworks Technology Radar📕 If Anyone Builds It, Everyone Dies by Eliezer Yudkowsky and Nate Soares🎤 Commit Your Code conference, run by Danny Thompson🛠️ Tools mentioned: Claude Code, Copilot, OpenAI Codex, Perplexity and NotebookLM✈️ Catch Dan and Nate at Dev2Next, Porto Tech Hub and QCon San Francisco🎧 Subscribe to Fundamentals of Software Engineering on Apple Podcasts__________________________________________________Chapter Timestamps00:00 Are you behind on AI? Probably not02:42 The book turns one, and conferences coming up07:33 The question of the day: do you feel behind on AI08:25 Social media driven development10:37 You cannot learn everything, so set career goals13:19 Why every new tool floods your feed17:00 Burnout and time boxing your exploration20:09 Prioritize what your job asks of you first22:19 Lean on your network23:27 Taking AI doomsday claims with a grain of salt27:17 The two sides of AI for software engineers31:00 There are no dumb questions33:35 Learning what the career you want demands35:25 Every language you learn makes the next one easier36:55 A daily AI brief instead of the rabbit hole39:46 How the Thoughtworks Technology Radar is made43:15 Agile practices matter more, and nobody is an expert yet46:05 How the PGA Tour eased agents into its workflow51:03 Startups vs enterprises: why the stakes matter52:26 Reading code and earning trust in your agent56:44 Give yourself some grace58:13 Dad joke and wrap up

In this episode of Fundamentals of Software Engineering, Nate and I dig into public speaking, recorded live from a conference floor between our own talks. We start where most people actually start, which is nowhere near a keynote stage. Nobody goes from never having spoken to opening a major conference, and pretending otherwise puts people off before they begin. We talk about the places that genuinely welcome a first talk: the lunch and learn at your own company, a local meetup, a book club with a few colleagues. Lower stakes, smaller rooms, shorter slots. I make the case that volunteering to speak on something is the best motivation there is for learning it properly, because you have to learn it once to know it and again to teach it.From there we get into the craft. We cover writing an abstract that survives a committee reading hundreds of them, why one talk should carry one idea, and what happens to your slides when you keep shrinking the font to fit more words in. We talk about live demos and why a recording is not cheating, tethering off your phone when the venue Wi-Fi dies, and building expansion joints into a deck so the same material can fill twenty minutes or four hours. Then the part nobody admits to: nerves. I still get them after twenty years. We finish on delivery, filler words, starting on time, ending on time, and why the room is almost always on your side.__________________________________________________Key Highlights🎤 Nobody starts at the keynote: Going from zero to keynoting KubeCon is vanishingly rare. The realistic first stops are a lunch and learn, a local meetup, or a book club with colleagues.📚 Volunteer to speak on what you want to learn: The best motivation for learning a topic is agreeing to teach it. You learn it once to know it, and again to explain it to a room.✍️ One idea, one talk: If you have two ideas, that is two talks. Abstracts fail when they try to be broad, and committees are reading hundreds of submissions for very few slots.🖥️ Slides are not a handout: A deck that works as a read-it-later document serves neither the room nor the reader. If the font keeps shrinking to fit the words, the words belong somewhere else.📹 Record the demo, and bring your own Wi-Fi: Recorded demos are not cheating, especially for anything slow. Tethering off your phone saves the talk when conference Wi-Fi fails, and it is worth testing beforehand.⏱️ Build expansion joints into the deck: Know what you can skip and what you can stretch, so the same talk fits a twenty minute slot or a four hour workshop. Start on time, end on time.😬 The nerves do not go away, and the room is on your side: After twenty years the nerves are still there. Almost nobody in that room wishes they were giving your talk instead: they came to learn something.__________________________________________________Resources & Next Steps🗣️ Start with a lunch and learn, a local meetup, or a book club at work🎥 Record yourself on a video call and watch it back to hear your own filler words📶 Tether off your phone as a backup for venue Wi-Fi, and test it before the talk🎧 Subscribe to Fundamentals of Software Engineering on Apple Podcasts__________________________________________________Chapter Timestamps00:00 Recording live from the conference floor01:30 Why a mixed conference beats one full of your own crowd04:30 Nobody goes from zero to keynoting06:00 Volunteer to speak on what you want to learn07:30 Lunch and learns, meetups, and book clubs as a first step09:00 Handling questions, including the ones you cannot answer10:30 Finding your own presenting style12:00 Telling the audience what they are getting into13:30 Submitting on a topic you have not learned yet15:00 Writing an abstract around one hook16:30 One idea is one talk18:00 What committees see: hundreds of submissions, few slots19:30 When the font keeps shrinking, the words are in the wrong place21:00 Slides that try to be a handout serve nobody22:30 The night before, with no venue Wi-Fi24:00 Recording demos, especially the slow ones25:30 Tethering off your phone as a backup plan27:00 Expansion joints: the same talk at any length30:00 Nerves, after twenty years of doing this31:30 The room is on your side33:00 Knowing your first sixty seconds by heart36:00 Watching yourself back to hear your own pace37:30 Filler words and the power of a pause40:30 Arrive early and check the room42:00 Start on time, end on time, the room is not yours45:00 Practising a nine minute keynote to the second46:30 Evergreen material and giving a talk more than once49:30 Your first attempts will be bad, and that is the job52:30 You already know something most people do not

In this episode of Fundamentals of Software Engineering, Nate and I dig into the question the whole show is named after and the one our book only had a single chapter for: what software architecture actually is. We start where Neal Ford and Mark Richards start, with architecture as the things you cannot Google, and we work out why that definition holds up. By the time a decision reaches an architect, the easy answers are gone. Nobody escalates a variable name. What gets escalated is whether this should be a modular monolith, a set of microservices, or something event driven, and none of those have an answer that survives being lifted out of your context.From there we get into the part that makes architecture uncomfortable: it is trade-offs all the way down. We talk about quality attributes, the ilities that routinely conflict with each other, and why a manager asking for all of them at once is asking for something that does not exist. We cover architectural malpractice, the habit of picking a pattern because it is fashionable rather than because the problem demands it, and what happens when a whole platform gets rewritten around one team's favourite language. We also talk about legacy systems and why reimagining beats dragging, about evolutionary architecture and fitness functions, about the difference between design and architecture, and we close on what we would tell an engineer who wants to grow into the role.__________________________________________________Key Highlights🔎 Architecture is the things you can't Google: Neal Ford and Mark Richards coined it and it holds. The answer always depends on your constraints and the forces you are actually up against.🏛️ No easy answers reach the architect: If a question had an obvious answer, it would have been solved further down. What lands on your desk is what is left.⚖️ The ilities conflict with each other: Scalability, maintainability, simplicity and the rest pull in different directions. Prioritising them is the job, not a failure to deliver all of them.🚨 Architectural malpractice: Reaching for microservices because they are in fashion, when the team shape and the actual demand say otherwise, is malpractice rather than ambition.🐍 Don't replatform a whole team for one capability: If your people are strong on the JVM, moving the organisation to Python to reach one library is rarely the trade you think it is.🔄 Reimagine legacy, do not drag it: Carrying every old defect and unfixed feature into the next system is a choice, and usually the wrong one.🌱 How to grow into the role: Talk to the architects around you about how they got there, what they like, and what they do not. Ask what the path looks like before you try to walk it.__________________________________________________Resources & Next Steps📘 Fundamentals of Software Engineering, the book and the podcast📚 Building Evolutionary Architectures by Neal Ford, Rebecca Parsons and Patrick Kua (second edition out now)📖 Software architecture writing by Neal Ford and Mark Richards🖥️ Fundamentals of Software Engineering on YouTube for the video version🎤 Catch Dan and Nate at KCDC, Devnexus, Dev2Next and QCon San Francisco🎧 Subscribe to Fundamentals of Software Engineering on Apple Podcasts__________________________________________________YouTube Chapter Timestamps00:00 Cold open: reading Carnegie is as useful as another framework03:19 Conference season: what is coming up06:53 Dev2Next and Venkat's conferences07:36 QCon San Francisco and some good news09:31 Today's topic, and where to find the book10:28 Why one chapter on architecture was never going to be enough11:36 Three shelves of architecture books and what they have in common13:31 By the time the question reaches you, the easy answers are gone14:30 Architecture is the things you can't Google16:43 Knowing which questions to ask, and how to get answers18:36 Does this problem actually require Kafka20:34 Structure, teams and what architecture you can realistically run23:21 Architectural malpractice, defined24:43 Designing for scale you do not have yet27:23 AI on the JVM, and not replatforming a team to chase a library28:48 New leadership, rewrites, and the defects you carry across31:34 Who should be an architect these days34:45 Where design ends and architecture begins42:29 Evolutionary architecture and fitness functions46:23 The ilities, quality attributes and real trade-offs55:46 Advice for engineers who want to grow into architecture

In this episode of Fundamentals of Software Engineering, Nate and I dig into context engineering, the phrase that has quietly replaced prompt engineering as the term on everyone's 2026 bingo card. Our core argument is simple. Context engineering is not a shiny new AI skill, it is a data fundamental you probably already know, just wearing a new name. Prompt engineering is about how you ask. Context engineering is about what the model actually knows when you ask. We frame it as a desk and a filing cabinet, where the context window is the desk and your job is deciding what belongs on it right now. Along the way we get into structured versus unstructured data, retrieval augmented generation, tools, and why getting the right information in front of a model matters far more than crafting the perfect prompt.We also pump the brakes on the idea that coding is solved and engineers are optional. We talk through the headlines, Spotify shipping thousands of deploys a day with most pull requests now AI assisted, and Ford rehiring hundreds of veteran engineers after AI could not replace decades of hard earned wisdom. That leads us to data hygiene, access control, and lineage, because AI does not fix garbage data, it exposes it. We cover keeping context fresh, why a confidently wrong AI is worse than no AI, and why curation beats volume when tokens are the currency of large language models. We close on data migration, version control for your schema with tools like Flyway and Liquibase, data validation, and the case for smaller local models fed the right context. Data is the backbone of everything we build, even in the age of AI.__________________________________________________Key Highlights🚀 Deploy Versus Release: Spotify reportedly ships around 4,500 production deploys a day with 73 percent of pull requests AI assisted, which opens a great conversation about why a deploy is not the same thing as a release.🛑 Pump the Brakes on Coding Is Solved: Ford rehired more than 300 veteran engineers after AI failed to match decades of expertise, a reminder that new tools boost productivity but do not remove the need for engineers in the loop.🗂️ Context Engineering, Defined: We reframe the buzzword as a data fundamental, where prompt engineering is how you ask and context engineering is what the model knows when you ask, using the desk and filing cabinet analogy.🧹 AI Exposes Garbage Data: If you have skipped access control, lineage, and data hygiene, AI will not solve that for you, it will shine a bright light on the disciplines you skipped earlier.📦 Structured Versus Unstructured Data: We break down the two main data types and why the proliferation of data stores means picking the right tool for the job instead of copying whatever Twitter or Netflix did.🔄 Migrating and Versioning Data: From big bang versus phased migrations to schema version control with Flyway and Liquibase, we cover the fundamentals that keep data changes safe and repeatable.🎯 Curation Beats Volume: More context is not always better. Because tokens are the currency of large language models, feeding a smaller local model the right curated context often beats reaching for the biggest frontier model.__________________________________________________Resources & Next Steps📘 Fundamentals of Software Engineering: From Coder to Engineer, the book behind the show, available on O'Reilly and Amazon.🌐 FundamentalsofSWE.com, the home for the book and the podcast.🧠 NotebookLM, a Google tool for building a curated, specialized model around your own documents.🛠️ Flyway and Liquibase, tools for version controlling database schema changes.🎧 Subscribe to Fundamentals of Software Engineering on Apple Podcasts__________________________________________________Chapter Timestamps00:00 Cold open, deploy versus release and pump the brakes01:02 Welcome and what this episode covers03:47 Podcast and book intro, Fundamentals of Software Engineering05:15 Data as the old priesthood, DBAs and data models06:47 News, Spotify's 4,500 deploys a day and 73 percent AI assisted PRs08:00 Deploy versus release explained11:06 News, Ford rehires veteran engineers after AI falls short12:06 Why you still need experts in the loop13:33 Domain knowledge AI cannot replace16:21 Data fundamentals, data outlives the systems19:25 Prompt engineering versus context engineering21:01 Context engineering defined, the desk and the filing cabinet22:48 Garbage data, access control and hygiene23:16 Structured versus unstructured data24:34 Proliferation of data stores and the right tool for the job27:24 Supplying context, prompt stuffing, RAG and tools31:03 Keeping context fresh, a confidently wrong AI is worse than no AI33:31 Data migration, big bang versus phased37:59 Version control for data with Flyway and Liquibase41:55 Data validation and guarding against bad input45:54 Curation beats volume and tokens are the currency of LLMs51:56 Smaller local models, curated context, and a dad joke to close

In this episode of Fundamentals of Software Engineering, Nate and I dig into the reality of working remotely and push back on a viral clip claiming that remote work is nothing more than white collar fraud. Drawing on nearly a decade of remote experience, we unpack why that argument glosses over the distractions of the office, the daily stress of the commute, and the return to office mandates pushed by leaders who rarely make that commute themselves. We also get honest about the parts that are genuinely hard, including the blurred lines between work and home and the tendency to work longer hours when the laptop is always a few steps away. Along the way we talk about the discipline remote work demands and why the pandemic era of remote work was a very different beast from where we are today.From there we get into an article by computer scientist and author Cal Newport on a pattern he calls doom trolling, the habit of loudly warning that AI could end the world while shrugging that nothing can be done about it. We walk through his Ford F-150 analogy, question the AGI hype and the extraordinary claims that rarely get challenged, and ask the question that cuts through a lot of it: who benefits from this messaging. We connect that to the mental health of developers who keep hearing they are about to be replaced, and we make the case that more software in the world means more need for software engineers, not less. The throughline is a familiar one for us: stay skeptical, adapt to change, and remember that the fundamentals matter more than ever.__________________________________________________Key Highlights🏠 Remote work is not white collar fraud: We respond to a viral clip calling remote work a fraud and explain why it ignores office distractions, commute costs, and the realities of daycare and family life.🚗 The commute is the least productive hour: Nate makes the case that the daily commute, anywhere from 25 minutes to over an hour, is wasted time that return to office mandates quietly ignore.⚖️ Blurred lines and longer hours: We get honest about the real downside of working from home, where the boundary between work and home disappears and the day often stretches later than it ever did in the office.👀 The always on Zoom window: We react to the idea of keeping every team member on a live call all day and argue that managing by output beats watching for butts in seats.🧠 The real cost of interruptions: Knowledge work means loading a hard problem into your head, and a two minute interruption can cost twenty or thirty minutes of lost focus.🔥 Cal Newport and doom trolling: We break down Cal Newport's Ford F-150 catching fire analogy and why so much AI doom messaging is a choice rather than a sober warning.💼 Follow the incentives behind the hype: We trace the money behind sky high AI valuations, note Ford quietly rehiring the engineers it replaced, and remind developers to consider the source before believing they are about to be replaced.__________________________________________________Resources & Next Steps📘 Fundamentals of Software Engineering, the book by Dan Vega and Nate Schutta, available from O'Reilly and Amazon and now translated into Korean and Portuguese🌐 Learn more about the book and the podcast at FundamentalsofSWE.com✍️ Cal Newport, computer scientist and author, and his writing on doom trolling and deep work🎧 Subscribe to Fundamentals of Software Engineering on Apple Podcasts__________________________________________________YouTube Chapter Timestamps00:00 Cold open on golf, remote work, and AI doom trolling01:05 Meet your hosts and today's topics07:39 Teasing the Cal Newport doom trolling article08:00 Book news, translations, and fall conferences09:12 A viral clip calls remote work white collar fraud10:11 Reacting to the white collar fraud argument11:27 Why the commute is the least productive part of the day11:58 Return to office mandates from leaders who do not commute12:47 The discipline that remote work requires13:24 Blurred lines and working longer hours from home14:54 Pandemic remote work versus remote work today16:12 Companies reversing course on remote work38:25 The always on Zoom window and whether it is surveillance40:25 The real cost of breaking deep focus41:54 Introducing Cal Newport and the idea of doom trolling43:03 The Ford F-150 catching fire analogy43:51 AGI best case, extinction worst case, and the hypocrisy46:51 Ford rehires the engineers it replaced with AI48:55 AI valuations and when the bubble might burst49:30 Mental health for developers and who to trust50:35 More software means more software engineers51:51 Adapting to change and why the fundamentals matter more

In this episode of Fundamentals of Software Engineering, Nate and I dig into the increasingly tense overlap between open source maintainers and the new wave of AI-generated contributions. We start with the policies maintainers are putting in place to refuse AI-driven pull requests, and why a flood of low-signal 50,000 line diffs is genuinely threatening the open-source contribution model. From there we get into the patterns we're seeing in the wild: code that compiles but solves the wrong problem, the trouble AI has actually deleting code, and the way junior engineers can lean on AI in a way that hollows out the deeper learning that builds real engineering judgment.From there, Nate and I get into the commercial pressure building underneath all of this. We talk about the Silicon Valley loss-leader playbook, why current AI tooling pricing is almost certainly going to climb sharply once teams are dependent on it, and what that means for engineering organizations who have built their workflows around a tool that may not stay this cheap. We also talk about what good practice looks like when you're using AI day to day, where you should still be writing the code yourself, and how to keep your sharpness as an engineer while these tools keep evolving.__________________________________________________Key Highlights🚫 Maintainers Saying No to AI PRs: Some open source maintainers have explicitly banned AI-generated pull requests, and we look at why this matters for the future of community contributions.📈 The 50,000 Line Diff Problem: Students are now submitting massive AI-generated diffs that overwhelm reviewers, and we discuss why volume without judgment hurts everyone in the loop.🗑️ AI Is Bad at Deleting Code: One of the consistent weaknesses in current AI tooling is removing unused or stale code. We talk about why you have to push it in that direction explicitly.💸 The Darth Vader Moment in AI Pricing: Current AI tooling follows the Silicon Valley playbook: cheap to get you hooked, then prices climb. We dig into what that means for teams who've built workflows around current rates.🧠 Engineering Judgment Still Matters Most: AI accelerates output but does not replace deep understanding. We talk about how to use the tools without letting them erode your engineering instincts.🛡️ Defenders Need Perfection, Attackers Need One Door: The asymmetry of security and reliability is sharper than ever when AI is generating code at scale, and we explore the implications for production systems.🎙️ Where the Conversation Goes Next: We close with where we think AI tooling and open source collide over the next year, and what engineers should be paying attention to right now.__________________________________________________Resources & Next Steps🎧 Subscribe to Fundamentals of Software Engineering on Apple Podcasts__________________________________________________Chapter Timestamps00:00 Cold open and intro01:00 Welcome to episode 8, open source and the AI token crisis03:00 Why maintainers are banning AI pull requests06:00 The 50,000 line diff problem10:00 AI struggles with deleting code14:00 How junior engineers should be using AI18:00 AI generated code that compiles but solves the wrong problem22:00 Where AI tooling is genuinely useful today26:00 Defenders need perfection, attackers need one door30:00 The Silicon Valley loss leader pricing playbook34:00 What happens when AI tooling prices climb38:00 How to keep your engineering judgment sharp42:00 Why open source matters more, not less, in this moment46:00 The patterns we are watching in the next year52:00 Closing thoughts and where the field goes next59:00 Dad jokes and Father's Day wrap

In this episode of Fundamentals of Software Engineering, Nate and I dig into the love hate relationship every developer has with the inherited code base. We unpack what actually makes code 'legacy', why working with it feels so painful, and the strategies that turn it from a burden into something you can confidently change. From Mike Feathers' definition ('legacy code is code without tests') to the realization that your code today will be someone else's legacy code tomorrow, we cover the full spectrum of why this stuff trips up even seasoned developers and what actually moves the needle.We get into the rewrite trap (and why YOLO big bang rewrites usually backfire), the strangler fig pattern that has saved countless modernizations, and how AI is finally turning the years long mainframe migration into something realistic. We also talk about scout rule refactoring, the fresh perspective new joiners bring (and why managers should actually listen), the soft skills side that nobody warned us about, and what empathy for past developers looks like in practice. If you have ever opened a code base, thought 'what idiot wrote this?', and then realized it was you, this one is for you.Key Highlights🔍 What Counts as Legacy: Mike Feathers' definition is code without tests, but functionally it's anything you didn't write within the last couple of hours. Even your code becomes legacy faster than you think.🛠️ The Rewrite Trap: Big bang cutovers are stressful, risky, and usually reintroduce edge cases that took years to fix. The strangler fig pattern lets you replace systems thin slice by thin slice with continuous demoable progress.🤖 AI as a Modernization Force Multiplier: AI lowers the cost and risk of mainframe migrations and makes interrogating commit history at scale realistic. Use it to summarize code intent, surface edge cases, and answer the questions human patience won't.🧠 The Missing Context Problem: The original developers retired, the why is gone, and only the what remains. Tribal knowledge walks out the door. That's the real challenge, not the syntax.📋 The Edge Case Iceberg: Happy path is easy. The real complexity lives in last day of the month, mid year changes, timezone quirks, and the goofy combinations of dates and times. If those are not tested or documented, the rewrite will reintroduce them.🌱 Fresh Perspective Is a Superpower: New joiners can challenge 'that's how we've always done it' assumptions that seasoned engineers no longer notice. Dan shares a real story of parallelizing an overnight batch job by simply asking 'does it have to be sequential?'🧹 Scout Rule Refactoring: Always leave the code better than you found it. Better variable names, smaller methods, dead code removal, missing documentation. Small daily improvements compound into a maintainable system.📈 Your Code Today Is Tomorrow's Legacy: Write the tests. Document the edge cases. Leave the breadcrumbs. The future maintainer might be you, and you will not remember why you made any of those decisions.Resources & Next Steps📘 Fundamentals of Software Engineering (book), now in Portuguese and Korean translation🌐 fundamentalsofswe.com (book + podcast hub)👥 Mike Feathers, Working Effectively With Legacy Code (definition source)📐 Strangler Fig Pattern, Martin Fowler🎧 Subscribe to Fundamentals of Software Engineering on Apple PodcastsChapter Timestamps00:00 Cold Open, When the Idiot Code Turns Out to Be Yours00:54 Welcome to Episode 702:33 Fundamentals of SE Now in Portuguese and Korean04:05 What Counts as Legacy Code06:48 Why Greenfield Feels So Good09:11 Legacy Doesn't Mean Bad10:41 App Modernization as a Career11:51 Getting Off the Mainframe in the AI Era15:25 Missing Context (the Why Is Gone)17:36 Fear of Breaking What You Don't Understand18:17 Mike Feathers and Why Tests Slow You Down Less Than You Think22:08 Getting Maintenance Time Approved25:01 Outdated Dependencies and the 1962 Car Analogy28:06 Tribal Knowledge Walks Out the Door32:14 The Rewrite Trap and YOLO Big Bang Cutovers39:48 The Strangler Fig Pattern42:00 Working in Unfamiliar Code47:00 Fresh Perspective as a Superpower50:23 The Scout Rule (Leave It Better Than You Found It)52:24 Comments, Refactoring, and Naming53:29 Empathy for Past Developers55:03 Your Code Today Is Tomorrow's Legacy59:08 Closing Thoughts (and a Dad Joke)

In this episode of Fundamentals of Software Engineering, Nate and I dig into what we learned at the Arc of AI conference in Austin. We discuss the big conversations happening around AI-generated code in production, why vibe coding falls apart at scale, and how tools that let developers move faster can also get them off course just as quickly. From an AI agent that tried to delete production to 50,000-line diffs that no human can realistically review, we explore the real risks showing up as teams adopt these tools.We also get into the durability of code, whether we'll eventually stop writing human-readable code altogether, and why evals for AI-generated code are something most teams are skipping at their peril. A recurring theme is that typing has never been the hard part of software. The fundamentals (testing, code review, architectural thinking, and understanding what code shouldn't do) matter even more now that we can produce code faster than ever. If you're feeling anxiety about AI replacing developers, this conversation is for you.Key Highlights💻 Code Is Cheap, Software Is Expensive: AI excels at generating behavior, but the architectural qualities and non-functional requirements that make code into software still require human expertise.🔐 The Authorization Bug: An AI agent commented out authentication code because it lacked the right role in dev. The kind of mistake a human reviewer catches instantly, but one that could slip through a 50,000-line diff unnoticed.🏗️ 200,000 Lines of Vibe Code: When someone asked Dan to review their vibe-coded app, it was 200,000 lines. Finding a bug in that is like being dropped into a massive enterprise codebase on day one with zero context.🤖 AWS Agent Gone Rogue: An agent tasked with fixing a critical production issue decided the best approach was to delete production and start from scratch. Any human would have vetoed that immediately.⚡ Moving Fast Safely: Like an F1 driver at 200 mph, moving faster in software development means being off course by even a small margin can put you miles from your target. More speed demands more frequent feedback loops.🧪 Evals Over Vibes: When switching AI models in production, "vibe testing" isn't enough. Proper evals are essential to verify that behavior remains consistent across model updates and prompt changes.📖 The Testing Paradox: You can write tests for what code should do, but you can't easily test for what it shouldn't do. AI-generated code may introduce unexpected behavior that no one thought to test for.Resources & Next Steps🎤 Arc of AI Conference (Austin, TX)📕 Fundamentals of Software Engineering in the Age of AI (workshop by Dan Vega and Nate Schutta)🎧 Subscribe to Fundamentals of Software Engineering on Apple PodcastsChapter Timestamps00:00 Introduction and welcome back01:30 Recap of the Arc of AI conference in Austin04:00 A power outage, elevators, and conferencing by candlelight07:30 Overview of talks, workshops, and hallway conversations09:00 The eight hour workshop on fundamentals in the age of AI11:00 Code is cheap, software is expensive13:00 Vibe coding at low stakes vs. enterprise software16:00 Developer anxiety and the real role of a software engineer18:00 200,000 lines of vibe coded code nobody can review20:00 50,000 line diffs and the authorization bug23:00 The AWS agent that tried to delete production26:00 Is code going to be durable or constantly regenerated?30:00 Will we stop writing human readable code?34:00 The testing paradox and what code shouldn't do37:00 Can AI replace CEOs? Black Swans and human intuition40:00 AI as productivity enhancer, not job replacement44:00 Evals vs. vibe testing in production AI systems48:00 Relearning lessons of the past in software engineering52:00 Moving fast safely and the F1 analogy56:00 Feedback loops, staying on course, and closing thoughts

In this episode of Fundamentals of Software Engineering, we dive deep into the diverse career paths available to software engineers beyond just writing code. Many engineers start their careers thinking the only options are coding until retirement or eventually becoming a manager, but the reality is far more exciting. We explore how the tech industry offers numerous opportunities that combine technical skills, creativity, and professional growth. From individual contributor tracks to specialized roles in developer advocacy, consulting, entrepreneurship, and more, we break down what each path looks like and how to know which one might be right for you.Drawing inspiration from Chapter 14 of our book, I share personal experiences about discovering my passion for teaching and content creation while Nate reflects on his journey into developer advocacy and speaking. We discuss the importance of paying attention to what energizes you in your daily work, whether that's solving complex technical problems, mentoring others, building products, or communicating ideas. We also emphasize that your interests will evolve over time, and that's perfectly normal. The key is staying open to opportunities, being willing to try new things, and not being afraid to pivot when something doesn't feel like the right fit.________________________________________Key Highlights:💼 Individual Contributor vs. Management Track: We break down the two primary career paths in software engineering and explain how the individual contributor (IC) track allows engineers to grow technically without managing people, reaching senior levels like Staff, Principal, and Distinguished Engineer.🎤 Developer Advocacy and Community Building: Learn how developer advocates bridge the gap between companies and developer communities through content creation, speaking, and building relationships. This role combines technical expertise with communication skills and offers a unique way to impact the industry.📚 Teaching and Content Creation: Discover how creating courses, writing technical content, and teaching others can become a fulfilling career path. We discuss how the saying 'to teach something, you have to learn it twice' reinforces your own technical knowledge while helping others.🏢 Consulting and Freelancing: Explore the world of independent consulting where you solve diverse problems for different clients, build variety into your work, and have more control over your schedule and projects.🚀 Entrepreneurship and Building Products: We examine how engineers can leverage their technical skills to build their own products and companies, especially in this AI-powered era where the barriers to entry have been significantly lowered.🔍 Following Your Passions: Throughout the episode, we emphasize the importance of paying attention to what energizes you, following those indicators early in your career, and not being afraid to advocate for the things you're passionate about without waiting for permission.💡 Empathy in Engineering: We discuss how understanding who your applications are helping and putting yourself in other people's shoes can make even the most mundane projects more meaningful and rewarding.________________________________________Resources & Next Steps:🌐 Learn more about the Fundamentals of Software Engineering book and get your copy📖 Purchase the book on Amazon or access it through the O'Reilly platform🎧 Subscribe to the Fundamentals of Software Engineering podcast for more episodes⭐ Leave a review on Amazon to help other engineers discover the book and share your feedback with Dan and Nate________________________________________Chapter Timestamps:00:00:00 - Introduction and Steve Jobs Quote00:01:10 - Episode 5: Career Paths for Software Engineers00:03:00 - Book Overview and Chapter 14 Introduction00:05:00 - Beyond Just Coding: Understanding Career Options00:06:00 - Early Career Perspectives on Career Paths00:15:00 - Individual Contributor Track Explained00:25:00 - Management Track and Leadership Roles00:35:00 - Developer Advocacy and Community Work00:45:00 - Teaching, Content Creation, and Education00:52:00 - Consulting and Freelancing Opportunities00:58:00 - Entrepreneurship and Building Your Own Products01:01:00 - Key Takeaways and Following Your Passions01:03:00 - Final Thoughts and Dad Joke01:04:00 - Wrap Up and Call to Action

We kicked off Episode 4 by tackling something every developer faces but rarely masters: learning to learn. In our industry, the technology changes constantly, and staying relevant means embracing a lifetime of learning. Nate and I dove into how successful engineers aren't just smart, they're insatiably curious. We talked about moving past the misconception that learning ends with school and recognizing that failure is part of the process. Whether you're debugging code or picking up a new framework, being comfortable with not knowing everything is what separates the good from the great. We also emphasized that everyone has their own learning style, and finding yours is key to making knowledge stick.The episode also explored practical strategies for staying sharp without burning out. We discussed the dangers of the shiny new thing paradox, where developers chase every hot technology without asking why. Instead, we encouraged building a technology radar, being deliberate about what you learn, and understanding that consistency beats intensity every time. A little bit each day, whether it's 20 minutes of reading or working on a side project, compounds into serious growth over time. We wrapped up by reminding everyone that FOMO is real, but you don't need to learn everything. Focus on what aligns with your career goals and what genuinely excites you, and you'll be just fine.Key Highlights:🧠 Learning Never Stops: School teaches us that learning is finite, but in software engineering, successful developers maintain an insatiable curiosity throughout their careers. The key is embracing the mindset that you don't need to know everything, and being comfortable saying, "Tell me more about that."✨ The Shiny New Thing Paradox: Just because a new technology is hyped doesn't mean you need to learn it. We discussed resume-driven design and how developers often adopt bleeding-edge tools without understanding the full trade-offs. The key is knowing not just when to use a tool, but when not to use it.📡 Build Your Technology Radar: Inspired by ThoughtWorks, a technology radar helps you methodically track technologies across four rings, from "hold" (avoid or phase out) to "adopt" (use now). This framework lets you see where to invest your learning time and helps you be planful rather than reactive to every new trend.🔥 Consistency Over Intensity: New Year's resolutions fail because people set unrealistic goals. Instead of promising to work out 90 minutes daily, commit to 5-10 minutes of reading or coding each day. Small, sustainable habits compound into serious growth over time, just like Nate's nearly 900-day reading streak.🎯 Start With Your Why: Before diving into GraphQL, Kubernetes, or any hyped technology, ask yourself why you want to learn it. Does it solve a problem you're facing? Does it align with your career goals? Learning with purpose prevents you from wasting time on tools you'll never use.🚀 Side Projects Are Learning Labs: If your day job restricts your tech stack, side projects let you experiment guilt-free. Dan shared how he built his personal website with Vue, Nuxt, and Tailwind to learn front-end skills outside his Spring and Java work. It's the right tool for the right job, plus it scratches a personal itch.🤝 Show Up and Soak It In: Even if a meetup or lunch-and-learn isn't on your immediate learning list, attending can be valuable. You might pick up a keyboard shortcut, discover a new tool, or make a connection that changes your career. Plus, free pizza and getting out of your house never hurt anyone.Resources & Next Steps:📖 Order Fundamentals of Software Engineering on O'Reilly or Amazon🎧 Subscribe to the Fundamentals of Software Engineering podcast📡 Explore the ThoughtWorks Technology Radar to build your own learning framework🏂 Connect with Dan Vega and Nate Schutta on social media for more learning tips and industry insightsTimestamps:0:00 Introduction and New Year Mindset0:59 Episode 4: Learning to Learn2:44 The Myth That Learning Ends After School3:19 Curiosity and the Tinkering Mindset5:05 Signing Up for a Lifetime of Learning6:47 Learning Through Failure9:09 Finding Your Personal Learning Style11:38 The Trap of Video Tutorials Without Practice14:40 AI as a Learning Tool, Not a Shortcut15:36 Dealing with an Overwhelming Number of Things to Learn18:22 The Shiny New Thing Paradox21:05 Staying Long Enough to See the Consequences of Your Decisions23:12 Using ADRs (Architectural Decision Records)26:00 FOMO and Side Projects29:05 Portfolio Theory for Technology Skills32:03 Building a Technology Radar35:25 Starting with Your Why38:25 Don't Over-Engineer for Problems You Don't Have41:48 Dan's Personal Website Example: Right Tool for the Right Job44:15 Consistency Over Intensity45:45 Morning Coffee: A Daily Learning Ritual48:49 Weekly, Monthly, and Yearly Learning Goals50:37 Learning Depth Strategy: Survey, Dive, Deep Dive, Ultra-Deep Dive52:10 Attending Meetups and Lunch-and-Learns55:04 Wrap-Up and Coffee Joke