The Agile Embedded Podcast

Luca Ingianni, Jeff Gable

Learn how to get your embedded device to market faster AND with higher quality. Join Luca Ingianni and Jeff Gable as they discuss how agile methodologies apply to embedded systems development, with a particular focus on safety-critical industries such as medical devices.

  1. APR 15

    E94 Requirements Engineering, part 1: Fundamentals

    Requirements Engineering Fundamentals - Part 1 We kick off a multi-part series on requirements engineering by exploring what requirements actually are and why they matter - even for Agilists. Jeff shares his medical device expertise while Luca brings his automotive and aerospace background to discuss the different levels of requirements (from high-level user needs to testable system requirements), the importance of traceability, and why proper tooling beats Word and Excel every time. We dig into practical aspects like the EARS format for writing requirements, the crucial distinction between requirements and design choices, and why glossaries aren't as boring as they sound. Along the way, we tackle the tension between regulatory compliance and actual engineering value, emphasizing that documentation should be an artifact of diligent work - not the work itself. Whether you're in safety-critical industries or just want to build better products, understanding requirements engineering helps manage complexity and prevent costly mistakes. Key Topics [02:30] What is requirements engineering and why it matters beyond safety-critical industries [06:45] Don't Agilists hate requirements? Debunking the myth and discussing iteration vs. waterfall [11:20] The hierarchy of requirements: user needs, system requirements, and subsystem requirements [18:00] Requirements vs. design choices: where to draw the line and why it matters for testing [24:15] Writing good requirements: EARS format, must vs. shall vs. may, and the value of glossaries [32:40] Traceability: linking requirements across levels and to test cases [40:30] Why Word and Excel don't cut it: the case for proper requirements management tools [48:20] Risk analysis and mitigation in safety-critical development [52:00] Documentation as artifact of diligent work, not the work itself Notable Quotes "The whole agile movement was a reaction to the one time through the requirements specification build test loop that took several years. By the time you got to the end, the requirements no longer applied." — Jeff "Do not use an LLM to manage requirements. Do use the LLM to write tools that help you manage requirements." — Luca "I view any medical device that I work on as if it's going to be used on my child. What do I need to do to convince myself that it is safe and effective? Once I have done that, if there are remaining boxes to check to get it through FDA, I will check those boxes." — Jeff Resources Mentioned EARS (Easy Approach to Requirements Syntax) - A grammar format for writing clear, verifiable requirements that constrains how requirements are written to reduce ambiguity FDA Guidance on Agile Development - Regulatory guidance describing how to do Agile development in medical device context ISO 26262 - Automotive safety standard mentioned as having similar traceability requirements to medical devices DO-178B - Aerospace software safety standard with similar requirements engineering principles You can find Jeff at https://jeffgable.com.You can find Luca at https://luca.engineer. Want to join the agile Embedded Slack? Click here Are you looking for embedded-focused trainings? Head to https://agileembedded.academy/Ryan Torvik and Luca have started the Embedded AI podcast, check it out at https://embeddedaipodcast.com/

    47 min

  2. APR 1

    Hardware-Software Co-Development with Tobias Kästner

    We talk with Tobias Kästner, a physicist-turned-software-architect and technical consultant at Inovex, about his journey from painfully slow hardware-software integration cycles to achieving three-week hardware sprints. Tobias shares hard-won lessons from medical device development, where fuzzy requirements and constant feedback from life scientists forced his team to rethink traditional approaches. The conversation centers on practical techniques: breaking monolithic PCB designs into modular "feature boards" connected via shields (think Arduino-style), using Git for hardware version control with SHA-1s printed on silkscreens, and leveraging tools like Zephyr RTOS to enable plug-and-play firmware that matches the modularity of the hardware. Tobias explains how relaxing constraints like board size and using automation to merge schematics allowed his team to iterate rapidly while maintaining a clear path to final form-factor designs. We discuss how this approach scaled to projects with 120+ people across multiple teams, and why the interplay between system architecture, organizational structure, and information flow matters more than most realize. Key Topics [02:30] The painful reality of traditional hardware development: six-month wait for hardware, nine months of debugging [08:00] Breaking apart monolithic PCB designs into modular feature boards with shield connectors [12:45] Relaxing constraints: larger board areas, autorouting, and prioritizing testability over final form factor [18:20] Version control for hardware: putting schematics in Git and printing SHA-1s on silkscreens [22:00] Using automation to merge feature board schematics into final form-factor designs [26:15] Firmware architecture: NuttX, Zephyr, KConfig, and device trees for modular, plug-and-play software [35:40] Scaling agile hardware-software co-development to 120+ person projects across multiple teams [39:00] The interplay of system architecture, organizational architecture, and information architecture Notable Quotes "When the board arrived, not a single line of code had been written for it because no one had been able to touch it. It took us nine additional months to debug all the things out of it." — Tobias Kästner "I've never seen any board working the first time. I've never seen any prototype without thin wires patching things out, but that's maybe a different story." — Tobias Kästner "We cannot think these architectures as independent of one another. If we have limitations in two of these architectures, we will see these limitations in the third architecture as well." — Tobias Kästner Resources Mentioned Inovex - Tobias's company offering engineering consulting services, trainings, and expertise in embedded systems, IoT, and full-stack development Zephyr RTOS - Open-source real-time operating system with KConfig, device tree support, and extensive driver library that Tobias recommends for modular firmware development NuttX RTOS - Apache Foundation RTOS with clean device driver model and KConfig support that Tobias used in earlier projects KiCad - Open-source PCB design software with emerging Python API support for schematic automation Services and Contact Through Inovex, Tobias provides trainings for both Zephyr and Yocto Linux, as well as consultancy and engineering support for embedded projects -- from 1-2 day workshops evaluating architectural state and cost/benefit analysis, to first prototypes, to full-fledged software development. With partners such as alpha-board (Berlin) and Blunk electronic (Erfurt), they also offer agile hardware services and help teams get started with the methods discussed in this episode. Email: tobias.kaestner@inovex.de Tobias Kästner on LinkedIn tobiaskaestner on the Zephyr Discord Channel Links Companies: Inovex -- Embedded Systems Blunk electronic alpha-board Navimatix Talks and publications: Modular and Agile HW Development (2018 talk) Leveraging Zephyr's HW Abstraction for Agile Systems Engineering (2023 talk) Whitepaper: Agile in der Hardware -- by Gregor Gross, Christoph Schmiedinger, and Tobias Kästner Leveraging Zephyr for Functional Architecture Decomposition (2025 talk) Books recommended by Tobias: Small Groups as Complex Systems -- Holly Arrow et al., SAGE Publications The Dao of Complexity -- Jean Boulton, DeGruyter You can find Jeff at https://jeffgable.com.You can find Luca at https://luca.engineer. Want to join the agile Embedded Slack? Click here Are you looking for embedded-focused trainings? Head to https://agileembedded.academy/Ryan Torvik and Luca have started the Embedded AI podcast, check it out at https://embeddedaipodcast.com/

    53 min

  3. MAR 18

    Test-Driven Development in the Age of AI

    We explore how test-driven development (TDD) remains essential—perhaps more than ever—when working with AI coding tools. Luca shares his evolved workflow using Claude Code, breaking down how he structures tests in three phases: test ideas, test outlines, and test implementations. We discuss why TDD provides the necessary control and confidence when AI generates code, how it prevents technical debt accumulation, and why tests serve as precise specifications for AI rather than afterthoughts. The conversation covers practical challenges like AI's tendency toward "success theater" (overly generous assertions), the importance of maintaining tight control over code quality, and why the bottleneck in AI-assisted development isn't code generation—it's expressing clear intent. We also touch on code spikes, large-scale refactorings, and why treating AI development as pair programming keeps you in the driver's seat. If you're wondering whether TDD still matters when AI writes your code, this episode makes a compelling case that it matters more than ever. Key Topics [02:30] Why TDD still matters with AI: confidence and control over generated code [06:45] Tests as specifications: describing desired behavior to AI rather than writing prompts [09:20] The three-phase test workflow: test ideas, test outlines, and implementations [15:30] Pair programming with AI: staying at the conceptual level while AI handles implementation [20:15] Code spikes and exploration: using AI to answer questions before writing production tests [24:40] AI failure modes: over-mocking and "success theater" with weak assertions [28:50] Large-scale refactorings: how AI excels at updating hundreds of tests simultaneously [32:10] The real bottleneck: expressing intent and specifications, not code generation speed Notable Quotes "As far as I am concerned, test-driven development is just about writing prompts for the AI that it can then use to build what you want it to build." — Luca "If you expect that a five-line prompt resulting in 10,000 lines of code will not result in 9,995 lines of uncertainty, you're just deluding yourself." — Luca "You can be five times faster than you were before and still maintain a very high production level quality code, but you probably can't be a hundred times faster." — Jeff Resources Mentioned Claude Code - Terminal-based AI coding assistant that Luca uses for TDD workflows, keeping conceptual work separate from code-level work Embedded AI Podcast - Luca's separate podcast focusing on AI in embedded systems, co-hosted with Ryan Torvik Luca's AI Training Courses - Hands-on trainings for using AI in embedded systems development (and much more!) links to all of Luca's work - Training, consulting, podcasts, conference talks and everything else You can find Jeff at https://jeffgable.com.You can find Luca at https://luca.engineer. Want to join the agile Embedded Slack? Click here Are you looking for embedded-focused trainings? Head to https://agileembedded.academy/Ryan Torvik and Luca have started the Embedded AI podcast, check it out at https://embeddedaipodcast.com/

    42 min

  4. MAR 4

    Engineering Organizations Part 2: Product Companies and Market-Driven Focus

    In this second part of our series on engineering organizations, Jeff and Luca explore how companies that build products should focus their efforts differently depending on their stage and scope. We start with startups and early-stage companies desperately searching for product-market fit, where the brutal truth is: quality doesn't matter yet. Your MVP should embarrass you—if it doesn't, you waited too long. We discuss the critical mental shift from throwaway prototypes to proper engineering once validation arrives, and why technical founders often fail by solving the wrong problem brilliantly. Moving up the ladder, we examine narrow-focus companies that have found their niche—like the German firm that does nothing but maintain a 100-year-old anchor chain machine, or specialists in medium-power electrical switches. These companies win through efficiency and deep expertise, but face existential risk if the market shifts. Finally, we tackle wide-focus companies introducing multiple product lines, where the challenge becomes running internal startups while managing established products, each requiring radically different approaches. The key insight: your focus must match your product's lifecycle stage, whether that's ruthless speed, cost optimization, or high-level process learning. Key Topics [02:30] Startups and early-stage companies: the existential search for product-market fit [06:45] The MVP philosophy: if you're not embarrassed, you waited too long [11:20] Quality vs. speed vs. scope: why quality doesn't matter in early stages [15:40] The Potemkin village approach: building facades to validate demand [19:15] Embedded products and MVPs: when physical products need creative shortcuts [23:50] The critical switch: from prototypes to proper engineering after validation [28:30] Narrow-focus companies: German hidden champions and deep specialization [34:10] Wide-focus companies: running internal startups within established organizations [40:25] Product teams and parallel focuses: managing different lifecycle stages simultaneously [45:00] Large established companies: high-level process learning and avoiding organizational weight Notable Quotes "If you read the Lean Startup, they will explicitly say: if you weren't embarrassed by your MVP, you waited too long. It really has to be painfully flimsy because you cannot afford to do it well." — Luca "Quality doesn't even factor because you're very explicitly building mock-ups from chewing gum and paper mache. They are fully intended to be thrown away." — Luca "Getting that product-market fit is existential. You will die if you do not get it and get it relatively quickly." — Jeff Resources Mentioned The Lean Startup - Eric Ries' book discussing MVP philosophy and the importance of being embarrassed by your first product The Mom Test - Rob Fitzpatrick's book about getting real customer feedback and validation through financial commitment The Art of Innovation - Tom Kelley's book on IDEO's design process, including the clothespin switch story Luca's Website - Trainings on embedded agile, AI in embedded systems, and more Jeff's Website - Consulting services for medical device software development You can find Jeff at https://jeffgable.com.You can find Luca at https://luca.engineer. Want to join the agile Embedded Slack? Click here Are you looking for embedded-focused trainings? Head to https://agileembedded.academy/Ryan Torvik and Luca have started the Embedded AI podcast, check it out at https://embeddedaipodcast.com/

    44 min

  5. FEB 18

    Engineering Organizations Pt 1: Service Firms - When You Are the Product

    In this first part of a two-part series, Jeff and Luca explore how different types of service-oriented engineering organizations should focus their learning and improvement efforts. Drawing from their consulting experience, they examine three distinct categories: product development firms that turn client ideas into reality, engineering development firms that sell specialized technical expertise, and solo engineers who package all necessary knowledge into one person. The core insight: what you should focus on learning depends entirely on what you're actually selling. Product development firms need to master the entire client journey and product design process, not just engineering excellence. Engineering development firms must become technical wizards in a specific domain that clients actually value. Solo engineers face the challenge of needing deep expertise while wearing every business hat. Across all three types, the common traps are the same: focusing too much on craft and too little on client experience, failing to specialize, and not investing enough in teaching as marketing. Throughout the discussion, Jeff and Luca emphasize that for service firms, you are the product - and that changes everything about where you should direct your improvement efforts. The conversation is grounded in real experiences, including some cautionary tales about firms that tried to be everything to everyone. Key Topics[00:00] Introduction: Two-part series on engineering organizations and their different focuses[02:30] Overview of the framework: Service firms vs. product-building companies[05:15] Product development firms: Why engineering excellence isn't enough[08:45] The critical importance of product design and client guidance over pure engineering[12:20] Process-level learning: Shortening cycle times and enabling rapid prototyping[15:40] The Irinos example: In-house board manufacturing to tighten feedback loops[18:30] Requirements will always change - designing for learning, not perfection[21:00] The danger of being a generalist: Why specialization matters for service firms[24:15] Engineering development firms: Selling technical expertise, not complete products[27:45] Technology-focused learning: Going deep on specific technical capabilities[30:20] The trap of becoming a commodity: Why domain expertise beats technology alone[33:40] The forklift invoice review example: You can't specialize too narrowly[35:30] Solo engineers: The complete package vs. temporary employee trap[39:00] Common failures across all service firms: Too much craft focus, too little client experience and marketing[41:30] Teaching as the best form of marketing for technical service firmsNotable Quotes"The customers don't actually hire them for their engineering skills. They are sort of a given. But what such a product development firm should offer the client is guiding them through the development process, which they don't have enough skills for to do it on their own." — Luca "Engineering is not the point. The unit of work is delivering a working product to the client that satisfies their business case, that has a reasonable cost to manufacture, and that you feel confident your own client has validated their market." — Jeff "It's not that engineering is irrelevant, but rather that it's table stakes. This is just taken for granted, but what such a product development firm should offer is guiding them through the development process." — Luca "You almost can't be narrow enough. I remember our friend Philip Morgan having this example of a company that specializes in reviewing invoices of forklift repairs. This is what they do. They review forklift repair invoices. And they're doing very well apparently." — Luca "Teaching and giving information and solving problems publicly is the best form of marketing. It's not advertising. It's building trust with an audience." — Jeff Resources MentionedIDEO - Prototypical design firm mentioned as an example of companies specializing in product designIRNAS - Product development firm with in-house board manufacturing capabilities, featured in previous episodes, exemplifying tight feedback loopsPhilip Morgan - Consultant and friend mentioned for his example about specialization (forklift invoice review company)Jeff Gable's website - Jeff's consulting services for medical device software development and advisoryLuca Ingianni's website - Luca's training products and resources for embedded systems, IoT, and AIConnect With UsStay tuned for Part 2, where we'll explore organizations that build products and what they should focus on when the market decidesIf you're in the medical device industry and need help with embedded software - either writing it or navigating the regulatory landscape - reach out to Jeff at jeffgable.comCheck out Luca's training products for embedded systems, IoT, and AI at luca.engineerReflect on your own organization: Are you focusing on the right things for the type of service firm you are? Are you specializing enough? You can find Jeff at https://jeffgable.com.You can find Luca at https://luca.engineer. Want to join the agile Embedded Slack? Click here Are you looking for embedded-focused trainings? Head to https://agileembedded.academy/Ryan Torvik and Luca have started the Embedded AI podcast, check it out at https://embeddedaipodcast.com/

    43 min

  6. JAN 19

    Rust with Milica Kostic

    In this episode, we sit down with Milica Kostic, an embedded software architect from Belgrade, Serbia, to discuss her journey from C/C++ to Rust and what it means for embedded development. Milica shares her experience adopting Rust in production environments, starting with an embedded Linux project using a microservice architecture that allowed for clean isolation of Rust code. We explore the practical realities of learning Rust as an experienced C/C++ developer - yes, there's a learning curve, and yes, the compiler will slap you on the wrist frequently. But Milica explains how the development experience, with cargo as a package manager and built-in tooling for testing and static analysis, makes the journey worthwhile. She's candid about where Rust shines (embedded Linux, greenfield projects) and where challenges remain (microcontroller support, IDE tooling, vendor backing). The conversation touches on the bigger question facing our industry: with memory safety becoming critical in our connected world, what role should Rust play in new embedded projects? While Milica takes a measured stance - acknowledging that C and C++ aren't going anywhere - she's clearly excited about Rust's potential, especially in safety-critical domains like medical devices. Whether you're Rust-curious or still skeptical, this episode offers a grounded perspective from someone who's actually shipped production code in Rust. Key Topics[02:30] Milica's background in embedded systems and her journey from electrical engineering to embedded software development, with focus on safety-critical industries like medical devices[04:15] The path to adopting Rust: from first hearing about it in 2020 to finding a client project willing to embrace it, and the importance of having experienced Rust developers on the team[07:00] Choosing the right project for Rust adoption: embedded Linux with microservice architecture as an ideal starting point, avoiding complex C/C++ interoperability[10:45] The learning curve: getting used to the Rust compiler's strictness, discovering the ecosystem of unofficial but widely-used crates, and how learning Rust improved C++ skills[14:20] What makes Rust development pleasant: cargo as package manager, built-in testing and static analysis, cleaner code organization with modules, and writing unit tests alongside source code[17:30] Current limitations: lack of official vendor support for microcontrollers, community-driven development, potential gaps in certified stacks (like BLE), and IDE support challenges[20:15] Interfacing Rust with C and C++: C binding works well, C++ has limitations with inheritance and templates, and the safety considerations when using unsafe code blocks[25:40] Integrating Rust into legacy projects: when it makes sense (isolated new features requiring memory safety) and when it doesn't (just for experimentation), plus maintenance considerations[30:00] The big question: Is it irresponsible not to use Rust for new projects? Discussion of Philip Marcraff's strong stance and Milica's more nuanced view considering team knowledge, existing tooling, and project context[33:45] The influence between languages: how C++ is learning from Rust's memory safety features, and why the borrow checker is harder to retrofit than basic safety improvements[36:20] Rust in operating systems: adoption in the Linux kernel and Microsoft Windows, and major tech companies pushing C++/Rust interoperability forward[39:00] The future of Rust in embedded: Milica's view that C, C++, and Rust will coexist, each with their own use cases, advantages, and trade-offsNotable Quotes"Learning Rust has also made me a better C++ developer as well. Once you get used to those rules, you apply them in C++ as well." — Milica "Just like writing Rust code is pleasant. It flows much nicer than or easier than it would with C++, for example. The way you organize your code, in my opinion, is also cleaner." — Milica "If you are developing Rust for embedded systems on microcontrollers, you need to be aware that there is no official vendor support. Everything currently is open source and driven by the community." — Milica "You definitely do not lose benefits of using Rust for the rest of your codebase when using a C library. That C library is isolated, and if there are some memory issues, then you know where to look." — Milica "I think most of the benefits come from starting with Rust in the first place. So having a clean slate, starting a new product, new project with Rust. That's where you see the most benefits." — Milica Resources MentionedEmbassy - An async framework used in embedded Rust projects, mentioned as a good starting point for greenfield embedded developmentZephyr RTOS - Real-time operating system that is working on official Rust integration, though not fully there yetRust Rover - JetBrains' official IDE for Rust development, released about a year and a half ago, though with some limitations for embedded developmentZed - A new IDE written completely in Rust, mentioned as an emerging option for Rust developmentSlint - A Rust-based GUI framework for embedded systemsEmbedded Online Conference - Conference where Milica gave a talk on Rust for embedded systems - link to her presentation in show notesMilica's LinkedInMilica's talk on Rust at the Embedded Online Conference You can find Jeff at https://jeffgable.com.You can find Luca at https://luca.engineer. Want to join the agile Embedded Slack? Click here Are you looking for embedded-focused trainings? Head to https://agileembedded.academy/Ryan Torvik and Luca have started the Embedded AI podcast, check it out at https://embeddedaipodcast.com/

    36 min

  7. JAN 5

    MicroPython with Matt Trentini

    We talk with Matt Trentini, Principal Software Engineer at Planet Innovation, about using MicroPython for professional embedded development—including medical devices. Matt shares how he was drawn back to embedded development after becoming jaded with traditional C-based workflows, and explains why MicroPython's interactive REPL and rapid development cycle have become game-changers for his team. We explore the practical realities of using an interpreted language on microcontrollers: how Planet Innovation uses it for Class B medical devices, what the performance trade-offs actually look like, and how features like the Unix port enable robust testing. Matt walks us through deployment considerations, explains how to integrate C code when needed, and shares compelling stories about real-time client demos that would be impossible in C++. Whether you're skeptical about high-level languages in embedded systems or curious about alternatives to traditional development workflows, this conversation offers a grounded, engineering-focused look at what MicroPython can—and can't—do in production environments. Key Topics[03:30] Matt's background and why he left embedded development before MicroPython brought him back[08:45] What MicroPython is: a complete re-implementation of Python for microcontrollers with REPL, filesystem, and machine module[13:20] How Planet Innovation introduced MicroPython through an OpenMV vision processing project[17:15] The game-changing power of the REPL for interactive hardware development and testing[21:40] Running MicroPython code on x86 for testing, and the mock machine library approach[26:30] Python library compatibility: what works, what doesn't, and memory considerations[29:50] Integrating C and C++ code through extension modules for performance-critical sections[33:10] Performance realities: 10-100x slower in interpreter, but can always drop to C speed when needed[37:45] Tooling: MPRemote, the magical mount feature, and development workflow[42:20] When NOT to use MicroPython: cost-sensitive high-volume products and resource constraints[45:30] Using MicroPython in Class B medical devices and safety-critical applications[49:15] Garbage collection: simple, predictable, and controllable—can be disabled when needed[52:40] Real-time client demo story: modifying state machines during a call and showing results immediately[56:20] Deployment: frozen code, disabling REPL and filesystem, and OTA considerations[01:01:30] Common mistakes: logic errors and inadvertent allocations rather than memory corruption[01:05:45] Threading, AsyncIO, and the Global Interpreter Lock across different ports[01:08:20] State machine frameworks: StateChart, Yasme, and PyTransitions[01:11:40] Junior developer productivity: faster onboarding compared to C/C++ embedded development[01:15:10] Getting started: board bring-up as an ideal first use case for MicroPython[01:17:50] Hardware-in-the-loop testing as a low-risk way to try MicroPythonNotable Quotes"It's hard to overstate how game changing the REPL is. Particularly as an embedded engineer, once you see that you can interactively talk to a peripheral, you can generate your own I2C, squirt it across and see what the peripheral does with it—suddenly driver development has just become easy to experiment with." — Matt Trentini "My trite answer is that MicroPython is slow—10 to 100 times slower than C in the interpreter. But my flip side answer is that it can always be made as fast as C because you can always drop into C to write things." — Matt Trentini "There was a moment in a recent project where we were discussing the workflow of a state machine with the client, and while we were on a call, another engineer was actually making changes to MicroPython code. Literally a couple minutes after we'd been hashing out the details, they showed the changes in the state machine using the REPL. The client was blown away—in 25 years of development, I have never had that kind of turnaround in C and C++." — Matt Trentini "If you want to make a good friend of your electronics engineers, give them a build of MicroPython that can run on their custom board. In the past, they would typically be waiting for weeks or sometimes months before a software resource could be assigned. Now I can turn around a MicroPython build in a day or two, and they can test I2C, GPIOs, and UARTs themselves." — Matt Trentini "The irony is that the people who have embedded C knowledge are actually the people that can benefit the most from MicroPython. It's like having a superpower—you understand what MicroPython is doing in the background, you know you're just effectively writing a lot less code." — Matt Trentini Resources MentionedMicroPython Official Site - The official MicroPython project website with documentation and downloadsOpenMV - Computer vision project using MicroPython for camera-based applicationsMPRemote - Tool for interacting with MicroPython devices, including the magical mount featurePlanet Innovation - Medical device consultancy using MicroPython in production devicesStateChart - State machine library compatible with Python and MicroPythonYasme - Yet another state machine library developed at Planet InnovationPyTransitions - Popular Python state machine library being ported to MicroPythonCircuitPython - Adafruit's fork of MicroPython with additional features and CPython compatibility focus You can find Jeff at https://jeffgable.com.You can find Luca at https://luca.engineer. Want to join the agile Embedded Slack? Click here Are you looking for embedded-focused trainings? Head to https://agileembedded.academy/Ryan Torvik and Luca have started the Embedded AI podcast, check it out at https://embeddedaipodcast.com/

    58 min

  8. 12/16/2025

    Terrible Habits of the Solo Developer

    In this episode, Jeff and Luca tackle the unique challenges faced by solo embedded developers. Drawing from their own experiences as consultants, they explore why working alone makes it harder to maintain good development practices - from the constant pressure to multitask across different stakeholder demands, to the difficulty of wearing multiple hats as leader, manager, and contributor simultaneously. The conversation moves through common pitfalls: skipping documentation because "it's all in my head," letting code reviews slide, making questionable architecture decisions without a sounding board, and neglecting tools like simulators under time pressure. But this isn't just a catalog of problems - Jeff and Luca share practical strategies for staying disciplined, from creating mastermind groups with fellow solo developers to strategically hiring third-party reviewers for architecture decisions. They discuss how to push back on arbitrary deadlines, the value of enforcing process on yourself, and why sometimes the best productivity hack is spending money on training to force yourself to sharpen your skills. Whether you're a solo consultant, the only developer at a startup, or part of a small team, this episode offers honest insights into maintaining quality and sanity when you're working largely on your own. Key Topics[00:00] Introduction: Can you do agile as a solo developer?[03:30] First principles of agile development and why they work for solo developers[06:15] Unique difficulties: Making progress in only one area at a time[10:45] Wearing three hats: Being leader, manager, and contributor simultaneously[15:20] Budget pressure and the challenge of 'nice to haves' that actually matter[22:30] The importance of delivering something palpable after the first sprint[28:00] Bad habit #1: No documentation because 'it's all in my head'[35:45] Bad habit #2: No code reviews and potential solutions[40:15] Using LLMs for code review: What works and what doesn't[44:30] Bad habit #3: Idiosyncratic or terrible code architecture[50:00] Bad habit #4: Not making it easy for other developers to take over[53:20] Bad habit #5: Neglecting simulators and development board support[57:00] Breaking bad habits: Working solo together through mastermind groups[62:30] Enforcing process on yourself and recognizing arbitrary deadlines[67:45] Applying agility to agility: Inspecting and adapting your own process[71:00] Sharpening the axe: Jeff's experience with the Embedded SummitNotable Quotes"When you're a solo developer, you have to be the leader, the manager, and the contributor for the software effort. Those are different roles and different skills." — Jeff "You must apply agility to agility. Inspect your process, figure out what works, what doesn't work. If something is annoying to you, either it's pointing you towards a real deficiency or it's just objectively a terrible process and you should change it." — Luca "It's really scary how effective rubber duck debugging is. You start to think of what the other person would answer, even though you're just talking to a rubber duck." — Jeff "Simple and easy are not the same things. Having good development practices, just like losing weight, is simple. It's just not easy." — Jeff "Dear listeners, have you ever paid with your own money for software development? Because I have. And it's really unnerving. You tell this developer to go do something and they just sort of disappear and you can hear the meter running." — Luca Resources MentionedQP Real-Time Framework - Event-driven framework by Miro Samek for embedded systems, mentioned as a game-changing architecture choice for medical device development with active object patterns and hierarchical state machines Zephyr RTOS - Open-source real-time operating system for embedded devices, discussed as an important technology for solo developers to master for modern IoT and connected device projects Embedded Online Conference / Embedded Summit - Premier embedded systems conference offering both online and in-person training, including hands-on bootcamps for technologies like Zephyr RTOS, organized by Jacob Beningo and Stephane Boucher Agile Embedded Academy - Luca's newly launched training platform focused on applying agile methodologies specifically to embedded systems development, offering practical courses for embedded teams FDA Software Documentation Requirements - Regulatory documentation standards for medical device software including requirements specifications, architecture documents, detailed design, and test protocols required for FDA submissions Mob Programming Methodology - Collaborative development approach where entire team works on single task together, referenced as an alternative to traditional multitasking, promoted by Austin Chadwick and Chris You can find Jeff at https://jeffgable.com.You can find Luca at https://luca.engineer. Want to join the agile Embedded Slack? Click here Are you looking for embedded-focused trainings? Head to https://agileembedded.academy/Ryan Torvik and Luca have started the Embedded AI podcast, check it out at https://embeddedaipodcast.com/

    54 min
See All (97)

Ratings & Reviews

4.9
out of 5
12 Ratings

About

Learn how to get your embedded device to market faster AND with higher quality. Join Luca Ingianni and Jeff Gable as they discuss how agile methodologies apply to embedded systems development, with a particular focus on safety-critical industries such as medical devices.

Information

  • Creator
    Luca Ingianni, Jeff Gable
  • Years Active
    2021 - 2026
  • Episodes
    97
  • Rating
    Clean
  • Copyright
    © 2021-2025 Jeff Gable & Luca Ingianni
  • Show Website
    The Agile Embedded Podcast

You Might Also Like