Show Notes
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 Timestamps
00:00 Recording live from the conference floor 01:30 Why a mixed conference beats one full of your own crowd 04:30 Nobody goes from zero to keynoting 06:00 Volunteer to speak on what you want to learn 07:30 Lunch and learns, meetups, and book clubs as a first step 09:00 Handling questions, including the ones you cannot answer 10:30 Finding your own presenting style 12:00 Telling the audience what they are getting into 13:30 Submitting on a topic you have not learned yet 15:00 Writing an abstract around one hook 16:30 One idea is one talk 18:00 What committees see: hundreds of submissions, few slots 19:30 When the font keeps shrinking, the words are in the wrong place 21:00 Slides that try to be a handout serve nobody 22:30 The nig
More from 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
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.
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.
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.
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