Week 01, 2026

What I Learned

Website Rebuild Launched this new journal section to document weekly learnings and reflections. Looking forward to sharing insights on embedded software and engineering practices.

ESP32 Dynamic Memory Discovered that the ESP-IDF framework supports dynamic memory allocation for ESP32 microcontrollers. This opens up interesting possibilities for more flexible embedded applications, though it requires careful consideration of the typical embedded constraints.

Reading & Listening

Matthew McConaughey - Greenlights (Audiobook) A brutally honest autobiography that doesn’t shy away from the messy parts. His philosophy of looking for “green lights” in life, and sometimes creating your own, resonated as a good mindset for the new year.

Agile Unfiltered Podcast Two episodes stood out this week:

• Who Delivers is Right: The End of the Scrum Guide & Your New Manifest
• The Agile Decluttering: 3 Things We Won’t Drag into 2026

The core message: Done > Perfect. Focus on delivery and quality rather than frameworks and processes. This applies just as much to embedded development as it does to web applications. Too often we get caught up in tooling and methodology when shipping working software is what actually matters.

Coding Buddies - Microservices vs. Monolith An objective, balanced discussion on architectural patterns. It sparked an interesting question: Could microservices architecture work in embedded systems? Most embedded projects use monolithic architectures, but with increasingly powerful hardware and connectivity requirements, there might be valid use cases. Need to explore this further.

Thoughts

The Rewrite Trend: Technology Choices and Problem Solving

This week I watched a PrimeTime video about a Microsoft engineer claiming they’ll rewrite C/C++ code by 2030. The discussion around this, combined with projects like uutils coreutils rewriting GNU Core Utilities in Rust, made me think about a fundamental question in software engineering.

What should drive our technology choices?

There’s a growing movement to reimplement established software in modern languages like Rust, Zig, or Go. These languages bring genuine advantages: Rust offers memory safety without garbage collection and fearless concurrency through its ownership model. Zig provides comptime execution and superior C interoperability. Go delivers simple concurrency with goroutines and fast compilation.

The question that keeps coming back to me is: Are we choosing technology to solve specific problems, or are we rewriting because the technology is appealing?

When rewrites make sense:

Some rewrites clearly add value. Tools with known security vulnerabilities that modern languages address by design are good candidates. Components where memory safety constantly causes production issues benefit from Rust’s guarantees. New projects can and should use the best available tools. Systems that genuinely need modern concurrency models should adopt them.

Where I’m more cautious:

Rewriting stable, proven software primarily because “it’s modern” raises questions for me. Take GNU Core Utilities: they work, they’re tested, they’re proven. What concrete problems does a Rust rewrite solve? If it’s measurably better performance, easier maintenance, or demonstrable security improvements, those are valid engineering reasons. But if it’s just “written in a newer language,” I’m not convinced.

My current thinking:

Technology choices should solve problems, not create them. Sometimes the best code is the code that already works and has proven itself over years. Sometimes a rewrite unlocks genuine new capabilities. The engineering challenge is knowing which is which.

This isn’t about being against progress or new languages. It’s about being intentional. Choosing tools based on the problems we’re actually trying to solve, not based on what’s trending.

I’m curious how this plays out over the next few years. Will the rewrite trend prove its value, or will we look back and realize we were solving problems we didn’t have?