Week 04, 2026

What I Learned

ESP-IDF Supports C++ This weekend I discovered that ESP-IDF has C++ support. This changes things for my ESP-HUB75 project. The C++ language features I’ve been missing, classes, inheritance, polymorphism, RAII, would make many concepts significantly cleaner. Better abstractions, proper encapsulation, more expressive interfaces.

This connects to the rewrite question I explored in Week 01: When does a migration solve real problems versus just being technically appealing? In this case, I believe it passes the test. OOP patterns genuinely simplify embedded code when you’re managing multiple displays, animations, and state machines. The language features address actual pain points in the current C implementation, not hypothetical improvements.

I’m now seriously considering the migration. The effort is real, but so are the benefits.

Reading & Listening

Nello Biedermann - Lazar Started reading this debut novel and I’m impressed. What makes it stand out: Biedermann tells a story set in the 20th century, but writes with a distinctly modern voice. Contemporary language, current cultural references, a style that feels like today, all woven into a historical setting. It’s a fascinating contrast that creates something fresh.

The first 100 pages have been captivating. I hope the rest of the book maintains this momentum.

Tilpod Podcast: Inner Source in Companies Listened to this episode about Inner Source and Open Source practices within companies. It sparked thoughts about my own experience with Monorepos.

Thoughts

Inner Source: Monorepos as a Technical Catalyst

The familiar Monorepo debate came up again recently. As usual, someone mentioned the “killer argument”: Google, Meta, and others use Monorepos too! The problem with this reasoning: it suggests false causality and distracts from the actual question.

For me, a Monorepo is primarily a technical tool to enable Inner Source.

If you’re serious about Inner Source, meaning you want to create a culture where developers collaborate across team boundaries, you need the technical foundation to support it. A Monorepo provides exactly that:

• Structural transparency: Everyone has access to the entire codebase
• Low barriers to entry: Code discovery and cross-team contributions become straightforward
• Visible learning: Developers see how other teams solve problems
• Organic knowledge transfer: Best practices spread naturally

My Experience in Automotive

I’ve worked in Monorepo environments in the automotive industry, and it shaped how I think about software development. Seeing how other teams solved similar problems, being able to contribute fixes across team boundaries, understanding the full system instead of just my component. These experiences accelerated my learning significantly.

The benefits are substantial: more motivated engineers through genuine collaboration, higher code quality through diverse perspectives, faster knowledge exchange across the organization.

Monorepo yes or no? It depends on the context. But if a company genuinely wants Inner Source, a Monorepo is one of the most effective technical approaches to break down cultural barriers. I’m convinced more companies should explore this path.

What’s your experience with Inner Source? Does your organization have the technical foundation to support cross-team collaboration?