Fundamentals of Software Engineering

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 Timestamps

00:00 Cold open: reading Carnegie is as useful as another framework

03:19 Conference season: what is coming up

06:53 Dev2Next and Venkat's conferences

07:36 QCon San Francisco and some good news

09:31 Today's topic, and where to find the book

10:28 Why one chapter on architecture was never going to be enough

11:36 Three shelves of architecture books and what they have in common

13:31 By the time the question reaches you, the easy answers are gone

14:30 Architecture is the things you can't Google

16:43 Knowing which questions to ask, and how to get answers

18:36 Does this problem actually require Kafka

20:34 Structure, teams and what architecture you can realistically run

23:21 Architectural malpractice, defined

24:43 Designing for scale you do not have yet

27:23 AI on the JVM, and not replatforming a team to chase a library

28:48 New leadership, rewrites, and the defects you carry across

31:34 Who should be an architect these days

34:45 Where design ends and architecture begins

42:29 Evolutionary architecture and fitness functions

46:23 The ilities, quality attributes and real trade-offs

55: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 Timestamps

00:00 Cold open, deploy versus release and pump the brakes

01:02 Welcome and what this episode covers

03:47 Podcast and book intro, Fundamentals of Software Engineering

05:15 Data as the old priesthood, DBAs and data models

06:47 News, Spotify's 4,500 deploys a day and 73 percent AI assisted PRs

08:00 Deploy versus release explained

11:06 News, Ford rehires veteran engineers after AI falls short

12:06 Why you still need experts in the loop

13:33 Domain knowledge AI cannot replace

16:21 Data fundamentals, data outlives the systems

19:25 Prompt engineering versus context engineering

21:01 Context engineering defined, the desk and the filing cabinet

22:48 Garbage data, access control and hygiene

23:16 Structured versus unstructured data

24:34 Proliferation of data stores and the right tool for the job

27:24 Supplying context, prompt stuffing, RAG and tools

31:03 Keeping context fresh, a confidently wrong AI is worse than no AI

33:31 Data migration, big bang versus phased

37:59 Version control for data with Flyway and Liquibase

41:55 Data validation and guarding against bad input

45:54 Curation beats volume and tokens are the currency of LLMs

51: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 Timestamps

00:00 Cold open on golf, remote work, and AI doom trolling

01:05 Meet your hosts and today's topics

07:39 Teasing the Cal Newport doom trolling article

08:00 Book news, translations, and fall conferences

09:12 A viral clip calls remote work white collar fraud

10:11 Reacting to the white collar fraud argument

11:27 Why the commute is the least productive part of the day

11:58 Return to office mandates from leaders who do not commute

12:47 The discipline that remote work requires

13:24 Blurred lines and working longer hours from home

14:54 Pandemic remote work versus remote work today

16:12 Companies reversing course on remote work

38:25 The always on Zoom window and whether it is surveillance

40:25 The real cost of breaking deep focus

41:54 Introducing Cal Newport and the idea of doom trolling

43:03 The Ford F-150 catching fire analogy

43:51 AGI best case, extinction worst case, and the hypocrisy

46:51 Ford rehires the engineers it replaced with AI

48:55 AI valuations and when the bubble might burst

49:30 Mental health for developers and who to trust

50:35 More software means more software engineers

51: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 Timestamps
00:00 Cold open and intro
01:00 Welcome to episode 8, open source and the AI token crisis
03:00 Why maintainers are banning AI pull requests
06:00 The 50,000 line diff problem
10:00 AI struggles with deleting code
14:00 How junior engineers should be using AI
18:00 AI generated code that compiles but solves the wrong problem
22:00 Where AI tooling is genuinely useful today
26:00 Defenders need perfection, attackers need one door
30:00 The Silicon Valley loss leader pricing playbook
34:00 What happens when AI tooling prices climb
38:00 How to keep your engineering judgment sharp
42:00 Why open source matters more, not less, in this moment
46:00 The patterns we are watching in the next year
52:00 Closing thoughts and where the field goes next
59: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 Podcasts
Chapter Timestamps
00:00 Cold Open, When the Idiot Code Turns Out to Be Yours
00:54 Welcome to Episode 7
02:33 Fundamentals of SE Now in Portuguese and Korean
04:05 What Counts as Legacy Code
06:48 Why Greenfield Feels So Good
09:11 Legacy Doesn't Mean Bad
10:41 App Modernization as a Career
11:51 Getting Off the Mainframe in the AI Era
15:25 Missing Context (the Why Is Gone)
17:36 Fear of Breaking What You Don't Understand
18:17 Mike Feathers and Why Tests Slow You Down Less Than You Think
22:08 Getting Maintenance Time Approved
25:01 Outdated Dependencies and the 1962 Car Analogy
28:06 Tribal Knowledge Walks Out the Door
32:14 The Rewrite Trap and YOLO Big Bang Cutovers
39:48 The Strangler Fig Pattern
42:00 Working in Unfamiliar Code
47:00 Fresh Perspective as a Superpower
50:23 The Scout Rule (Leave It Better Than You Found It)
52:24 Comments, Refactoring, and Naming
53:29 Empathy for Past Developers
55:03 Your Code Today Is Tomorrow's Legacy
59:08 Closing Thoughts (and a Dad Joke)