Embedded - 461: Am I the Cow in This Scenario?

Episode Date: October 5, 2023

Chris and Elecia discuss the pros and cons of completing one project or starting a dozen.  Elecia’s 2nd edition of Making Embedded Systems is coming out in March. (Preview is on O’Reilly’s Lea...rning System.) She’s working on a companion repository that is already filled with links and goodies: github.com/eleciawhite/making-embedded-systems.  If you’d like to know more about signal processing, check out DSPGuide.com aka The Scientist and Engineer's Guide to Digital Signal Processing By Steven W. Smith, Ph.D. And as noted in last week’s newsletter, there is an interesting overlap between smoothies and the Fourier Transform.  Giang Vinh Loc used  Charles Lohr’s RISCV on Arduino UNO to boot Linux (in 16 hours).  We also talked a bit about Greg Wilson’s recent episode with Elecia (Embedded 460: I Don’t Care What Your Math Says). Transcript Thanks to Nordic for sponsoring this week's show! Nordic Semiconductor empowers wireless innovation, by providing hardware, software, tools and services that allow developers to create the IoT products of tomorrow. Learn more about Nordic Semiconductor at nordicsemi.com, check out the DevAcademy at academy.nordicsemi.com and interact with the Nordic Devzone community at devzone.nordicsemi.com.

Transcript
Discussion (0)
Starting point is 00:00:00 Welcome to Embedded. I am Alicia White, here with Christopher White. It's just us this week, and this is a special episode. We will explain why later. But it is a special episode of us chatting. Too early. It's too early? Yeah, it's too early in the morning.
Starting point is 00:00:25 How are you? It's too early. It's too early? Yeah, it's too early in the morning. How are you? It's too early. Have you recovered from missing Greg's episode? Have I recovered from missing Greg's episode? Mm-hmm. Well, missing the Greg's episode wasn't the thing I need to recover from. But I'm feeling better. Good, good, good.
Starting point is 00:00:41 Don't schedule a vaccination on top of a podcast is the moral of the story. If you're me, you apparently suffered no great immune system. No ill effects. I was sad to have missed that episode. What did you think of it? It was very interesting.
Starting point is 00:01:00 I think there were definitely some thought-provoking things that he, that he proposed, uh, some of which I agreed with and some of which I probably would have taken some issue with on the show, but he's not here to defend himself. So I don't really want to hash that out too much. Um, yeah, a lot of people seem to really resonate with the episode. We got a lot of feedback in Slack and through email, software, writ large, so long in an ad hoc way, it's kind of hard to put things back in the bottle and start over, not start over so much, but bolt on ethical principles and regulatory bodies
Starting point is 00:01:56 and rules and regulations. Even education processes. Even education processes is something that's kind of grown organically and haphazardly for a better part of a century now. Based on what we've needed. Yeah. And I think the other thing that, this wasn't really a criticism, but it was something that came to my mind, is that software, it's hard to talk about as a thing. It's kind of like talking about writing as a thing. There's kind of like talking about writing
Starting point is 00:02:25 as a thing. There's all kinds of different writing now, some of which is fanciful and for fun, and some of which is very serious. There's certain types of journalism where if you make a mistake, that could have serious consequences.
Starting point is 00:02:42 And there's writing stories for sci-fi that go in analog magazine, which if you make a mistake, what does that even mean? That's the plot. So I think that's one of the hard things I had thinking about applying more rigor to software is it's important to understand where we need to apply rigor because we don't have the resources and the capabilities to broadly refactor, refactor is a terrible word, broadly remake the software development community. And I think we need to focus our efforts where it's important. And not all software is important.
Starting point is 00:03:20 Fair, fair, fair. Do you agree with that? Yeah. And I mean, he used the medical industry a lot. Right. Fair. Fair, fair. in some cases, I can take a first aid course. Yeah. That doesn't make me a professional. Yeah, yeah. But it might make me enough. I mean, like babysitters usually go ahead and get the first aid certification because it's good to have.
Starting point is 00:03:57 But that doesn't mean they should be doing surgery. Yeah, and I think that comes to something else that I remember. I think it's important for people doing... See, the computer science thing is confusing, too, because there's computer science, which is really a mathematical discipline, and then there's software... You mean the algorithms part. Well, I mean, if you take computer science in college, that's what you're supposed to be learning. If it's just software engineering, then don't call it computer science. I don't know. What's the difference there? I mean, engineering is getting stuff done. In practice, there's very little difference right now, I think.
Starting point is 00:04:36 I mean, computer science, you take languages courses and software development courses, but you also take algorithms courses and more theoretical stuff. I think the computer science part should be, this is my personal stupid opinion, I think the computer science part should be limited to the actual science of computing, which is not the same thing as software engineering. So like O notation and structures? Sure, things like that.
Starting point is 00:05:04 Structures. Data structures. But the more mathematical parts, the parts where, you know, people write papers for things, right? You're not writing a paper in your JavaScript class for a publication or your intro to, I don't know,
Starting point is 00:05:24 intro to sorting algorithms don't know, intro to sorting algorithms. So it's kind of a mishmash because we talk about computer science and I think that term gets abused as all software development because that's where you learn software development in college is you get a CS degree, right? So I think that's a bit messed up. When I talk about the degree I did at Mudd, which didn't fall in the normal ranges,
Starting point is 00:05:51 I say that I did all of the theoretical engineering and all of the applied CS. I didn't take many of the CS courses where you didn't actually type on a keyboard to get... Well, you still do that, but okay. To make a program. Yeah, all right. And that was intentional, because
Starting point is 00:06:09 I found, I think, what you're calling computer science to be deadly dull. Well, you wouldn't have enjoyed math either. Except for Fourier, I did not. Right, but that's okay, we're off topic. What you found dull or not is not.
Starting point is 00:06:27 But I think basically, I mean, what I wanted to do was a software engineering degree. And that's kind of what you're saying I did. Right. Because I kind of avoided some of the more esoteric CS courses. So where I was headed with that thought, where I got split off in the distinction between CS and software engineering, is regardless, I think his point that everyone should have a basic grounding in scientific methods is a good point. Because that way of thinking is useful in engineering, it's useful in theoretical stuff, it's useful in life. You know, being evidence-based, being able to analyze data and understand what it means, being able to recognize when your data is perhaps faulty or flawed or badly collected or understanding error, that kind of thing is super important. And having some notion of what a rigorous approach to solving a problem is, I think, is useful. And when he was saying that, I was like, well, I took all those courses.
Starting point is 00:07:30 I got that. And then I was realizing, well, do you get that if you just go for a CS degree at a standard state university? I don't think so. We did science. Yeah. The college we went to, it was all science-y. First couple of years, we were taking chemistry and physics and, you know, all of those courses. And when he was saying, you know, people should spend a lot of time in the lab, I was kind of like, yeah, I did.
Starting point is 00:07:51 I did spend a lot of time in the lab. I was doing chemistry experiments for reasons I didn't at the time understand. Anyway, but I do I think are important. I do see the value in that. But, you know, kids going to college may not. That's the hard thing. I mean, they're being asked to learn everything we learned plus everything that has come along since. Yeah, you throw some stuff away.
Starting point is 00:08:28 Unfortunately, I think ethics is one of the things you often end up throwing away. Wow, maybe. So changing the subject, I started a new Classpert cohort. And I asked the Classpert students to do some lightning round questions as part of their sort of introductory assignment. And I got a really good answer from one from Mike. And it is on, do you usually complete one project or start a dozen? Okay. What is your answer for that?
Starting point is 00:09:00 I mean, I start dozens and dozens. Clearly, there are piles of projects all over the place. Have you looked in the garage? You sound like you feel a little bad about that. Well, yeah, I'd like to finish some things. Because then I can have more space for more projects. Mike said, I start at least a dozen. I don't really see them as incomplete, though.
Starting point is 00:09:28 I think test projects, or just-for-the-fun-of-it projects, are to a coder what scribbling is to an artist. I wouldn't think of an artist's scribbling as incomplete if they didn't cover the entire page. What makes a thing like that complete is the fulfillment it brings to the artist. The same is true for coders and their scribblings. What makes a thing like that complete is the fulfillment it brings to the artist. The same is true for coders and their scribblings.
Starting point is 00:09:52 I think a lot of people feel bad that they don't finish their projects, that their answer to that question is start a dozen. And I never meant for that to be a... Accusatory. Accusatory. Yeah, yeah, yeah. Not at all. I never thought that either. If you start a dozen, that's great.
Starting point is 00:10:08 That means you're interested in a lot of things. Half a ukulele is still half a ukulele. That is true. And it appears that it will always be half a ukulele. No, I'm going to get that damn thing finished because I have a guitar kit that I haven't even started. So that doesn't count. Yeah, I mean, that's definitely true of things where, yeah, the sketch analogy I really like. Because that's, you know, for trying programming things, I really like that idea.
Starting point is 00:10:41 And there's certain projects, you know, there's certain things where it's like, I'm building something. This is what I want to build. And then I want to have the thing. And so if you don't have the thing, you haven't really finished. And that makes me feel more guilty than, oh, I went and played around with a game engine and made a little thing and,
Starting point is 00:10:56 you know, it did something and then I threw it away. That doesn't bug me at all. Like you're saying, you know, that that's exploratory little fun things. Are you still in, were you enjoying the ukulele the last time you touched it? Yeah.
Starting point is 00:11:11 Yeah. It's hard to get. I don't know why I haven't gone back to it. I mean, for a while it was because where you were working was too cold. And now I think where you're working was too hot. No, it's always too cold now because there's a heat pump water heater in there. Right. It's difficult.
Starting point is 00:11:28 It takes a lot of time, and I kept making mistakes. And so it's just harder than I expected. So I just need to go down and spend the time on it. But, you know, there's other things that bubble up that – that's the problem. It's kind of the lowest priority project all the time so there's always another project that that's like i gotta build a hammer a radio transceiver so i can get this uh ham radio thing with my dad going and you were working on uh morse and then you took a break for a little while to do some music no i, I just, taking a break from something that takes five minutes a
Starting point is 00:12:05 day is just me being badly organized. But no, I have, I have. You have, like you said, dozens of projects. Yeah, but I spend a tremendous amount of time doing nothing when I could be doing something. Do you know that when cows are making milk? I thought you were going to say when cows are making tools, referencing the far side. Do I know when cows are, am I I thought you were going to say when cows are making tools. I'm referencing the far side. Do I know when cows are making... Am I the cow in this scenario or the milk in this scenario? You're the cow. Uh-huh.
Starting point is 00:12:34 It doesn't... It isn't like they look like they're doing anything. They're just standing around just chewing. You're allowed to do nothing. Sometimes doing nothing is the most important part of getting something done. No, no, I don't think that's, no. I don't think sitting on the couch and surfing the internet is productive of any sort. What did you say?
Starting point is 00:13:01 Something about a cow? Oh, am I the cow in this scenario? Sorry, I had to write down the title of the show. Okay. Before, yeah. I do admit that I have too many things I'm interested in, and so that makes me a little bit harder on myself when not all of them are progressing. and project completion and all that stuff.
Starting point is 00:13:46 And it's not necessarily one is bad or the other is good. It's a way to look into how you do things and maybe see that things could be improved. That's all. That's how I see that question. And it isn't intended to be one is better than the other. Yeah. They both have tons of value.
Starting point is 00:14:06 Finishing projects is awesome, but if it's a project that you pushed yourself through and didn't enjoy and all of that, that's not as awesome as just dropping it and going on to something else. Here's the thing I think about projects. I think about projects as a stepladder. One project gives me skills that lead to another.
Starting point is 00:14:26 And so if I get stuck on one project, I'm not moving up the ladder. And so if I have 12 projects, I have 12 ladders. That's perfectly fine. But if I'm constantly on the first rung of all of those ladders, then maybe there's something I need to look at there to start moving up some. And the idea with having multiple ladders is you can go sideways. Yes. All right.
Starting point is 00:14:49 Enough with that metaphor. I don't know how cows climb ladders anyway. This episode is sponsored by Nordic Semiconductor. Nordic is a market leader in IoT connectivity, creating the IoT devices of the future. They specialize in ultra-low-power wireless communication. Their portfolio includes Bluetooth Low Energy, LE Audio, Bluetooth Mesh, Thread, Matter,
Starting point is 00:15:23 Cellular IoT, and Wi-Fi. Is there anything else? Laura? They don't do smoke signals. They don't do smoke signals. They don't do Morse code. They can have that. We'll ask them to add it.
Starting point is 00:15:34 Nordic has a vast ecosystem of development tools. Developers can reduce their development cycles and accelerate their time to market. The NRF Connect for VS Code extension provides the most advanced and user-friendly IoT embedded development experience in the industry. Yeah, because it's VS Code. And Nordic is giving away six PPK2 power profiler kits. And these are standalone units which can measure and supply currents all the way from sub microamp as high as one amp. And this works on the Nordic
Starting point is 00:16:14 dev kits as well as external hardware. So it's a nice power profiler kit. If you would like one, answer this question. What is your favorite PPK2 feature or spec? And there's a right answer to this. So answer by the end of October and we will see who wins that kit. In the meantime, for the PPK2 or their various and wonderful chips, check out nordicsummi.com. We are proud to have them as sponsors of this show. Okay, so I'm a class part, adjusting for the whole asynchronous cohort where we don't have a weekly meeting. Instead, we just chatter on Discord all the time. Is that better? For some students, it seems to be. I suspect we have some students who are just like, have declared Discord bankruptcy and are just not going to follow anything, which is kind of sad.
Starting point is 00:17:15 I'm trying to pull them along through some of the quieter channels, sending out emails and stuff. But we're supposed to do Micro Madness next week, which was always one of the most fun things about doing the cohort. This is where you give them a giant pile of dev boards and they're supposed to sort through them and make them do battle until you choose the one dev board that rules them all. Yes, although there's no physical dev boards.
Starting point is 00:17:47 It's all just links to, or actually just names of dev boards. Data sheets. And they have to go out and scavenger hunt on the data sheets and things like processor size and amount of RAM. So switching that to be asynchronous has been, I mean, I keep coming up with plans and then realizing, no, that's going to be super boring. But I think we've got one now. But it made me, as I was working on it and I was talking about it with people, it made me put the blanks for the way I usually run it as a, like a March madness basketball style tournament. Right, right.
Starting point is 00:18:28 Into my GitHub. Oh, okay. My GitHub for the new book. Right. And so, github.com, Alicia White, making embedded systems.
Starting point is 00:18:42 Alicia White is Echo Lima Echo, Charlie India Alpha, Whiskey Hotel India Tango Echo, which is to say no spaces, dashes, or anything, and you have to spell my name correctly, which is like electricity and not like E-L-I anything. Yeah, I don't think there are any words that start with E-L-I. It lied. It lied. Electricity, though.
Starting point is 00:19:02 I'm a lot more like electricity. This was just an excuse for you to show off your phonetic alphabet skills. Oh, yeah. I worked hard on those. Like every night for like a year, I would go to sleep spelling things. Explains a lot of things. So you have this GitHub, and it's the companion to your second edition of Making Embedded Systems, which is currently in progress.
Starting point is 00:19:26 And you now have written 98 chapters. Gosh, it feels like that. And it's going to be a six-volume set like Knuth, with the last volume always coming soon. Yeah. But yes, so the GitHub contains what exactly, besides March Madness? It goes chapter by chapter with the book, which I think is going to make some things hard to find. But the book is supposed to have a little bit more code than it did before.
Starting point is 00:19:56 I haven't actually done any of the code because the GitHub isn't really supposed to be ready until March. But in the meantime, I have just dumped links in there and things that I use like calculators for figuring out timers and power consumption calculators. I just keep throwing things in there, including the March Madness blank.
Starting point is 00:20:21 And anytime I find something interesting, like this morning I came across from Classbert's Discord a computer organization, how you do, like how processors are organized. Yeah. There was a long course about that, as well as like a 90-minute read and a video. So I'm just kind of collecting things I find interesting.
Starting point is 00:20:49 Well, I mean, it's hard to, that's one of the difficulties of writing a technical book in this era is there's so much information on the web and it's kind of difficult in a print book to call out. It's like you can't put a url with 5 000 things in a bunch of uh encoded encoded strings in a in the middle of your text to say go read this right i mean if somebody's reading the electronic version you can have links but um it's cool to have some to find a way to have that as well as the print book and this be the kind of the, okay, here's where to find more information.
Starting point is 00:21:27 And the other hard thing is like stuff goes away, right? So you can't really put it in print. Well, I did before. Yeah. And I'm definitely still keeping the further reading section where I suggest further reading for each chapter because each chapter could be its own book. But yeah, this does let me put in sillier things too.
Starting point is 00:21:49 Like I put in all of the games that are like how to make logic things and how to do assembly program. The Shenzhen IO style. TIS 1000 or whatever that game was. Yeah, TIS 1000 or whatever that game was TIS 100 and I don't really have a place for those in the book but they certainly are links that I end up trying to find all the time and so now I'm going to have a link
Starting point is 00:22:15 where maybe I can find the links I keep sending people I think I said this morning it's the director's commentary for your book I am on chapter 9 it's the director's commentary for your book. I am on chapter nine, which is the math chapter. I mean, it's now chapter 12, the math chapter. And you hate math, so I'm sorry.
Starting point is 00:22:36 I have never liked this chapter. And I was trying to go through and figure out what I could cut, because I'm starting to hit page boundaries. I've gone over what I said I was going to write. Yeah. As evidenced by the fact that now there are going to be 14 chapters instead of 10. But, but even as I try to cut things, I'm like, I don't know any place else that talks about how you do,
Starting point is 00:23:03 how you go from a normal average to a windowed average and how that's different and how truncation works into that. And, sir, you can use Q numbers in CMSIS for faking floating point. But what the heck does that mean? If you don't know, how are you going to be able to really use the Q numbers? I haven't seen a good description of Q numbers. I just kind of learned it from seeing what somebody else did or looking at the docs for the libraries and stuff.
Starting point is 00:23:40 Yeah, it's not super intuitive either. And the book actually builds it up. Like it doesn't start with here are Q numbers. It's like, well, you can scale things. And if you scale things by powers of two, then you can do this. I don't know. I have really forgotten a lot about this book. I'm really surprised I wrote it.
Starting point is 00:24:02 Well, there's the DSP book, the Analog Devices DSP book has some of that kind of stuff, like you were talking about the averaging stuff. But I don't remember if it had number representation and things like that either. The latest copy does. This is the
Starting point is 00:24:19 DSP guide, and it started out as an Analog Devices boy, I'm going to have to look up this, DSP Guide. And it started out as an analog devices. I don't know if they ever paid him for it. Yeah, it's a free book. But now it's a free book. You can buy a hard copy as well. But I would look up for the dspguide.com because the old version,
Starting point is 00:24:43 he's been adding to it for a long time. It's really good. It's a great resource for signal processing stuff, but obviously that's not what your book is about. But you have to cover all of that, because you called it making embedded systems instead of making very specific embedded systems that don't have these five things I don't want to write about.
Starting point is 00:25:06 So many things. I keep like, okay, I'm going to put in a short section about machine learning. How do you put in a short section about machine learning? You should just not do that. No, I am. Because I want to say, go look at TinyML. Okay. And I want to say, go look at TinyML. Okay. And I want to say, set expectations.
Starting point is 00:25:27 You're not going to be identifying between 10,000 images on a Cortex-M0. Yeah. That's just not going to happen. Yeah. And so machine learning has a lot of good stuff, but you don't train on the devices. Well, you can if you've got enough time. Look, somebody just booted a RISC-V emulator on an Arduino
Starting point is 00:25:55 Uno and had it boot Linux. It took 16 hours to boot, but it booted. I'm shocked. Yeah. How did they get enough RAM? I think, you know, I don't know how it works. Maybe they had an offline thing. You must have an external RAM.
Starting point is 00:26:15 Yeah. Or maybe it's a very tiny, I don't know. I don't think you can get Linux that tiny. Well, the emulator is only 400 lines of code, the RISC-V emulator. That part doesn't bother me. No, that doesnulator is only 400 lines of code, the RISC-V emulator. That part doesn't bother me. No, that doesn't bother me. The Linux kernel bothers me. I'll find the link for it.
Starting point is 00:26:32 Maybe I put it in the newsletter. I don't remember if I put it in the newsletter or not. But it's a thing. Did you put the DSP Fourier filter is a smoothie recipe generator? Yeah, that was in this week's.
Starting point is 00:26:48 Okay, that was pretty cool. I liked that. It was a low math version. It starts low math, but it gets to it. And then there's a video, so you can stop whenever you're... Don't you think you would appreciate Fourier more if you'd done what I did in Real Analysis 2 and develop it from first principles so you can fully understand and be one with Fourier. Fourier is great because the world is made of circles and sine waves. Orthogonal basis function. It's not just Fourier. You can do
Starting point is 00:27:15 those kinds of transforms with all sorts of sets of orthogonal basis functions, Bessel functions, trigonometric functions, which is Fourier, but there's a whole bunch of other stuff out there, and you can do all kinds of cool stuff, and you're really limiting yourself. Applied CS and theoretical engineering. I feel like you just did that to be cool. It was cool. I took the classes I wanted to take. I also took the classes I wanted to take, and some others. Yes.
Starting point is 00:27:48 Anything that didn't involve Russian tanks? Russian tanks? No, no, no. There were no Russian tanks. What? Oh, there was just a lot of Russian and a lot of tanks. Yes. Those were separate.
Starting point is 00:27:56 Those were separate. No, no. Well, I took theoretical math. I guess I took applied CS too because I mostly took the networking and CS courses did I take? Security, networking, all the kind of IT stuff. All the classes you could get out of because you were already on the computer science administrator. Because I was already doing it for a full-time job. Yes. Yeah.
Starting point is 00:28:21 And the prof was like, you already had to deal with this. I think I took networking while working at Cisco. Yes, that was pretty hilarious. Ready for a listener question? All right, hit me. From Sila, cookbook approach versus hands-on in time-consuminess. What's the question? How do you feel about taking a cookbook approach where you
Starting point is 00:28:50 follow a recipe or a tutorial versus doing something hands-on trying to figure it out yourself? I approach this the same way I approach writing functions. You look to see if you can copy it from someone else and if you can't you do it yourself
Starting point is 00:29:10 no if I find myself writing the same five lines of code over and over again I make it a function if I find myself having to do some sort of skill over and over and over again it's probably worth trying to understand it if you're solving a fixed problem that it's probably worth trying to understand it. If you're solving a fixed problem that you're probably not going to come back to for a while, the Codebook approaches are fine,
Starting point is 00:29:31 or if it's the first time you're encountering it. I think they both have their place, but I kind of... It's the 12 projects problem again, but I try not to start a new project which involves learning something if I'm just trying to fix a little corner of something. Does that make sense? How to stop overlooking things.
Starting point is 00:29:57 Oh, I was wondering if you were going to answer. Oh, this is a continuation? This is a continuation. Oh, okay. Overlooking things versus exploring problems that are really not time feasible. One of the problems with the cookbook approach. Oh yeah, is you don't understand what's going on. Is that you don't understand what's going on. Yeah. And so you overlook an important piece because it wasn't in the recipe. Yeah. I don't necessarily have baking soda. Baking powder sounds the same. Should be fine.
Starting point is 00:30:29 Usually is. Well, that is the problem. And you have to know the travel with the cookbook approach, which is basically the stack overflow approach to development, which is what everybody does now, is to find an example of something. Yeah, that is sometimes an insurmountable problem, which means you do have to, you can kind of mix it up. Like you can take a cookbook and then you can kind of explore a bit
Starting point is 00:30:53 and see how maybe it works under the hood and maybe see other people's cookbook solutions for the same problem. But it's tricky and it's the same, you know, that's the problem with the code generators, the AI code generators and the ML stuff, is that's all cookbook, right? It's worse. It's an automated chef that goes and gets the cookbook for you
Starting point is 00:31:15 and then delivers you the completed meal. And if you don't understand what it's doing, then you don't have a basis for knowing whether you've overlooked something or not. So I think it comes down to what the problem, how complex the problem is you're trying to solve. Like if it's a small little thing like, oh, I need to know how to reverse a linked list, let's say, and you just grab a function that does that, it's probably going to be okay. But if it's something more complex, then when there's a bug, you're going to be forced to kind of go to the deeper exploration route.
Starting point is 00:31:52 And that is actually the final part of the question. What are your thoughts on learning about something to its origins or learning just enough to do your thing? Oh, boy. Boy, that's my big downfall. Tell me about your physics degree. Yeah. One of the reasons I did poorly in physics in undergrad was because I did not, I just could not accept random stuff that was just thrown at me. And so one example would be like magnetic flux, where you've got the integral.
Starting point is 00:32:25 They just hand you the integral to compute the flux through a loop or something. I want to know where all that stuff came from. And they weren't giving us Maxwell's equations or where those came from early on. So in freshman physics, it was just, here's a new integral. Do this thing. And I would get stuck
Starting point is 00:32:40 because I was trying to understand it. And what I didn't understand was that I couldn't understand it. Well, they did. I mean, they tried some things. Like they would give you the integral for a torus and then ask you to do a cylinder. That's just math. That's fine.
Starting point is 00:32:56 I didn't understand. I couldn't expand that way. Well, that's because you hadn't been taught calculus correctly. That's because my calculus was bad, yeah. But you couldn't just take the initial equation. We didn't have the same problem. Yeah, that was just an example, but there was tons of stuff like that where it was just, here's how this is. And I couldn't solve problems that way because maybe I was too lazy to memorize stuff.
Starting point is 00:33:20 That's part of it. I didn't want to just memorize all these stupid things. Because when I get in trouble, I like to be able to get back to where I was. And if I got in trouble in physics, it was very difficult for me to kind of come up with those equations that they, even for motion stuff, like, where did this come from? Or there'll be some trick that, there are a lot of tricks in undergraduate physics, because they can't teach you all that stuff. Because when I took graduate physics and they actually developed all of that and I finally understood where it came from, I realized how much that required. So either you don't teach freshman physics or you teach it in a way that I couldn't deal with and not develop any of the machinery that builds freshman physics. That's why I loved graduate physics, because I got to build all that stuff. And some of that stuff that they taught in freshman physics was way harder than the solution methods that they taught in graduate physics, because once you had the math, there were solution methods like the Lagrangian for equations of motion that were way easier than anything they were doing and you didn't have to memorize anything.
Starting point is 00:34:26 It was just, this is how this works and you can solve a couple of differential equations and bam. But now could you explain the Lagrangian? No, because I haven't done that in 10 years. And because it is very hard. It's not that hard. Well, it's not freshman physics. Well, yes, not freshman physics. Well, yes.
Starting point is 00:34:46 So the problem I had was I could not accept things without understanding them from somewhat first principles. And after doing the graduate stuff, you know, when I got stuck on a test, it's like, oh, I forgot this stupid equation of motion. How does that work? I could derive it in a minute from first principle because I understand how it worked. So that's, you can get in a trap though. And if you get in a trap where you're always deriving things from first principles, you're going to get, you're just going to spend your entire life proving the existence of the universe. So you have to kind of accept some things as here's how to do this, unless you want to be a person who studies those things it can be very useful to understand things from first principles
Starting point is 00:35:28 so you're not constantly looking stuff up or referring to things or it gives you some agility to develop new ways to solve things but i'd say for most software or engineering stuff it's probably better just to kind of learn the best, the methods and stick with them. Sometimes. Embedded bit shifting is something that, while I don't think you should memorize everything, you can't
Starting point is 00:36:06 fake bit shifting. You can't look up how to read this part of a register. You really have to understand that this hex goes to bits, and these bits can be moved around. They can be cleared, they can be set,
Starting point is 00:36:23 and you need to know the ands and the ffs and all of that. But I think of that as a first principle. How can you shortcut that? And you can't shortcut pointers, which is really horrible because I think it's a part, a thing people don't understand coming into computer science or into software development. And languages that are not C and C++ have a different treatment that allow for a much... Python does indeed have pointers.
Starting point is 00:36:58 Well, if you're using pointers in Python, you probably need to... Well, the thing, a lot of times you do use pointers in Python, you just don't know it. And sometimes you don't, and things can go very weirdly. But I don't have a list of things you need to know from first principles. Yeah, no, I agree. Right, and what I'm saying is not that you should never understand things deeply. There's definitely fundamentals. Fund fundamentals fundamentals should be understood deeply um and what you're talking about are fundamentals i'm talking about it like you know i was going back to her the first part of her
Starting point is 00:37:37 question and linking it to this it's like if there's a little algorithm or something do i need to go understand q sort to you to QSort to add a sorting to something? No. I'm not going to spend half my day researching sorting algorithms. I'm going to call a library function and get on with things until that proves to be too slow or something's wrong. But that's totally different from like, do you know how to do bit math or what a pointer is? Because it's very hard to write code for an embedded system if you don't know those things well. So I think there's a little bit of a difference there. But I don't know, as a learner, how to identify which things are fundamental.
Starting point is 00:38:21 And this isn't just embedded systems. I mean, this is anything you're learning. There are going to be things that you have to decide. I'm going to accept this so that I can progress, or I'm going to stop progressing and get to the bottom of this so that I can understand it more deeply. And I think the worst thing you can do is flip back and forth between those very quickly.
Starting point is 00:38:47 Oh, that's what I did. You want to know all the way down to the ground, great. But then you have to do something right away. Oh, no, I'm going to switch. Oh, but I really want to know. But I'm going to switch. And that flux. This is how I never got any homework done.
Starting point is 00:39:03 That flux makes it very hard to do either one. So that's actually one of the things I like about some of the timed study methods or work methods like Pomodoro, where you can't flip back and forth that fast, or you're not supposed to. You're supposed to focus. And that would be the advice I would have if you're thinking about this problem hard is to do one or the other for at least 30 minutes or 15 or whatever you set, but don't flip between them constantly. I understand the desire. You can write down all your questions when you're in desire. You can write down all your questions. When you're in cookbook mode, write down all your questions. But keep going through cookbook mode until you get to the end.
Starting point is 00:39:52 Because when you get to the end, some of those questions may have been answered. Right, yeah. I think it's a good point to bifurcate it into different modes and find the things that you want to go deeply on and make that a separate task. Yes. That's education. And then focus on that separate task as a separate task. Yeah.
Starting point is 00:40:14 And if at the end of the day you don't have enough time to go back to those, make a list. I have a list of things I want to read. Prioritize them. Things I want to understand. Yeah. I added a new thing to my list recently that was about, nobody really wants to know this, Greek and Latin prepositions and how they affect English etymologies.
Starting point is 00:40:38 Because I'm a huge nerd about language. Christopher's looking at me like I'm going to have to sleep on the couch tonight. What? Why? I don't know. Unless you're going to be staying up all night reciting Greek prepositions. No, I don't talk about these things very often. Do you speak Greek? No.
Starting point is 00:40:58 Oh, okay. Latin? No. But, I mean, English is some sort of weird conglomeration. Prepositions are really an important part of most languages. And it's like, I feel like I should know more of the Spanish prepositions because it's an area that, but they're all so short and they're hard to remember and on and up and above and below. And anyway, anyway. Well, I think we've ruined her question. Thank you, Silah.
Starting point is 00:41:31 Do we have time for one more? Yeah, plenty. How do you feel about live coding during interviews? I know, we're too old for this question. Yeah, it's hard for me to answer because I haven't done an actual... The last time I had contact with live coding with interviews was 20... I want to say 2019, 2018. That's not as long ago as I thought. We were interviewing folks for the Swift firmware... It's going to sound funny.
Starting point is 00:42:00 The Swift firmware team at Fitbit. We were firmware engineers who were moving to the mobile side and doing Swift development on the idea that having people who knew how the firmware worked writing mobile apps would be helpful. So we had a small team that we created. We learned Swift and Apple development, but we also were involved in hiring so they did live coding tests over zoom uh this was before the pandemic but didn't over zoom anyway with some i don't know thing where you could see them typey typey and i think we had to take them to we'd already you know we were internal to the company so it was a weird internal to the company but we didn't know anything about the jobs we were
Starting point is 00:42:51 taking like technically so it was a weird situation so we had to come up to speed so we had to take some exams the problem i have with live coding tests is they often... There's a very... It's very tempting for the person giving the exam to feel like it's time for gotchas or to demonstrate how smart they are. And so I saw that happen a lot with the Swift coding exam. There were a lot of, well, you did it this way and that does work,
Starting point is 00:43:31 but did you know about this very expressive way of doing it that Swift just added in the last six months and why aren't you using that or something like that? It's just, you know, I do see the value in live coding tests in that you do want to see that somebody can actually do something. But I think the bar should be pretty low. And I think the questions should be extremely straightforward. And the ones I've seen, the ones I've done, the ones I've been asked,
Starting point is 00:44:03 tend to not be straightforward. They are either, code up this computer science puzzle. Solve this computer science puzzle and do it in C or whatever. Show me how you do it. Or here's some completely abstruse code. what does it do? Or you have 10 minutes in Swift, I want you to do a thing that sorts the countries by flag by some complicated problem.
Starting point is 00:44:36 And I think a lot of people have trouble solving complicated problems while somebody's watching them on the fly in a few minutes. But that doesn't make them bad bad engineers and maybe they can solve that problem in 15 minutes if you go away maybe they can solve it in 25 minutes if you go away and allow them to do some research um so my my gut feeling is that you, you can give live coding tests. You should be very, very considerate about how you're addressing the problem. You should be very conscious of your own reasons for asking the question. And they should be a low bar. It should be like,
Starting point is 00:45:23 can they write a simple function that compiles? If there's a mistake, do they know how to fix it in the language we're dealing with? Because you don't want people to come in who can't do anything. But you should be able to establish a lot of their technical expertise through normal questioning as well. So that's where I'm at with it. I don't see a way around it, but I think it should be made much more compassionate. I have been thinking about domain information versus technical skills.
Starting point is 00:45:55 When I gave questions, they were always things that I hoped the person didn't have to acquire additional knowledge skills for. So like asking about string copy. It's a function that I think many people have used and asking them to implement it. I'm not asking for them to gain any additional knowledge. Fizzbuzz, which is a super popular question, not a bad question, but you have to figure out what the heck it is they want. What is the answer here? And it's not super complicated. I'm not going to say it's a bad question, but it is a question where you're asking them to learn a lot about what you want before trying to implement what you wanted to see.
Starting point is 00:46:49 And the more you have that in a question, and these are the ones that I think get really hard, you have to learn all about what they want. And then you have to internalize that well enough to implement something. So are you testing their ability to learn or to code? And both abilities are very important, but I really can't learn when somebody's watching me. You can't test somebody's ability to learn in five minutes. You just can't. It's cruel because that's not usually how people learn, especially under pressure. People really don't learn well under pressure unless they learn very well, in which case they're learning exactly what you're telling them. But that's a separate problem.
Starting point is 00:47:28 And I think you can learn a lot about somebody's ability to solve problems and learn by tailored questions about their experience. Unless it's a very junior person and they haven't done anything. But even then, they should have gone to school. I don't know, even the senior folks, sometimes they just
Starting point is 00:47:43 can't sit down at the keyboard and code. Right. What I'm saying is you can ask them questions like, what was a difficult debugging problem you recently solved? How did you go through it? That's much better to me than, hey, reverse a linked list and make me watch you do it. Because they'll be able to tell you how they thought through something. And some people are good at answering the coding questions, don't get me wrong. They can talk through what they're thinking and do all that stuff. I got okay at it. I was never very good at it, but I got okay at it because I realized what people were looking for. But I just think it's, we're humans, not computers. And so learning through human stories, you get a better sense
Starting point is 00:48:32 of somebody's skills than a five minute snapshot of what they do all day long. You know, pick your worst five minutes of coding. It invariably involves a typo. Actually, recently it involved slash R. How many times have you done that through the day, right, of eight hours of work? How many five-minute segments are there in 15, whatever, are there in an eight-hour day? There's a lot. And choose your worst because you'll be under pressure.
Starting point is 00:49:02 Yeah, so it's very difficult. I mean, the whole problem of hiring is very difficult, and I don't think there's proof that anything works, frankly. I think Google did a big study recently where they were like, well, interviews don't work. We have no idea. We have no idea what makes a good engineer or not, and we certainly can't figure it out from talking to someone for a couple hours.
Starting point is 00:49:23 So I think it's really tricky. And mostly you're looking for, honestly, mostly you're looking for a cultural kind of, does this person, is this person going to be a good person to work with? And the base level of, is what they said is on their resume resembling what they're talking about? But I don't think you could do much beyond that. And that's why I think contracting is great, because then you get six months to see if somebody actually could do what they say. And if they can't, then they're gone. Maybe that's, yeah.
Starting point is 00:49:54 But six months is a lot better than 15 minutes. Six months of paid work, as opposed to those 15-hour take-home tests. Those are, yeah, well, I don't think that's a good idea either. Yeah, take-home. You're not asking them about something they can do. You're asking them to learn something and then do something in that ball that they don't understand. I think here's something. I'm going to go out on a limb here and it's going to sound like tooting my own horn. But I don't care because I hate engineering. So I took the Fitbit take-home exam, the firmware take-home exam, after years of working for them. I did terribly at it.
Starting point is 00:50:51 I'm not even sure I got most of it right. It took me a long time, and I did a terrible, terrible job at it. I think everybody who has take-home tests, all of their engineers should have to take them. I was a principal engineer at Fitbit, constantly rated at the top, constantly getting good reviews. Producing lots of code. Producing tons of code. I was an exceptional engineer at that company,
Starting point is 00:51:14 and I failed the frickin' exam. Yeah. So either I was no good, and the bar is just very low, or the exam was no good. Or bar is just very low or the exam was no good or possibly i didn't care enough because i wasn't actually getting hired in there and maybe i would have focused more or something but oh no it was a fresh i remember when you took it it was super frustrating and it was one of those, if you knew the answer, it all kind of made sense. If you knew the answer in the domain, it was obvious.
Starting point is 00:51:48 And it wasn't well stated. The person, yes, the person taking the exam isn't in your head. They don't know what you know. This is not a test of, you're not giving final exams. You're not the professor. You're trying to make sure that You're not the professor. Yeah. You're trying to make sure that this person has the skills that is on their resume. Stop trying to make them.
Starting point is 00:52:12 Jump through hoops. Yeah. Make, make wolves eat goats and lettuce. Goats. We did get one. So that, that question came out of something that was that came up on the Patreon Slack.
Starting point is 00:52:28 And I like the response to part of that conversation in which one person said, I swear I want to personally slap anyone who makes candidates live code in an interview. I'll provide this service for free for you and everyone else in the Slack so if you want someone to come and slap your interviewer for you just join the Patreon Slack it's so funny that they have this I think you know I think part of it is we have the technology to do this stupid live coding stuff because back when I was hiring people a lot, we didn't have that. We had a whiteboard. Like that's any better. It was better because you couldn't ask them huge questions. You can't ask somebody to write a program.
Starting point is 00:53:16 You could ask them to write a function. So what you were saying, write string copy or something simple, that's doable on a whiteboard. And you didn't have a compiler there, so you didn't get tripped up on little syntax errors and stuff. It was mostly seeing, okay, did they kind of understand how code is written writ large? What about Conway's Game of Life?
Starting point is 00:53:37 I remember being asked that. That's actually not that easy. It isn't that it wasn't that easy. It's that I kind of remember how it works, but I don't really. And so I was spending a lot of time on the rules of the game instead of thinking about good programming practices. I think people need to think long and hard about what they're trying to learn from a question in an interview.
Starting point is 00:54:01 If you don't have a good answer for why you're asking a question, it's real specific, like what thing about this candidate are we trying to understand, then you shouldn't be asking the question. And you should be asking the same questions to everyone. Exactly.
Starting point is 00:54:16 In as fair a playing field as possible. And if you have multiple interviewers, you should coordinate so that you're asking different questions. Yeah. Anyway. Anyway, if anybody would like us to interview your candidates for you, it will cost you, but we might actually do it. Announcing a new service.
Starting point is 00:54:39 You're booked again? I think so. Nice and definitive. Well, I have some work to do and there is the promise of my main contract coming back online, but that has not yet happened. Wait a minute. The month swapped over. I thought, oh, well, we'll talk about it after. What do you want me to do? I don't know. And I am pretty booked. I think my main client is off doing the demos with the code I gave them, and I suspect they'll be back. And then I have another little client, and then I have the book, and I have the class, and really all I want to do is lay on the couch
Starting point is 00:55:23 when it's 85 and sit outside. Why is it 85? It's October. Why is it finally warm here? It's a very strange place we live. October's the best time to visit Santa Cruz. Very strange place. Welcome to summer.
Starting point is 00:55:36 It's October. We're in the Southern Hemisphere. Maybe that's it. We're in a bubble. It's a bubble universe that's actually in the Southern Hemisphere. I've never seen the Southern Cross. Yeah, you have. It's in pictures, books.
Starting point is 00:55:48 It doesn't count. It's just some stars. We've got a lot of stars. We've got stars at home. Which I haven't seen lately either. You haven't gone outside. That's not the problem. What? Oh, clouds?
Starting point is 00:56:04 Clouds, and we need to go someplace with dark skies. You can see stars without dark skies. Anyway. The problem is you don't like the stars we have. You want new stars. I want the Milky Way. That's a lot of gas, too. And dust.
Starting point is 00:56:21 Is there anything else you would like to talk about today? No. Okay. Then, thank you for co-hosting and for producing, for getting us such great sounds. Great sounds.
Starting point is 00:56:40 Now I feel like I have to insert a bunch of sounds. Thank you to Nordic for sponsoring this show. We really appreciate it. All the sounds. link on embedded.fm. You'll also find the transcripts there, the support us links, and various other things you might find interesting. We do still have a blog. It's very quiet. But it's full of stuff. But it is full of great stuff. And now, let's see. Winnie the Pooh. Nothing Pooh bear. Nothing at all. We can't all, and some of us don't. That's all there is to it. I know, I already read that part.
Starting point is 00:57:29 It's Eeyore, it's one of my favorite parts. Can't all what? said Pooh, rubbing his nose. Gaiety, song and dance, here we go round the mulberry bush. Oh, said Pooh. He thought for a long time and then said, What mulberry bush is that? Oh, said Pooh. He thought for a long time and then said, What mulberry bush is that? Bon honami, went on Eeyore gloomily.
Starting point is 00:57:56 French word meaning bon homie, he explained. I'm not complaining, but there it is. Pooh sat down on a large stone and tried to think this out It sounded like a riddle And he was never very much good at riddles Being a bear of very little brain So he sang Coddle Stone Pie instead Coddle Stone, Coddle Stone, Coddle Stone Pie A fly can't bird and a bird can't fly
Starting point is 00:58:19 Ask me a riddle and I reply Coddle Stone, Coddle Stone, Coddle Stone Pie That wasn't in poo voice. Do I have to redo it in poo voice? Coddle stone, coddle stone, coddle stone pie. A fly can't bird, but a bird can fly. Ask me a riddle and I reply, Coddle stone, coddle stone, coddle stone pie.

There aren't comments yet for this episode. Click on any sentence in the transcript to leave a comment.