『Fundamentals of Software Engineering』のカバーアート

Fundamentals of Software Engineering

Fundamentals of Software Engineering

著者： Dan Vega Nate Schutta
無料で聴く

【Amazonプライム会員限定】今ならプレミアムプランが4か月 月額99円。

10月19日まで。※適用条件あり
Programmer, coder, developer—there are any number of titles used to describe people who create software, but what does it mean to be a software engineer? Despite the way software is often taught, being a software engineer is about far more than simply producing syntactically correct programs.© 2026 Dan Vega, Nate Schutta
エピソード
  • E12 - How Developers Can Start Speaking at Conferences

    E12 - How Developers Can Start Speaking at Conferences
    2026/09/16
    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
    続きを読む 一部表示
    54 分
  • E11 - What Is Software Architecture

    E11 - What Is Software Architecture
    2026/08/22
    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
    続きを読む 一部表示
    1 時間 1 分
  • E10 - Context Engineering Is Just Data Fundamentals in Disguise

    E10 - Context Engineering Is Just Data Fundamentals in Disguise
    2026/07/13
    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...
    続きを読む 一部表示
    57 分
adbl_web_anon_alc_button_suppression_t1
まだレビューはありません