Show Notes
Launching the Fundamentals of Software Engineering Podcast with Dan Vega and Nate Schutta We are thrilled to introduce Episode One of the Fundamentals of Software Engineering podcast. In this inaugural episode, we share the origin story of how this book and podcast came to be, starting with a simple tweet about goals for the year. I talk about how Nate responded to my tweet saying he could help with at least two of my goals, and that's when our collaboration began. We dive into the challenges of writing a technical book, from multiple rounds of editing to finding the right balance between comprehensive coverage and keeping content accessible. We also discuss why we decided to launch this podcast as a companion to the book, allowing us to explore topics we couldn't fit into the manuscript and go deeper on subjects that matter most to software engineers at every stage of their career. Throughout this episode, Nate and I introduce ourselves, share our backgrounds, and talk about what gets us excited about this industry. From my early days falling in love with web development to Nate's transition from chemistry to computer science, we reflect on our journeys and the lessons we've learned along the way. We talk candidly about imposter syndrome, the importance of learning to learn, and why reading code is often more important than writing it. We also touch on our shared passion for golf, spending time with family, and maintaining a healthy work-life balance in an industry that never stops evolving. This podcast is for anyone who wants to level up their software engineering skills, whether you're just starting out or have years of experience under your belt. Join us as we explore the fundamentals that make great software engineers and help you navigate your career with confidence. _______________________________________________________________________________ Key Highlights: 📖 The Book's Origin Story: How a tweet about New Year's goals sparked a collaboration between Dan and Nate, leading to the creation of Fundamentals of Software Engineering. We discuss how the book evolved from Nate's initial online training sessions to a comprehensive guide covering essential topics that aren't always taught in traditional education. 🎯 Bridging the Education Gap: We explore the significant differences between what's taught in universities, bootcamps, and what you actually need to know on the job. Whether you have a four-year degree focused on theory or completed a 14-week intensive bootcamp, there's always a learning curve when joining a real development team. Our book aims to fill that gap and provide the institutional knowledge that helps new engineers become productive faster. 📚 Reading Code Over Writing Code: One of the most fundamental yet overlooked skills in software engineering is the ability to read and understand code. We emphasize that engineers spend far more time reading existing code than writing new code, especially in an era where AI-generated code is becoming more prevalent. Learning to navigate unfamiliar codebases, identify patterns, and understand legacy systems is crucial for career success. 🎤 From Introverts to Conference Speakers: We share our personal journeys from being uncomfortable with public speaking to becoming regular conference presenters. Many assume all speakers are extroverts, but most of the people we know in the conference circuit are actually introverted. We encourage anyone interested in speaking to start with local user groups and remember that you have a unique perspective worth sharing, regardless of your experience level. 🧠 Learning to Learn in Tech: The technology landscape changes constantly, and what worked five years ago might be obsolete today. We discuss the importance of developing meta-learning skills and understanding that you're signing up for a lifetime of continuous learning when you enter this industry. The key is not trying to learn everything but rather developing strategies to learn effic
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 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. __________________________________________________
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.