Embedded - 531: Sequestering the Mess

Episode Date: August 6, 2026

Elecia and Christopher celebrate winning the IEEE Educational Activities Board Meritorious Achievement Award in Outreach and Informal Education! A huge thank you to Mark Omo and the wonderful listeners who submitted nomination letters. Chris and Elecia talk about learning Hungarian to qualify Chris for an EU passport. They also cover Cory Doctorow's new book The Reverse Centaur's Guide to Life After AI, smart ways to hand off codebases, and the most valuable skills they've relied on through their engineering careers. DISCUSSION RESOURCES & LINKS AWARDS & MILESTONES: IEEE Educational Activities Board Meritorious Achievement Award in Outreach and Informal Education "For creating and sustaining Embedded.fm, a long-running technical engineering podcast that bridges academic theory and industry practice, champions underrepresented groups in STEM, addresses professional ethics, and provides informal technical mentorship to a global audience." Huge thanks to Mark Omo for submitting the nomination and to the other nominators for advocating for our work. To the 450+ guests—artists, makers, educators, entrepreneurs, and traditional engineers—who have generously shared their time and deep expertise with us: this award belongs to you too. And to our incredible global listener community: thank you for tuning in, sharing episodes with your colleagues, and keeping the STEM pipeline strong. If Embedded.fm has ever helped you solve a tricky bug, navigate a career transition, or stay inspired in hardware/software design, we'd love for you to celebrate with us by sharing your favorite episode with an early-career engineer or student this week! Embedded episode 501: Inside the Armpit of a Giraffe, an interview with biologist Meredith Palmer and engineer Akiba, won a Communicator Award for an Individual Episodes-Science & Technology, Distinction 2026. BOOKS & READING LIST: The Reverse Centaur's Guide to Life After AI by Cory Doctorow Programmers at Work: Interviews With 19 Developers Who Shaped the Computer Industry by Susan Lammers (1986) Embedded AI: Intelligence at the Deep End by David Such (No Starch Press, Early Access) TECHNICAL & LANGUAGE MENTIONS: The Hungarian phrase "Boldog vagyok" ("I am happy"). Elecia's Duolingo page Zephyr RTOS and embedding Rust libraries into Zephyr environments Memfault observability, CSV data extractions, and battery performance analytics AI models escaping sandboxes (The OpenAI and Anthropic benchmark incidents) Transcript

Welcome to Embedded. I am Elysio White here with Christopher White. Oops, I meant to say, welcome to Embedded, an award-winning podcast. Congratulations to us. Congratulations to us. Two awards now. It is, it is. I got the Signal Award for the giraffe bird armpit with Meredith and Akiba, the story of ecology and technology. which is great.

I mean, I'm excited about it. But Signal is kind of one of those where you pay for it mostly. I mean, it's still a little competitive. Uh-huh. And what have we won now? We have won the I-Triple-E, educational activities board, meritorious achievement award in outreach and informal education. That's a lot of words.

Okay, so I, AAA, I think most people know what that is. It's the engineering organization for electrical engineers, a lot of computer general people involved. Yeah. They have a bunch of different activities boards. The educational one is all about helping people take more education in, basically. But this one, this particular award is about outreach and informal education. So it's not teaching classes. It's specifically not teaching classes.

But it's somehow teaching people about engineering without teaching classes. Okay. So it's one I'm really excited about because, gosh, that's what we do. We do provide a level of informal education. Most podcasts do. And we definitely... We go with most. Most of the ones I've listened to do.

And we definitely provide outreach talking about what engineers do in their daily lives and trying to keep people in engineering. Yeah. This was based on the nomination from Mark Omo, who took the pile of my planning after I had given it up and decided to put it in the trash and got it all done and helped everyone. who offered to be a nominator to write their papers and get them all in on time. And I am actually really shocked, everyone. Why? Well, it is an award that you don't pay for. Right.

In fact, you get money for it. Not a ton, but, you know, it's an actual award, not... Yeah. And we get a trophy, right? I assume we get a trophy. I'm kidding. I don't know. I don't, because, you know, it's the first time we've ever tried to get the award.

And so it doesn't seem plausible. Okay. You've been interested in getting awards for the show for some time. Does this satisfy your award getting this? Yes. Yes, it absolutely does. It was one of my, my New Year's resolution was to apply for a, awards every month until we won one.

And so this was part of it. And even though other people had to do most of the work, I'm still, I was actually, after the whole packet went together and got submitted, I was actually really just honored to be nominated because- That's what they all say. Several people had to put in time, serious time, to write. I mean, maybe not like days of time, but hours of time to put this together and write up something that was nice about the show, about what we do with the show. And so after that went together, I was like, okay, no, I really am honored to be nominated for this. That was really cool.

But to also be selected is actually even cooler. Okay. So, yes, I do think this satisfies my desire. We have one outstanding submission that I did earlier in the summer for a science communication award. And that was one where the entrance fee was very low. But it's competing against like Science Friday and Radio Lab. Yeah, but they're old. They don't need any more awards.

Well, I mean, if it was me, I'd probably give it to ologies. Science Friday wasn't even a podcast. It was a radio program for like a decade before they just put it on the internet. It's not even count. So I would be really pleased if we heard back from them. But if we don't, I'm done. I don't need any more awards, I think this actually was a nice exercise in external validation of... And thinking about the show and what you wanted to do with it and what we have done with it.

And it's nice to look back and realize that you've produced something. We don't do that often enough. We don't celebrate our victories often. Maybe we, Christopher and I, but I think... We got cake yesterday, and I regretted it. Common engineering thing that we spend a lot of time identifying and dealing with problems. I mean, critical thinking skills is like one of the things you have as an engineer. Problem solving.

Problem solving. It has the word problem in it. Right. But we don't often say... I mean, when you fix a bug, it's like, oh, thank God. But now I'll go on to the next bug. Yeah. There's never, nobody ever throws us parties and parades.

Through a party once. It's not a parade. We could try that. We've never thrown ourselves a parade. I don't think that's going to happen. There would be so many glow-eaten things. It'd be so cool. Well, Bulldog Vadjok.

Ah, I am happy, yes. I'm happy as well. Chris has found that his A grandparent is Hungarian Great-great-grandparent It's Hungarian And that makes him eligible for a Hungarian passport So long as he can speak some of the language

Yes So we are learning Hungarian Which I'm finding to be very amusing I'd forgotten how much fun it is to learn a language It's a strange language I mean it's not strange It's just it's a very unique language compared to most European languages, it's not from the Latin family. It's not from the

Germanic family. It's not from the Russian family or whatever that would be called. Uralic? It is Juralic. And so it's more, it's closer to Finnish. Close to Finnish, I think Latvian and some parts of inner Russia speak little bits of uralic things. And it's funny because English is basically a romantic. language and a Germanic language that got mashed together.

Mutual theft of both. Yes, but it's somewhere in between. And it's why we have so many two words for one concept. It's because you have to do both the romance and the... But yeah, Hungarian's been fun. Duo lingo's been fun for, you know, I'm not... For the initial stages, it's great. Learning how to say thank you and please and goodbye.

Which has nothing to do with anything. But we were joking about Hungarian notation. That will be experts in it. Yes, exactly. Look out future code reviewers. It's all going to be in Hungarian. Yeah. What else have you going on?

What else do I have going on? I still have a client, improbably. So you're doing engineering work? I'm still doing engineering work. Pretty close to shipping or actually shipping now? like this week or last week or yeah so firmware is kind of solidified to the point where there's a less to do right now because nobody really wants to do any touch it yes there are some small bucks and stuff and I'm kind of working around the edges of our memphol implementation add some new metrics

figure out how to do a few things people are starting to use it and they're asking me questions like how do I do this how do I get this data out and I like I don't know and then I go look and it turns out you can't. And so now I'm having support conversations with people because I don't know, why can't I get this time series in a non-AI MCP way. I just want to put it in a spreadsheet. You know if Tyler's listening to this. He's like, all you have to do is this. Well, then he can tell me because the email I got back from support was, not that. It was you can use our S3 continuous thing or MCP. And all I want to do is give an EE away to take one's devices battery chart and put it in CSV, which

turns out to be way more difficult than I expected. But other than that, it's great. How funny how hard things are easy and easy things are hard. Yeah, yeah. So, well, that's the way we do things. We don't want to do the easy things. They're boring. But other than that, yeah, I, you know, have learned a lot of Zephyr again. This is my second actual Zephyr project. So I've done quite a bit of Zephyr in there. I finished up my little Rust project, bringing a Rust library into our code to just experiment with it. That had some positive results. That was a little easier than I expected. So it turns out you can put Rust code in Zephyr with, you know, not too much difficulty given Zephyr and Rust. But yeah, learned a few things. I like, you know, I like

any project where I'm learning things. If it's the same, if I'm turning over the same kind of thing, I feel like, I just feel like a cog, so I haven't felt that way with this job. And you're still on your extremely long-term project. I am. Robotics, which is complicated. And we have new team members who are early in their career, which is a lot of fun for me, for mentoring and just trying to figure out what I can chunk off without then later regretting. how much I have to do to make sure it works.

It hasn't been a lot of hardware for me because it is a robot, and so the hardware is large and somewhat dangerous. Okay. So, or don't really want it in my office. So I spend a lot of time simulating stuff, which gets old, but I'm in a slump right now. Hopefully it will get better soon.

That's the way it always goes. Yeah, and especially on long-term projects. My pattern has always been I enjoy it for six months to a year, and then either the new stuff slows down or you go in maintenance mode, and that's less interesting. I don't think that's what's happening to you. It doesn't sound like you're in maintenance mode yet. We haven't shipped yet.

Yeah, yeah, it sounds like you're still pushing rocks up hills. So many rocks. But there's some really fun parts about it. and I shouldn't say too much more about it. So let's see, we've got some books to talk about. Books? Would you, you've been reading books in French? Yes.

We're becoming so multilingual. Would you rather read Tolkien in French or Pratchett in French? Well, I'm doing both. I know. So I had been reading Lord of the Rings in French, a translation, obviously. and it's a challenging book to read in English, just not in terms of it's difficult to understand or anything, but, you know, it's flowery language.

It's, you know, a little archaic, and there's a lot of verse in it and stuff. So I got about halfway through Fellowship of the Ring and got a little bored, not bored, but I was a little tired of it and would come back to it, but I was like, I need a break, I need to erase something lighter. Well, it's not like you don't know the story. You can jump in.

It does help, yeah, yeah. Yeah. And I was finding a lot of vocab I was having to learn, and some of it's archaic and not that useful except when you're reading books. One of the things about French that's a little bit different than English is there's a lot of written language that's very different from, let's say, current spoken language. I can't believe your French tutor made fun of you for talking like an archaic old man. I just used a verb that was only used for writing.

But there are verbs only kind of used for writing, and then there's verbs that are, there's verb tenses that are definitely only used for writing. Like there's an entire past tense that's only for writing. And you'll see it in books a lot, but nobody speaks it ever. So that's a bit confusing. And yeah, so I was just like, okay, maybe this is too hard. This is kind of slow going because I'm not, I can't just read it. I can read, but every page there's, you know, four or five vocabulary words, I don't know.

So I said, okay, well, I want to read something fun that's a little lighter. and I went and found a translation of the Pratchett books. Terry Pratchett. Terry Pratchett. Disco World, yes. Sorry. So I'm reading the 11th book. It's the one where...

Death dies? No, well, he gets fired. Oh, okay. And so a lot of bad things happen in the wake of that. Ramifications, people. That are very funny. But yeah, I'm reading that, and I'm finding... I'd forgotten that Pratchett is one of the few English books I can read

where I have to look up words occasionally. It sounds funny because you think of Pratchett is silly books, but he uses a lot of, anyway, so I'm having to look up a lot of vocabulary there too, but it's more, yeah, it's more fun. It's easier to read in some sense. Like I can go a lot longer before I run into something I don't know. But Tolkien's sentence structure, boy, we are not talking about computers today, are we?

Natural language processing, it's hard. Go ahead. Tolkien's sentence structure is simpler, but the vocabulary is more difficult in Lord of the Rings. Pratchett's sentence structure being sarcastic, has a lot of ellipsis and commas, and he can have a sentence that's very, and that's harder for me to parse in a different language than English. It's hard to parse in English and keep your place in a sentence, which is, you know, going into an ellipsis, and then maybe an ellipsis for the ellipsis, and then a parenthetical, and then it comes back to the main thing, so it's long. And so when you're trying to translate that or read it in a different language, which becomes even more challenging. So Pratchett, while the language is simpler, the sentence structure is more complicated.

So I didn't quite realize that. So what I really need is like Sesame Street books. But, yeah, no, I also bought a murder mystery. I hadn't read from a native French writer. So I'm going to start that as soon as I finish the Pratchett book. And maybe that'll be less vocabulary. There's a lot of words out there. There's so many words.

There's so many words. And, of course, there's zombies in this. So I'm learning all the words for shambling. and stumbling and a bunch of stuff that, you know, not all that useful in everyday conversation. We're also reading Reverse Centaur. Yes, Corey Doctoro's new book. Can you describe it?

I've only read a couple of chapters so far. It sells itself as an overview of AI, AI being LLM and that kind of AI, and how we should think about our relationship to them. And it's Cory Doctor-Rose, so there's a lot of course language and opinions and, you know, a lot of anti-corporatism, which I'm not wholly against. But yeah, and so the first couple chapters, he's introduced this concept of reverse centaur, which I already forgot what it meant, but...

The whole book's title is The Reverse Centaur's Guide to Life After AI. How to think about artificial intelligence before it's too late. Yeah, before it's too late. Yeah, great. And the description is, in modern tech parlance, a centaur is a person who is able to use technology to be a better, more productive version of themselves. So somebody with a calculator. A reverse centaur is a person who is forced to use technology to work at an inhuman

pace. A driver made to delay all day long. A warehouse worker made to work without food or bathroom breaks. A programmer made to crank out impossible amounts of code. Okay. And so this is about using AI in a way that helps us, where us is the most number of people as opposed to the person with the most amount of money. Right. Okay. I mean, Doctoro is very, it's fine if you get a cash register and it helps people who were cashiers who used to add everything up by hand, which was a very skilled set of things to do. You get a cash register and now you don't need somebody who can add correctly. Do you fire half of your cashiers and make them do twice as much work? or do you use that technology to allow the cashiers to help people more?

Or do something else. Or do something else that is important to the job, but without trying to make them go faster. Yeah. I think the difference, that reverse Centaur-Sentar thing reminded me of something that Steve Jobs once said. Not a huge fan of Steve Jobs, but he did say this. I think he said this. He didn't correct me and tell me who the right person was. But he said something like the computer should be a bicycle for the mind.

like bicycles they're great they help you get from one place to another faster they're good for your body they you know they're an accelerant for things we already do and they don't necessarily have a lot of downsides whereas computers in the 80s that felt like that's kind of what it was and now we've got the AI stuff which feels like okay it's the bicycle and the writer and then I mean, it's worse when it's the writer and I'm the bicycle, which is where Dr. O is going. I think that's where I was heading. Suddenly, suddenly we're the bicycle for the, for the. The AI is getting to do all the art and fun work, and I'm trying to put together a website that doesn't crash.

And I've seen a lot of people say, well, we just need to adjust. And I haven't read the whole book, so maybe he discusses this, but we just need to adjust how we think about software development. And now we're the people who just writes the becks and all that stuff. And, you know, as you know, programmers, coders, software engineers love to write specs into designs. So it'll be interesting to see if that's what actually happens. And we become better designers who guide the AIs through the dr. dr. Rhetory of coding. But I don't know.

So, yeah, the book, I am not a huge fan of Dr. O's. He, the problem with Dr. O's, I agree with a lot of what he says. But then he makes me mad about it. Yeah. So I can't really describe what that means, but, uh, so yeah, I'm, I'm trying to pace myself through it. There's a lot of stuff I, I mean, he said in the book already that I agree with,

a lot of stuff that, uh, I didn't know, a few descriptions that I found tortured. But, uh, we'll see how it goes. This is for a book club. A bunch of us are reading it. And we're doing it slowly. So this is not going to happen fast. Uh, although at least one person on the Patreon and

its lack, read it and found it interesting, not life-changing, but interesting. I do wonder, given the pace of how things are changing, whether any book can be written right now that's going to be applicable in a year, but we shall see. It's funny you say that. Because I've been reading a book from 1986 called Programmers at Work, which is a series of essays by a whole bunch of programmers, some of whom are very famous, some of whom are billionaires, some of whom are professors. And it's 40, it's been 40 years. Sorry. And some of, and they didn't, I mean, this is, this is from then. Yeah. Much of the advice that they are giving,

even for things that have sunk into the midst of time, Lotus 1, 2, 3, and whatnot. It's about having a good idea of what you're building before you start building it. If you don't have a spec, at least have a goal. And as I become a manager, people interrupt me more and I only get to do fun work at night. So there were a lot of things that I'm like,

okay, yeah, I hear that all the time now. Yeah. This is advice I would give. Not the manager part. That's the sign of a new manager. But I am having trouble with, I don't want to take advice from these people who are what I think of as ethically questionable. People I would not want to have to dinner.

People I would not want to be in the same room with for physical safety or just emotional safety reasons. Yeah. Am I really going to take advice from somebody I dislike? I don't dislike Dr. O. I mean, we've seen him in person speak once. He didn't seem...

Oh, no, no, he just gets on my nerves. Yeah, he gets on my nerves. I think he would agree that he gets on many people's nerves. I don't think that's a controversial. I think he thinks that as a feature. I don't think that's a controversial statement. And he's had... I mean, some of the concepts he's have been really great,

but I don't... I don't tend to like his writing. Yeah, it's fine. I wish we could... Wikipedia, Corey Docterose every book so that I could just read that. But we're reading Reverse Centaur, and I'm reading this programmers at work. And it's really made me think about how do you decide if you're going to take advice from somebody you don't respect? Do you just ignore all of them?

Well, I mean, this goes back to the old adage or whatever, the claim that you need to separate the art from the artist. when they're giving you life advice It's a similar thing, right? It's like, can I enjoy this workpiece from this objectively horrible person who did terrible things? Because the art is separate, right? But even if you can separate the art from the artist,

I know what the person did, so that's in the back of my head the whole time. So even if the advice is good, I find that difficult. I mean, there are definitely people who I don't like who have given me advice that's been good, but not liking someone is different than not respecting them. There's plenty of people I don't like that I respect. And there are a few people I like whom I don't respect. Okay, well, hopefully nobody in this room. No, of course not.

The dog. But yeah, I mean, so it's hard to, like, It's hard to take advice from somebody you don't respect. That's like listening to music from somebody whose artistry you don't like. I think, I might have ruined that metaphor, but I think respect is the key word you use there. And I don't think you should take advice from people you respect because it might not be trustworthy. Why do you not respect them? Because they're dishonest or they're in some aspect of their life or trying to pull one over on you or get something out of you.

and their advice is suspect, get it from someone else. I don't know. I mean, there is technical advice. Like if somebody awful told me, you know, never use tabs, use spaces, and I agree with them. I mean, that's a silly example, but. You don't just start using tabs because somebody you don't like said you should use spaces. That's got a reverse psychology thing going on. I do have a little bit of oppositional defiance disorder, but not that much.

It's hard to decide what to pick and choose. And sometimes it's hard to find out more about the artist for fear that you won't be able to like the art afterwards. Yeah, sure. That's why I think, you know, the post-social media internet has made that more of a problem because we do know more about the people who make our art or who give us advice. And not, I mean, it's not a problem, but it's a different environment where we actually are aware of things that we weren't before. And I think on the advice thing,

I find it hard to believe it's common for there to be a piece of advice that only one person can get you. That's a good point. And I see this in this book that there are a lot of commonalities. And I would be much happier taking the advice from a Turin Award winner than a billionaire.

Were they billionaires when they wrote the book? No. No, they were not. Okay, let's see. There's a new book coming out about AI and embedded. I'm not going to tell you a lot more about it other than I'm pretty excited about it because it means that I'm not going to write that book.

And I do mean AI techniques on embedded devices. edge AI, inference, not how to use agents or tools to use AI to do embedded software. This is making smart devices. Okay. Smarter devices. Smarter devices. And that's by whom? And when is it coming?

And what's the publisher? It is, gosh, I don't know if I'm supposed to say or not. Oh, no, no, no. know, they have it, they have it on their website. It is called Embedded AI, Intelligence at the Deep End by David Such, and it's from No Starch. It's on early access right now, and it's supposed to come out in September, October. Ooh, and they're predicting it at 600 pages, which I actually, yeah, maybe.

It's a lot of material. That stuff's difficult, and you have to, if, If it's a starting from scratch sort of book, you have to introduce all of the deep neural network stuff on its own. Some of that, but also there's a whole third section that's all projects and applications. Oh, nice. Actual code and stuff. So I'm looking forward to that. Doug G. asked us, have you found a good general book on AI, something you could recommend to a non-technical person?

Sadly, right now, that's Dr. Rose reverse Suntar book right now. Yeah, I can't think it's, I mean, it depends on the angle you're going for, is that what is what people are calling AI and how does it work at a high level and, you know, general overview of the current situation, which if somebody was writing a book on that, I would caution them against it right now. I mean, is it about LLMs and convolutional networks or is it how is this going to affect our society? Yeah, yeah, yeah. So there's a lot of like going on there. Or how does a person use AI responsibly? Or is it a practical cookbook? Yeah.

So I don't understand. I don't know the scope of the question or the scope of the book desired. But no, I don't know of one. If you're looking at social impacts and, yeah, and kind of future looking what might happen, I think Dr.Row's book is probably good. But it's definitely directed toward people who, might be affected or replaced by quote AI.

I would go even further than that. It's directed towards people who work in technology. Yeah, yeah. It, a technical person could read it. I mean, a technically minded person could read it. But there is a little bit more context, jokes that are available to folks who, developers and kind of stuff. Who are developers and have seen some of the tropes before that we end up with.

Metrics. Key performance indication. KPI's, yeah. Let's see. I have some cards here that we're going to try. Otherwise, more listener questions. Okay. What skills have been most valuable in your career path?

Let's see. Well, I mean, this is difficult. to not say, and I'm pretty good at this. Typing. I'm pretty fast at typing, and I learned to type in an early age, so I'm pretty quick at typing. Having a model of what a computer is and how it works in my head from an early time that hasn't really changed much, especially for microcontrollers, I think that's really useful because that kind of explains a lot of things that happen in code, like pointers and how memory is structured and stacks and all of that garbage. If you know kind of how the machinery works, then that stuff is less mysterious when you see it

for the first time or the 11,000 time. Because it's usually the same set of things just in different places. Yeah. And even all this AI garbage, it's all arithmetic. It's all, I mean, it's arithmetic. It's literally addition for the most part. and some multiplication. It's just a lot of it. And all that happens with the same kinds of structures, just on a much larger scale with some fancy tricks that early computers from the 80s and the 70s were using. So I don't think there's anything lost in understanding computer architecture at a base level. I feel like I'm, I don't know how to express this, but I feel like I have some skill at deduction.

and eliminating things that, like when debugging, eliminating things that aren't possibilities early and evaluating risks early. But that's off the top of my head. Those are the kinds of things that I think serve me well in the jobs that I do and have in the past. I don't think I'm a particularly genius coder or elegant coder or anything like that.

I think I'm probably, you know, all right. Because I have a lot of bad habits that I learned early and haven't kicked. Like what? Oh, I don't know. Just the way I structure stuff sometimes or I don't know. I mean, I'm fine. I'm not a bad coder. It's just I've seen well-architected stuff that looks beautiful and I don't feel that way about my own code.

My stuff works. It's fine. It's clean. It's good. It's just, I've seen better. What are you? We were playing a game recently with friends, and somebody said, asked what, what major skill made me most successful?

I answered the ability to count to 10 because I was playing this game, but I was not playing the game. All right. And she took that to me, the ability not to get angry, which is not how I meant it. I feel like many people stop after the fourth effort, the fourth thing, or the sixth. And I guess it's part of detail-oriented, but I'm not going to stop early. I'm going to count all the way to 10.

Do you mean that in a sense of perseverance or in the sense of doing everything you're supposed to do? Perseverance more. Okay. Not about ticking boxes, more about exploring all the options in more of a breadth for a search instead of going down deep on one. Yeah. Because there's always the chance that you can knock things out. I think another skill that has been good for me is diagrams. And this came up last week with a junior engineer that was writing drivers all over the place.

And I was like, make me a diagram. And I'm pretty sure he thought I wanted him to make a diagram because I had been making all these diagrams to do some documentation preparation. And no, I just wanted to, I wanted him to make a diagram because I wanted him to think about how all of these things went together, how we went from I squared C to device to peripheral and built that up into a whole subsystem and then into multiple subsystems. Because I'm working on a pretty big project. And so there's, there are subsystems of subsystems. and I've always thought about things in more of a diagram method. It's in my book too. That you can build like an org chart diagram to see who talks to what.

And then if you squint and your org chart looks really weird, like there's only one thing at the bottom instead of one thing at the top, all of your devices go through one protocol and that is a point of weakness. a point of failure. Or if you have 10 things talking to one little thing, then you have a lot of complexity in this area. And being able to use diagrams to find complexity before you write it,

in order to simplify before you write it, is so much better for me. I think those two, the perseverance and kind of having this, system view or forcing myself to have a system view even when all I want to do is write the thing that's in front of me? I think visualization is something that people sometimes lose sight of. And you're right. Like, it's easy to think about something. Because code makes, the way we write code is words. And it tends to be ordered and structured in a kind of a non-visual way.

I mean, there are linkages in things, but that's not apparent in the code very obviously. And the thing, but the things we're writing code about tend to be modules that interact with each other. They're graphs and networks. And you can't, I think it's impossible once you get past a very base level of complexity to have that in your head and see, get any insights from it that you can from a, you know, a picture of how this modules interact with the hierarchy, their connections. I mean, it can reveal things instantly to you that you couldn't see otherwise, like loops. Oh my God, there's a loop here. This module talks to this module and goes back to this module on now.

I've created a loop that I didn't want or like you said, you have a hierarchy where everything's funneled through one place and you didn't mean that. Plus, it's good to start there because it's easier to start with a good design. Yes. where you consciously don't funnel everything through a single point of failure, then it is to dry a diagram after the fact and then notice it and then have to, you know, unwind everything. And if you're drying a spaghetti, your coat is going to be spaghetti. And it's so much easier to shift large things around in the drawing.

Yeah. I mean, if you're using a drawing program, sure, maybe it's tedious, but if you're just using a paper and pencil, it's erasing and not difficult. I think some people get lost in, oh, nobody ever looks at this documentation. That wasn't what I wanted. I didn't want the documentation. But people say, I'm not going to do that because this isn't going to, nobody's going to update it or nobody's going to look at it again. But that's not the point.

Yeah, my point with that drawing, with the drawing last week was not, this is documented. And to a certain extent, you hope that nobody looks at your source code again after the product ships, right? But that doesn't mean you don't write it. Yeah. So. It's engaging with the thought process and trying to find the complexity and reduce it or hide it under the rug or something. Hided up the rug. I told one of the engineers recently.

Look, the reason we have magic numbers all in a header file is that we're trying to pretend that we're not. toddlers, that were not messy human beings that have all of these things. And so this whole file here that is full of magic numbers and ifs and entirely things that we agree are just kind of gross because they depend on the state of the system today. Let's all put that in one file and then we can pretend that doesn't exist. And the rest of the code will look so pretty. I mean, there's something to be said for sequestering the mess. Exactly. This is where the the mess is. You're not allowed to have mess anywhere else. Right.

This is the mess file. And if you blow that mess file away, you can replace it with a different mess and your code still works. Exactly. Let's see. Scott H. asked, what's a decent way to go about handling over a largeish code base with all its context to notebooks and tooling to someone else? Scott is dreading this process and is not sure that it's a sign that it's not a great job of documenting possibly. yes. Is it worth making diagrams in this world of generic AI slop? I don't. I think yes, you should probably make a diagram?

I mean, we just had this discussion. Well, the main question is, what's a good way to go about handing over a largeish code base with the context? And my opinion on this has changed recently due to AI. The last time I needed to walk up to a decent-sized system, well, actually I'm going to take a step back there.

I often will search whatever I want on GitHub to see if there exists code already. And then, you know, if it's a driver that has a nice license, I'll go read it. Even if my driver needs to do something else, it's nice to see how somebody else has done it because they will have answered some of my questions.

I have found, as I look at larger things, some of the drone utilities, some of the flying code, even large control systems, that if I pull those into LLM, an AI, I can get it to explain what that does to me much faster. And I can ask it what it's doing and who calls what and all those things that I used to use graph-fiz for and other tools that would help me figure out, well, how many other, how many times does this get used? Is this directly through the main flow of how this code normally runs? That's not something for them to do. That's something for the recipient to do.

Well, that's actually what I'm telling, Scott, is that... Just give up and say throw it into a chatbot? No, I'm saying it... I used to not want to have large code bases handed to me. It was a pain in the ass. Now I am much more willing to take that work on myself because I have to do that thought process

interrogation anyway and somebody else's diagrams aren't always worth it. Fair. Although if you're the creator of the code base, you by definition should have the most knowledge to create some diagrams. I would say at a minimum, you should create some diagrams. If you don't have them, you should have made them and as penance you should make them now.

I would at least want a read-me on how to build everything. Yeah, at the very least. You definitely need to provide. This is these are the prerequisites you need to install, these version numbers of the tools, this is the tool chain you need on this system. Or here's a container. Here's a pointer to the container with all that stuff that you can run and build and I've tested it.

That would be very nice to have. I love it when people deliver that. because it means I don't have to sweat for a week or so trying to get everything set up. You just got it. So, I mean, that's a very nice thing to do. Sitting down with somebody and walking through the code base at a high, I mean, if you've got an opportunity to actually have a face-to-face conversation, I think it's a lot better than just saying toss it over to clot or whatever because they can ask questions of the person who actually did it. And so, I mean, there's varying steps here.

I mean, certainly many developers now will take code and throw it into the thing and have it help them organize it or understand it. And that's fine. But if you have the opportunity to actually engage with the person who owned it and wrote it, it doesn't have to be a code review. It doesn't have to be a, I'm walking you right through every line and function. It can be, all right, well, here's how this tree is structured. You've got your drivers in this directory. You've got some other stuff in this directory. You've got this stuff in this directory.

and then we've screwed up and we've got some stuff bleeding between two directories that we understand is, you know, you can lay out, you can say where the minds are much easier than something that didn't write it is going to, no matter how genius the machine is at figuring out the structure, it's not going to say, you know,

we've had trouble with this in the past. Well, and the AIs can lead you down rabbit holes. I watched somebody replace a perfectly good circular buffer system because the AI said there was a race condition. And it was, that wasn't the problem. The problem was their code hadn't set a critical area. Yes, there was a race condition. It wasn't the circular buffer's fault.

And another thing to consider, it depends on your code base, but sending all that stuff to a cloud-based AI service means that they have your code. Unless you pay for it. Mm-hmm. Sure. Yeah, I know. I know. You're talking about two large companies,

which have admitted that their little agents went for a little walkabout in the last two weeks. Wait, not everybody's heard that. Will you give the summary or? Well, both Open AI and Anthropic had incidents. Open AI had an incident where they were, quote, testing some new models in their, their internal sandboxes, and they got out and decided to solve the, they were running a

benchmark. They do this when they're developing new models. They run them in benchmarks and sandboxes. And I don't know, I think it was a cybersecurity model or something like that, but in order to solve a problem they gave it, it decided to hack its way out of the sandbox, out of open AI, and into some other companies, including, I think, Hugging Face, which is one of the big open source model websites. Yeah.

They basically committed a cybercrime, but since it's a company, I guess nobody's going to charge him with that. And then about a week later, Anthropics said, oh, yeah, that happened us too. So. So the little AIs, as they're being tested, are escaping their test facilities so that they can cheat. I mean, I don't think it knows that it's trying to cheat. It's trying to do the best job it can. It's not trying to do the best job it can. It's just, it's following its training, and its training has given it the ability to write code.

And so maybe somebody shouldn't have given it the hacking handbook? I think somebody should look at how they make their sandboxes because I think somebody made some mistakes and they're not very good at it. They shouldn't have asked this AI, how do I make a sandbox that keeps you enclosed? That is my worry, is that that's exactly what happened. But apparently it did all sorts of things left little paper trails all through their network and on their servers for follow-on models to breadcrumb through and stuff. So anyway, it's all very great. But keep in mind, and this is mentioned in the doctoral book, these guys, and I suppose gals, but it's mostly guys. These guys like to talk up their own capabilities, and you've got to be careful when they say, oh, my God, our model did this amazing, horrible thing to our.

own company, whether or not they're actually trying to sell you something. Right. That was in the doctoral book where they talked about how subliminal messaging and how that was talked up as advertisers can make you do whatever you want and whatever the advertisers want. Which was advertisers trying to sell companies on advertising. Yes. It wasn't, it was just snake oil. Right. So when they come out and say, oh, AI is going to take all your jobs or AI is going to, oh, if we got to be careful because AI is going to come and become a super being that takes over the world and slaves us all. You have to take that with the grain of salt that A, they're insane people, possibly, no offense.

And B, they're trying to talk up their product, so you think how great it must be now to give them the money. Because if you believe that you were about to create a super, super intelligence that was going to obviate the entirety of human society. and usher in a new era of whatever robot overlords. Why do you need to go public right now? I mean, why do you IPO? I mean, money's going to be gone

as soon as you finish this. So why are you running a company? Why did you write a book about how to be rich? Instead of just enjoying your richness. Yeah, anyway. So I don't know where, where do we end up from? What was the precipitating documentation? Oh, handing off code bases.

Scott, I hope that's what you wanted from this show. Another random card question. Who or what do you compare yourself to most often? Is it the dog? Because you're as cute as the dog. I promise. I mostly, I mean, in terms of a negative, like, self-talk comparison sense, it's usually musicians.

Anika. No. Although she's much better than me, but she should be. No, musicians, because that's the thing that I'm most wanting to develop myself into, a better version of myself. I think I've ceased doing that with computers. I mean, I think I used to. Like, I used to think about, oh, this guy's better coder,

this person's a, you know, smarter algorithm person, but I don't think I care anymore. So, and I think I compare myself to myself a lot, which doesn't make a lot of sense, but like, you know, my past self or what I think my future self should be. That's interesting. Tell me more. Well, like, you know, it's the, I should be always improving in some skill or facility. Oh, like when you say, oh, I haven't practiced languages today. And I say, weren't you just reading a book in French? Right. And you're like, yeah, but that doesn't count.

And I'm like, in what world does it not count that you are? I wasn't sitting down here at my desk with a textbook and transcribing something and correcting my faults and things or working on Hungarian. But same thing with music. Like, I might practice drums for an hour and then feel really bad about it because I didn't do it the right way or didn't do the things I wanted to or I'm still got to record that song that I haven't done yet and I'm just sitting here practicing. but yeah I don't yeah I don't beyond that I don't I mean I'm trying to avoid I have deleted my Instagram

I'm mostly backing away from social media entirely I still have my mastodon account although I blew up half of it moving servers yeah but I'm not I don't post much I read it occasionally to see what people are up to but I think I think I've reached the end of my social media era but Instagram was really bad for that because it's really tuned in knows you want to see, like if you're, if you have a skill, it knows you want to see other people doing that skill. And it, the way, the way people get more views on videos and things is to be more

demonstrably flashy and cool. So there's a lot of drum videos and stuff where people are doing amazing things and I don't know how many times they tried it, you know. Yeah, they're doing amazing things for 30 seconds. So, but that's just, just keeps coming at you and just makes you feel inadequate after a while. I was like, look at all of these drummers who are better than me. I never see a drummer on her who's worse than me. That's interesting.

They don't. Seriously don't. Orgami doesn't have that problem. Yeah, yeah, right, right, right. That's a different art form and it's... I mean, I do see incredible origami, but it's not something I want to do. It's kind of like watching a jazz drummer,

and you're like, oh, that's great, but it's not what I want to play. Yeah, yeah. I mean, you occasionally, see the wild multi-thousand-fold things, but that's not what you want to do. And I see

I see things I find inspiring as opposed to things I find competitive or depressing. That may be a difference between origami as an art form and where music has ended up because music has a competitiveness, especially rock and popular music. There's a skill competitiveness

to many instrumentalists, especially guitar, especially drums. Well, I am pretty confusing to the algorithm, I think, because there are some forms of origami I will just flip right by and some that I will stop at. And it's not necessarily the same ones more traditional origami people like. But yeah, so where was I headed with that? Oh, the comparison. So I used to compare myself to that kind of thing a lot. But I think the other thing is I tend to compare myself to multiple people, because I'm not.

I like doing a lot of things, so I might be comparing myself to a drummer and somebody writing a video game and somebody writing music and somebody, I don't know, learning a language and all these things I like to do. And instead of... Yeah, compare yourself to the number one in each thing in order to make sure you don't feel like you're the number one in anything. But that's the thing that social media is, oh, these are the things I'm interested in. So I've subscribed to 70 people who are good at the things I'm interested in. And suddenly it's like, well, I have to embody. the skills of those 70 people who were all the top of their game. It's not very healthy.

No. No, I've stepped away from Macedon because I wasn't good at picture descriptions. I want to be good at picture descriptions, but I'm not. And the vitriol you get when you fail is just not worth it. I'm still doing Instagram, but mostly just so I can show off origami stuff. I do look at it a little too much, but mostly because it's origami and silly things. If you start looking at the ridiculous stuffed animal advertisements and occasionally click on one, then most of your advertisements become stuffed animals.

So I'm there for that. National Park Service, Monterey Bay whale watching, a billion origami. See, I feel like we should be able to get that from somewhere else. Oh, I would love to, yes. I have been thinking lately about newspapers and missing them, missing reading the newspaper in high school and in college. Who do you compare yourself against? Whom do you compare yourself against?

Is it who? Yeah. Do you compare your, okay. I shouldn't ask the question unless I was going to be answered in return. I try not to compare myself against you. Why would you compare yourself against me? That way leads to madness. you were so talented.

You speak French, like, really well. No, I don't. You only recently started relearning it, and now you're doing Hungarian. Over a year ago. And I can barely speak English, and you're maintaining both, and you play... Come on, Hungarian's easy.

We both learned that if you want to say, what is that, you say what bat. Me ass. And I mean, your musicality is incredible. Fine, I didn't, no, no, no, no, no. And you're kind, and you're really smart. Okay, so I try not to compare myself with you. There are people in my life who are role models,

but I don't really compare. Okay. That's super healthy. Yeah, I know. Or if I do, it's with fictional characters. Well, you know they aren't real. Yeah, but sometimes I want them to be. You said there was another listener question.

Simon asked, when is it really worth the effort to get embedded development off the hardware and do it on your PC? Oh, good question. I like doing it when there's a core algorithm of some kind. So if your thing is a Bluetooth device that has one sense... Uploads a sensor or something, it's not that attractive. But if you have like an algorithm to compute something, that's an ideal place to have a unit test that's off the device because you can run it more at your leisure,

infinitely with more inputs and outputs and stuff, faster. Stuff like that is very useful. I think if you have, sometimes you have a platform, like if you've got more of a complicated, embedded platform that runs dynamic code, more of an operating system kind of thing, like the smartwatches, I think that's another case where the complexity is such that it's hard to develop on the hardware with the iterative speed you want. Those are the two things I would say.

You've got an algorithm that's complex and you want to develop it. And you have something where the iteration speed development on the hardware is a limiting factor. Both of those are the same answer, actually, because if you're doing the algorithm, you don't want to be messing with developing an algorithm on a microcontroller. And if you have something, you can have a file replace the input and a file replace the output, then do that. that. Simon did have some more context. They're regarding pain with networking and Zephyr's native sim. Oh, right.

It is faster, maybe more professional, if you can avoid using your target hardware for a lot of the software development process. Sometimes. Shouldn't we just make it work with a couple of targets? We're 99% likely to use. actually not sure I understand that last question. I don't understand the last one, but I mean, it's very difficult to emulate a complete SOC.

You can do it, like you can do it. You can do it in a QAMU, and there was that other thing we talked about a while back. I forgot the name of it, starts with an end. Anyway, there are platforms you can do that. You can run, I think, Zephyr on QMU and do all that stuff. Well, and I think Zephyr does have, I think Native Sim.

It does have some, but I think he has a specific issue with networking. I thought he was using WSL too to run it or. Yeah. But the question itself. There's a hat in a hat and a box in a box kind of going on. So once you add a lot of complexity, it gets more complex. When your peripherals are the driving force of what you're doing. Yeah.

Simulating those does not do you a lot of good. if your complexity is out on the edges of your device, it's not running software inside your core. Yeah. That is harder to simulate. Not impossible. You can still do unit tests. Unit tests are still great.

You can have mocks so that you still get files in and out. But the first thing you want to do to get off of your microprocessor are the algorithms. And the second thing might be whatever. is most complicated. And it's a pain in the butt. Like, this is why it's a judgment call, because I think I can count on less than one hand, perhaps, how many times we've actually had an abetted thing

with an emulator or a simulator of the whole thing. Oh, of the hardware too? No, I know. The whole system? No. I mean, Zephyr does that make that a little easier? Because there's the SIM targets now, and there's a bunch of SIM things for peripherals.

So you can do a lot more in Zephyr than out of the box than you could with, you know, free R-Tos or ThreadX or whatever you had on a pick or a Cortex M3 back a few years ago. But it's a lot of work. It's a lot. It's another thing to maintain. So it's not like you just get it for free. And suddenly I'm running my code without any hardware a lot of the time. There's a lot you can do with Wauqui, too.

Yeah. I don't know if you could do Zephyr on that or something that heavyweight, but I'm going to have to try that. But there are emulation platforms out there other than Zephyrs, if you're having trouble with Zephyrs. But yeah, I haven't really done that a lot because a lot of times the hardware is fast enough. You know, the iteration time isn't that, it's a few seconds most of the time with a good J-tag to download new firmware. they boot fast. It's not like it used to be where I'm waiting a couple minutes between finishing compiling and getting new code running.

Yeah, I mean, when you said only five times done this, I was like, what? I do this all the time. But the truth is, I only do part of the system. Right, yeah. Whatever system has the most complexity or whatever system has, or whatever system has the most need to change or that somebody else is in charge of. The risky parts.

The risky parts. But even when I'm doing a key value store or a simulated e-prom on a flash, I mocked those up. I did when I first developed them. But now that there are like five different versions you can get off the shelf and most vendors have them as part of their hal. no, I'm not going to mock those up anymore. I'm just going to trust if they work. There was one thing I think he said. This is the same person who said something about multicast and networking.

I thought they might have mentioned in the Slack, but if it is, and you're doing something with networking that's challenging or complicated or you haven't done before, I would encourage you to not think of emulation at all or simulation. I would write the thing you're trying to do in desktop software or Python or, or whatever. Write it to do the thing you want to do networking-wise and make sure you understand how to make that work because multicast is weird.

Networking is weird if you're doing any kind of active thing because it's not just like TCPIP, unicast where you have an IP address and you send something to another IP address and you go back forth. Multicast involves joining groups and leaving groups and the network has to believe you and the interface has to be configured correctly to do the right thing.

So if it was something like that, I would do a prototype, a prototype, not on the hardware, that I'm going to throw in the trash. But at the end of it, I will know at least it can work, and I understand it from a conceptual standpoint. And then when it doesn't work on the hardware, then I can at least have some angles to try to figure out why. instead of, this just doesn't work well, is it the hardware? Is it a bad driver? Or is it that I don't know what I'm doing? Yeah, especially with networking. It's really easy to say, this doesn't work, and then you realize your masks or your networking was set up wrong.

And you didn't even know that was a thing. Or maybe it's not even your device. Maybe your network isn't set up correctly, but you're focusing on your device so much that you didn't configure the router properly and it's not doing IGMP snooping or, You know, whatever. A network is a network. It's not a single device. All right. Well, that covers our listener questions. I think that covers everything. All right.

Then we're going to call that the show. Thank you so much for listening. If you'd like to contact us, hit the contact button at embedded.fm, where the show notes will be. And thank you. Thank you for listening. Thank you to Mark and everybody who, volunteered and who actually wrote letters for our meritorious achievement award in outreach and informal education,

which I'm really pleased by. I'm really pleased the show actually makes a difference for people. Me too. Ready for some Winnie the Poop? Mm-hmm. Okay. Everybody in the 100-acre wood is going on the expotition to the North Pole.

All right, said Iyore. We're going, only don't blame me. So off they went to discover the pole. And as they walked, they chattered to each other of this and that, I'll except Pooh, who was making up a song. This is the first verse, he said to Piglet, when he was ready with it. First verse of what? My song.

What song? This one. Which one? Well, if you listen, Piglet, you'll hear it. How do you know I'm not listening? Pooh couldn't answer that one, so he began to sing. They all went off to discover the pole. Owl and Picklet and Rabbit and All.

It's a thing you discover, as I've been told, by Rabbit, Owl, Piglet, and All. Eeyore, Christopher, Robin, and Pooh, and Rabbit's relations all went to. And where the pole was, none of them knew. sing a hay for owl and rabbit and all. Hush, said Christopher Robin, running towards Poo. We're coming to a dangerous place. Whush, said Poo, turning round quickly to Piglet. Hush, said Piglet to Kanga.

Osh, said Kanga to owl, while Roo said, Hush, hush, several times do himself very quietly. Hush, said owl to Eeyore. Osh, said Eeyore in a terrible voice to all rabbits, friends and relatives and hush, hush, hush, hush, hush, hush. They said hastily to each other all down the line until they got to the last one of all. And the last and smallest friend in relation was so upset to find the whole expedition was saying, hush to him that he buried himself head downwards in a crack in the ground and stayed there for two days

until the danger was over and then went home to a great hurry and lived with his aunt ever afterwards. His name was Alexander Boodle.