Embedded - 413: Puppy-Like Glee

Episode Date: May 19, 2022

Chris and Elecia chat about practice, software quality, and empathy for seemingly unmotivated team members.  Elecia is teaching another cohort of Making Embedded Systems in the fall, starting late August. There will be reminders between now and then but if you want to sign up, here is the page. The funny and odd music instruction video with the copy-and-paste method of composition. Sign up for the newsletter! Support us on Patreon! Transcript

Hello and welcome to Embedded. I am Elysia White, here with Christopher White. It's just going to be us this week. We had some plans, but they fell through thanks to the pandemic. I mean, yeah. Good morning! How's that cappuccino treating you? It's decaf, which seems to have the same effect as caffeinated on me

because I have a quirky metabolism title. What are we talking about this week? I thought we would talk about lumber, paper-making techniques, dog pharmacology, and the difficulty of playing funk beats on the drums. Let's start with that last one, I guess. Okay. What? You have been working on practicing. That sounds very accusatory. You.

Sorry. You, my dear love, have been practicing at getting better and self-critique. I've been practicing and practicing. Yes. Yes. And I mimicked, I pretended to be you on Discord. Quite unsuccessful. It was Slack. Slack. Yes. And I mimicked, I pretended to be you on Discord. Quite unsuccessful. It was Slack.

Slack. Okay. Where we talked to our patrons. Slack. And I said, I set unrealistic goals for myself. And when it seems like I'm going to meet them, I change the goal to something much harder. True. Oh, and I watch myself play and think I look like a dork when actually I'm super cute and just concentrating.

False. I do look like a dork. Yes. So, I mean, the ongoing saga of music for me has been, I've played music for a long time. Everybody knows this on the podcast, and I will connect this back to software, I promise. But learning music is a weird thing because normally people go to a teacher, and I've gone to teachers, and they have a curriculum somewhat, depending on the instrument, it's kind of usually a standard set of things you do as you progress. It kind of fizzles out once you get advanced enough, and then you're starting to look around for things to learn and improve. And so I've been to teachers and things, And one of the advantages of teachers is they will tell you when you're doing things incorrectly, or at least from their standpoint, incorrectly.

And they will point out mistakes as you go in the lesson. And that's all well and good, but lessons are usually pretty short, 30 to 45 minutes. And so it's, you know, they're teaching you new stuff and you've got a few minutes to play what you've been working on for the week and have them yell at you and tell you you're doing it wrong. So even if you're doing lessons, it's hard to get good criticism. And I don't mean criticism in the sense of you suck and, you know, everything you're doing is wrong. I mean like, okay, here's how you can improve this. Here's this part that isn't feeling right even though you can't tell and things like that.

Sure, that's the role of a good teacher. Yeah. Telling you kind of the easy things you're doing wrong that can help you make strides. Yeah, yeah. And guiding you towards things that look non-obvious but lead to good things right after. Yeah. That's great. It's often not enough, but it's more than somebody who's either working on their own or self-taught gets.

And I've sort of moved into the working on my own phase of my musical experience. I've had teachers before, but I don't have one now. And teachers I've had before have been mixed quality on the feedback stuff. I mean, sometimes teachers are more interested in showing you new stuff than telling you you need to really spend time on this aspect of your playing or whatever. And I haven't had really great teachers who have been the latter type, who have been like, nope, you need to go home

and you need to do this for an hour a day and just this, and then you need to come back and see me. But you've been getting that from YouTube. No. And you signed up for a course too. No, what I get from YouTube is, here's some stuff to work on.

YouTube doesn't tell you what you're doing wrong. No, of course not. Yeah, the problem with YouTube is there's always more stuff and there's always people to work on. YouTube doesn't tell you what you're doing wrong. No, of course not. Yeah. The problem with YouTube is there's always more stuff and there's always people to compare yourself to. But compare yourself to in your mind. Like, oh, that person, you know, people, there's always people who are obviously better at you than something that you can find, right?

Yeah. And so it's not great to just be constantly looking through, oh, that person can do something I'll never be able to do, and that person can do something else I'll never be able to do. But what I've been trying to do is improve how I practice so that I'm actually making progress. Because I've been, to roll things back a little bit, I've been practicing seriously. I've played drums for a long time. And I was in a band for a long time, and that had a ton of rehearsal time, which took the place of practice.

And when you're in a band, there's plenty of people to glare at you and tell you when things are not feeling right or you're doing something wrong or you need to pare that back. And so that was very good. And so I got very good at playing in that band and that music.

Not very good at playing other types of music that I wanted to play. And so I've taken a break from that. We did the record and stuff. That was a different kind of feedback. But now I'm kind of like, okay, I really want to get much better at the drums. And so I've been trying to be habitual about practicing an hour plus a day, sometimes two hours a day, and really, really focusing for about six months, I'd say, something like that. Yeah. But for about four to five of those months, I really wasn't doing something very important. And that was to record and play back and listen to what I was doing.

And so about a month ago, I started doing that. And not just playback audio wise, because you had been recording audio. I'm recording video of me playing. Right. Which is, I mean, it just sounds like torture. It's extremely torture. I had been doing small snippets of audio stuff and playing it back, but video for at least drums is super important because there's a lot of technique stuff and there's a lot of movement stuff and you can't just hear that. So that's what I've been doing. And so I've been videoing all, basically all of my practice and playing back as much of it as I can, as soon as I can, and kind of looking at what I'm doing. And it's been extremely depressing because one of the things is that I've learned that I cannot tell sometimes when I'm making a mistake when I'm playing. I don't have that internal,

immediate thing in my head saying this feels wrong or that the placement of this note rhythmically is wrong. And so I can do stuff like just this week, I'm working on a song. I played along to the song kind of casually, but I felt like it went pretty good. And then I played it back yesterday and I was like, this is a complete mess. Rhythmic stuff all over, it's messy, stuff I didn't notice. And so it's things like that that I'm hoping will allow me to kind of level up and get better faster than if I was just ignoring those things and playing the same thing over and over and over again and hoping that just a little hint of, oh, you're making a mistake that I get in the moment would be enough to correct me over time. And I think it's going to work, but it's very hard because it's very hard to look at what you're

doing. First of all, it's very hard to see yourself on video and just minor stuff of like, oh, the camera angle makes me look like Richard Nixon, you know, it's driving me crazy. But beyond that, just seeing, oh, I look kind of goofy and that movement is super stiff or what's wrong with my face. So I have to get over some of that stuff to get to the music stuff because that stuff's not really important. It's important if like I'm going to put a video on YouTube. I don't want to look like a total goofball. But, yeah, so I think that's a key aspect of practice that a lot of people, like, you can practice a lot and make no progress. Sure, if you're practicing wrong or you're practicing the same thing over and over again. That's another thing is I'm trying to get better at is when I watch these videos and get mad at myself for stuff that's wrong,

well, it should be wrong. I'm practicing it. That's a good thing to realize. If it's right and it feels good, that's something I should probably drop from my practice ritual, right? Because that's not doing me any good. Yeah, it's like having a donut for breakfast or something. It feels good, but it's not going to help you. So, yeah. So I've been working a lot on that and thinking about that in a more general sense,

just outside of drums, like how do people get better at stuff when they're working on their own? And that applies to software as well, right? So like, how do you get better at anything? Because most of the time you're not getting a lot of feedback in the moment. Like, when you're writing software, you get feedback from the compiler, which is great, I guess. It's kind of like, you know, this doesn't work, or you've typed something wrong. But it doesn't tell you this code is inelegant or inefficient. And you get feedback from your peers, but that's probably the best stuff is when you have a code review happen. But if you're in a small team or you're working on your own hobby project, how do you get better? How do you self-critique writing software? I know it's not directly applicable between music and software because software is very analytical and music is not. But I think there's this application here of how do you get better at self-criticism in you are working. You can't just have 10,000 hours of nothing practice, of doing the same thing over and over again. That doesn't help you.

But one of the things they said that I wasn't as enthused about was that they said you had to be self-critical from the start. And that I strongly disagree with. At some point you have to start and then not be constantly self-critical or you can't get over the hurdle of learning it. Oh, that's interesting. And so you have been playing drums for years, decades. Really?

Don't think about it. And so you have the basics down. Some of them, but that's where I'm getting most mad at myself. But yes, go on. You have the basics down enough that you notice when you don't. Yeah. I have the capacity to self-criticize because I know what's wrong. Right.

Yeah. And to self-criticize about things you can and should fix. Yeah. And that's harder with something like software because like you mentioned earlier, like with drums, I can always listen to somebody record it or watch a video and say, oh, that's the right way to do that.

With software, it's like, okay, I wrote this LED thing. Is this the right way to do it? It works. I mentioned on Twitter that if you were having trouble on a HAL or example that you had code for, you know, working with a library, that the example they gave you didn't work or it didn't make sense in your context, you can just search in GitHub for that function name, and now you have 200,000 examples, some of which work.

Huh. And one of the things that we didn't see much in school learning how to do software, or even early in our careers, was the idea that you should be reading code. There was no code to read. Exactly. I mean, there were books with snippets. And there was the Linux kernel.

Well, some of it, it was barely out. So now there is a ton of code to read. You can watch other people program. You can watch other people's results of their programming. You can take, I mean, all of LeetCode, which is not, I'm not saying it's a good thing that LeetCode exists, but all of LeetCode you can do the example and then you can read 25 other ways to do it. What's LeetCode?

Oh, it's this place where they give you interview like questions okay and and i mean it's probably great for practice it is great for practice i don't i hope but it is it's a little painful when people tell me how many lead code things they've solved on easy or hard and i'm just like that's nice it's nice to have boxed problems what have you shipped um yeah i and i i sense that probably those things are being used in interviews like here's a leak okay anyway well yes so that's a good i mean doing but that comes back to don't practice the wrong things too much right um at point, you can stop reading driver code. At some point, you can stop playing with linked lists

because you understand them enough. Yeah, and I would say sometimes you can stop playing with stuff because you know where to find how to do it quickly enough. Exactly. You don't have to have it on instant recall, although sometimes you have to have it on instant recall for interviews, which is weird, but okay. And then there are some other things we do. You mentioned compiler warnings, compiler errors.

Yeah. We should be using linters. Yeah, yeah. And when you get started, using a linter is just, I mean, how can I deal with hundreds of errors? When you say linter, what are you referring to in 2022? Like when I hear that from like 15 years ago, I'm thinking, well, it's PC lint and that's it. No, I mean Clang. Okay.

That seems to be the default and it's a good one. And GCC is getting better too. Yes. And those are beyond compiler things, and they're rules that are written by people who are generally thinking about how things fail. Which is what you're trying to build in your mind is how do things work and how do things fail? And if you spend too much time practicing how things work, then you don't identify that you're headed down a bad, bad path. So you do need the failures too. Which, this is an aside, but this kind of reminds me of a video I watched this week.

A little bit about practice, and I'm not going to link to it because it's an insane video. You made me watch this. It's pretty hilarious. Well, it's a two-part, three-part video. The third part is not important. The first part was about a composition technique, which applies to code. And the video's notional idea of composition technique was you just write like 10 short phrases, less than like a bar length phrases. And then you cut and paste them all over a score, just all over. And then you play all that back. And then sometimes serendipitously there will be a section that doesn't sound like something insane. And so you pick those out and then start developing those as song ideas. serendipitously there will be a section that doesn't sound like something insane and and and

so uh you pick those out and then start developing those as song ideas but the second part was the video person i'll link to it it's by a guy named ben levin who's a very strange but interesting music youtuber the second part was answering a question. I get really nervous when I play in front of people or recording on stage. I can do stuff when I'm alone and it sounds good, but as soon as I try to do it under any pressure, I can't do it. And this advice is good for interviews too. Yes. And the advice he gave was, well, that's because your body changes when you're nervous and all sorts of things don't work the same way. Your muscles don't work the same way. Your respiration doesn't work the same way. Your brain doesn't work the

same way. And so he said, get your body into similar states before you practice a section or something that's giving you trouble. So go for a jog and then sit down at your instrument and immediately try to do the thing you can't do when people are in front of you because your physiology will be all lamped up and you'll be tired or what have you. Try to do it when you're hungry or haven't slept well. Just, you know, try to practice when you're not at your best because you're not going to be at your best when you're nervous. And that doesn't really apply to the immediate thing we were talking about with code code but i do think it's interesting that a lot of times we judge ourselves on what we can do when we're at tip-top condition mentally and physically

and a lot of the time we're not but it's so easy when you are self-critiquing to say well i could do better if i wasn't tired, and then you just let it slide, right? Right. Yeah. And I find that with work a lot of the time is there'll be a part of the day where I'm just really struggling to figure something out and I can't.

And I'm too tired or frustrated. And sometimes the difference with code is you can walk away. You can't walk away from a performance. You walk away and come back. It's not good. So, yeah, I've just been, you know, I've been thinking more about how to get better at things and how to be efficient at getting better at things,

but also how not to be too, not to let that turn into, I'm terrible at this and get discouraged. You're not doing all that well at that one. No, I'm not. It's very, very, very hard. It's very hard. And I've had to work very hard to, you know, force myself to note things that are going well. Like, oh, that section was great. This is good. But I don't generally do that. Those things just slide past.

Like, well, whatever. That was good, so I don't need to think about it. But if you just focus on the negative and give yourself negative notes, well. It's pretty easy to stop practicing because it's just so overwhelmingly bad that doesn't happen to me because i get very mad that's the reason i got i went to grad school um so but you know that's a that's a very idiosyncratic personal trait that i will get mad enough to keep doing something um even when it doesn't feel good. But yeah, I don't think I learned good habits from school about kind of being an autodidact or even homework.

It took me a long time to realize that homework was practice and you don't get better at schoolwork unless you keep doing the thing over and over. It doesn't have to be rote, but you have to do something enough times that you recognize patterns and you recognize shortcuts and you recognize what questions mean when they're phrased differently than you expect. And I think all of that stuff kind of is mixed together in this whole learning category of psychology. And it's all really weird. And I kind of wish people would teach that. It doesn't work because you can't teach a five-year-old psychology. But I wish there'd be more of that in school. Like, here's how people learn.

And this applies to you. And this is why the things we're doing as teachers are the way they are. They may seem weird to you. This may seem mean or boring or rote, but there's reasons behind some of these choices that have been made in how people teach music or teach science and technology. I think they are teaching five-year-old psychology now. There's been a big push to make sure to tell people that it's okay that they got a bad grade. That just means they're learning.

You're not a bad student. You just don't know this yet. This is hard, and I bet if you put enough effort into it and get some help, you can do it. Yeah, yeah. And I don't really remember hearing those things. You got your grade, and that was it. I got some of that. But I think it was based on expectations.

Like, if there was a student in my class who was consistently getting Cs, I don't know that they got that kind of feedback. But if there was a good student who got As all the time and then got a D on a test, I do think they got that kind of feedback. But I got the kind of feedback that I was a good student. Not that I had done well on an assignment.

Huh. Huh. Okay. And there's two different kinds of self-image there. Yeah. And one of them you can get better, and the other one you're fixed. Oh, you're maxed out. You're at the max levels this game supports,

so what more do you want? Or even if you're not at the max level, maybe you're a bad student. That's what I'm saying about the C student. Expectations. It's not a fixed identity. Your identity needs to be fluid. It needs to be about, I am not good or bad.

I am learning this. I'm just bad at offset metronome practice. Yes. That thing that you learned like a week ago and then got really good at it and then kind of didn't and then got good at it again. And now you're saying you're bad at it? Because you've only known it for like a week. Who, me?

Yeah, offset metronome practice. Oh, I'm not good at it. No. I never said I was good at it. But you got better pretty quickly. Sort of. Yeah, no, I mean, no, I agree. You're just so got better pretty quickly. Sort of, yeah. You're just so hard on yourself. No, no, no. But that's the thing.

It's hard to measure a lot of kinds of progress. I try to teach it in my Embedded Systems class. I don't know how successfully I am because I'm trying to teach a lot of things in that class. But I do give them rubrics for grading each other's and their own homework.

And I'm hoping that they notice that I try to make things fairly measurable, fairly good questions about what makes for good versus not good. And if they can put together their own rubrics for whatever they're doing, I mean, it's a meta step of how do I decide that this is done well? Yeah. And I've tried to do that for myself, but it's a double self problem. Like I have to make up my own rubric to grade myself on. So there's a lot of bias that creeps into that. And with code, there's this step of how do I show that this is good code? And then we go back to testing and unit tests and command line tests. Yeah, I think we have a question about that that we will get to in a minute.

Well, we're kind of going through it too. Well, I'd like to mention it explicitly. Anyway, yeah, I think I can wrap up my musing on practice. But it's been interesting. And I don't know if anybody else has experienced this as self-taught in anything. But it's definitely a skill. And unfortunately, how do you practice practice? You do it.

Yeah. But you have to do it right. To some extent. Like I could come down here and put my iPod on. Wow, dating myself. I could come down here and put whatever music app on and just play along for hours a day and never improve. You can improve at some things. Maybe.

It depends on where you are in your learning cycle. There is a point at which you do not improve further. Yeah, that's the thing. It's like when you're first learning an instrument, yeah, you can learn pretty fast doing that kind of thing. But at the stage I'm at, that doesn't do anything for me. So the question you were alluding to is from Bicycle Repairman. It would be interesting to hear our views on the things we do

and don't do to improve software quality, such as enable additional compiler warnings and fix them, apply linters, keep the cyclomatic or cognitive complexity low, ensure that your code is covered by unit tests. All these things that I think we all kind of agree are great and yet sometimes they do them I am going to be a bit of a contrarian on some of this okay warnings do we agree on that?

I agree on warnings but mainly because it's a cognitive load thing a lot of warnings aren't important they're just noisy. But you shouldn't have warnings because any warnings makes you ignore warnings that are important. That's the thing. You fix the warnings that you don't care about. So the warning that says, did you really mean to have X equal this instead of X equal equal in the if statement? So you can see that.

If you have 100 warnings, you're not going to see that one. Or some weird type thing that doesn't seem like it matters. Oh, this is being converted. Oh, that's fine. Until it isn't fine. Did you mean to put a star here or maybe an ampersand, something? Because these aren't the same types. I don't think code should have any warnings,

and you should strive for no warnings from the start just because you don't want to be... You don't want to have the alarm bell going off all the time, and then you miss the alarm. And that's something that's been discussed in a lot of uh books about like airline disasters and things and how to design warning user interfaces is the alarm is always going off the alarm is never going off um linters yeah that linters kind of fall into that same category i think take the easy wins on quality i think and the easy wins

are turn up the warnings and have have a robot tell you when you've possibly done something wrong and for the files you can't change the library files the bsp files you get that's okay mark those yeah as as don't have the warnings don't dointer. Yeah. Just don't let them hide your good warnings. Cyclomatic complexity and cognitive complexity. Now we're getting into loosey-goosey stuff. Yes, I know you can measure it. But now we're talking about more subjective stuff. And I agree keeping things simple is a good principle,

but no simpler. So that's a good principle to maintain, but it's also a principle that can be abused when people come into an existing project and start asking a lot of questions about, well, why are you doing it this way? Why are you doing it this way? I'm going to rewrite all of this because this doesn't look right to me. And I think that comes from not taking the time to understand things that are complex, that sometimes necessarily have to be complex. And once you've got an existing code base for a system, it is complex. And coming in immediately and saying whether it's too complex or incorrectly complex is not something you can do quickly. So that's my main concern with that is kind of the late comer, hi, your code base confuses me because I've looked at it for a day and I don't get it.

If you're translating algorithms from papers or you're working with a PhD person and implementing algorithms that they're talking about, why should I have code that anyone can walk up and understand? It's taken somebody a hundred hours to develop this algorithm. You're not going to look at it and understand it no matter how clear I write it. Yeah. And stuff like complex data flows. Sometimes stuff goes through a lot of stages before it comes in one end and goes out the other, whether it's coming in from a sensor that's reading at a high rate and then going out a network interface. There's a lot of steps in

between there, and it's complex. And yes, it should be made as simple as possible, but sometimes there's multiple cores involved. Sometimes there's asynchronous things involved. So I'm not excusing spaghetti code, but I do think we need to be a little more cognizant that sometimes things are complicated. And as I like to say, hard things are hard. And so this isn't excusing... Overly complex? Bad, poorly commented code. No, no, no.

This is just saying sometimes there are complex things that can't be made simpler. Or if they are made simpler, they don't make sense to the people who initially put them together. Like quaternions. Quaternions are not a thing that you can just, oh, you should reduce your cognitive load on that. Yeah, thanks for that. Or Fourier transforms or any sort of digital signal processing.

If you don't know what it is, then yeah, that looks pretty complex. Because it is complex and it's an area of expertise that you may not have. And I think the thing about code comments, code comments are important, but they're extremely tactical. They're extremely local to the code. It's as if you said by putting a post-it note on all the parts of an internal combustion engine, you would understand how an internal combustion engine works. That's a nice one.

I don't think that would work. The design port, the 10,000 foot, the 50,000 foot level description of how code works, I think needs to be outside of code for things beyond a certain level of simplicity. So that's when I have a little trouble kind of having a yes, that's all good, keep it low response because I don't know what keep it low means without context. The one I'm going to have the most people yell at me at is unit tests. What do you mean? Why would you not test your code? I think you should test your code.

So just to stipulate, test your code. I think unit tests have become a bit of a fig leaf, cargo cult. If we have unit tests, then our code must be good. And if we don't, it must be bad. From experience, and people are going to yell, well, you're just not doing it right. And of course, they say that about communism a lot. I've been in a number of places that have had unit tests. I've written extensive unit tests.

And they have caught things. It has been good for certain things. So I'm not against unit tests per se. I do think when your company writes 100 unit tests for a bunch of code that changes rarely and then stops and then you've just got this legacy base of unit tests doing nothing, that

that's not helping anyone. So I think unit tests need to be carefully considered because there is great effort in writing them. There is overlap with what unit tests do and great effort in writing them. There is overlap with what unit tests do and system tests in certain cases.

And a lot of times, the unit tests that get written are for the stuff that's easy to write unit tests for. Oh yeah. And if it's easy to write a unit test for, it's easier to write higher quality bug-free code. And you probably don't need a unit test to persist forever because that's not going to change very much. People aren't going to go in

there and change your bit-twiddling library that you wrote, right? Once it's done and tested... So I have many minds on unit tests, and I'm certainly not in the test-driven development camp. I think I was at one point. And I guess what I would say is I don't know how to deploy them most effectively at this point as a professional. And that may be a failing of mine, but I don't think just write unit tests for everything is the answer. Unit tests make it so that things can be safely refactored. Do you know how often I refactor my spy driver? Like, never.

Yeah. When I have another team, like I was talking about algorithms, that's an area where I put unit tests because what if I change something and it affects the higher level algorithm? Or what if the algorithms folks change something and it doesn't work the same way on my device? the unit tests for things that don't change i mean yeah you should have a test for your bit twiddling library does it need to run every time yeah you commit i don't know do you need a sweet 15 minute long unit test that's the thing is I hate it when it takes, I mean, right now I have a system that takes maybe 15 minutes to commit. And sitting there waiting for it to all happen, it usually is stopping me from doing something more useful. I know many times I go off, I don't care that it's happening.

But every once in a while, I need to watch it because I'm waiting for that to finish so I can do this. So I don't know about the whole having unit tests that always run. I do believe in testing. I believe in writing code to test. And I believe that if you change something and you should rewrite, I mean, you should look at your unit tests. But there are so many things. Like making a flash driver.

I'm not going to write a mock for the chip. Right. That seems like a terrible use of my time. I might do something higher level where at the very top level when I'm reading and writing to Spy Flash and I'm making like a KV store or some sort of database, I might

use a file as the back end. But that's going to take away all the timing problems. But I'm not going to find timing problems in unit tests unless they're egregious or unless I'm running on the hardware in a way. And when I'm running on the hardware in a way. And when I'm running on the hardware, I would rather have a command line test.

That's the problem with embedded too is, yes, there are a lot of ways to unit test embedded software. All of them are a compromise. Yeah. And that's, I mean, the people who believe more strongly in unit tests, okay, I'm not saying that's wrong i'm saying that's i don't do it for a reason not i don't do it because i'm lazy i think it's a it's a balance of how you do your entire device testing and where you put your efforts and if you're putting a lot of effort in unit tests you may not be putting efforts in integration testing or system testing or other places because there's limited time. If you don't have a dedicated testing group, dedicated testing group people aren't doing unit tests. If you don't have that,

you need to be doing system tests and things like that yourself. So if you're going to spend all your time doing mocks and things for low-level drivers that will get executed once or twice effectively while you're debugging code in ways that you could probably debug it a different way. Is that an effective use of your time? Or like you're saying, are higher-level tests more appropriate that exercise the entire system?

Perhaps not as code coverage completely, but there's other ways to find errors in code that are not unit tests, like proper usage of assertions and error handling for when things go wrong in ways that you don't expect. And that's another thing about unit tests that bugs me sometimes is there's less... Well, I'm doing unit tests so the code runs right,

so I can't elide a lot of this error handling or assertions. And I think that's a big mistake too. So sometimes the test needs to be built into the code for quality. Yeah, I mean, I don't think there is a recipe for these are the right things that you should be doing. And if you're not doing them, you're a bad developer. Having said that, the question goes on, why are so few developers so interested in these things? I have great interest in them.

Some of it's negative interest. But I think the question is valid. Why is there limited time to think about quality in many organizations because there's limited time yeah and money and money and i think so you can only hold so many things in your head and so one of the reasons practice is important is because then those things don't have to sit in your head. They become more automatic. But if I'm coming up to a new project and I need to learn the processor, my peripherals, the BSP for this processor compiler IDE combination, that's three things that are on my brain. And now I have this application that I'm trying to put together. I don't have enough bandwidth to also keep up with all of

the latest trends in software. And I know unit tests is no longer a latest trend in software. It's been around long enough that it is internalized to me. I do do it sometimes. But that's one of the reasons that I think embedded developers are slower to get onto the bandwagons here. And so many times, like the warnings and the linters have often felt insurmountable. Trying to get PC lint working was always a pain. And then there was always somebody in the organization who wanted to argue about which things you should have and which things you shouldn't. Now that we have Clang, I just do what it says. It isn't that these aren't valued. It's that sometimes it feels so overwhelming to try to put them in

that there's no place to start. And I can't fix the library code anyway. I'll just keep an eye on my files. That's fine when it's just you. And then when you have another developer, you explain. But eventually you should let the robot do it. The robot, your processor is bored. It wants to do things.

So let it do the linters. Ensure you're going to have to tell it which files not to use. So that's why I think a few, well, a few developers, that's why some developers aren't interested in some of these things. It's not necessarily because the managers don't value them. The managers, if they were asked, should we be doing these things that will increase the robustness of our system, the managers will probably say yes.

I mean, a lot of managers have been in our position before and are now managers, right? Yeah. I've gone back and forth. I know it's trite, but there's like the old fast, cheap, and good pick two. Yeah. Or pick one. That's what usually happens. But, you know, fast, cheap, and good, you can pick two.

And there's a triangular, you know, 2, cheap, and good, you can pick two, and there's a triangular, you know, 2D space which you can exist within those things, and they're all interlinked. The truth is that as a developer, you don't have control over fast or cheap. Those are decisions that management wants to make.

Here's the amount of money we have to spend. Here's when we need this product to go on the market. Those are what control those other things. And so good is a dependent axis of those other two things. So it's really tough. And a lot of times you just gotta, you gotta do the quality things that have the biggest bang for the buck that fits into the frame you have and the resources you have. And sometimes that means, depending on the product, like you also don't want to do, you know, NASA or FDA level quality things on a Tamagotchi, right? You're wasting your time. That's not important.

But you don't want Tamagotchi quality on an FDA product either. So, you know, it comes down to risk assessment. Risk assessment will kind of convey to you what level of quality you need to impart into the development process, and that will help you choose which things to focus on most. Next topic. Okay. As you probably have heard, I am teaching making embedded systems through ClassPert. The third cohort, the yellow seahorses, will be starting in August, late August.

I'm taking the summer off. I'm still so burnt out. I'm taking the summer off of coding. Yes, yes, yes. Of teaching, not coding. Oh, all right. I'm still working. So if you're interested in that, I'll put a link in the show notes.

I am mostly interested in companies. I think companies should be paying for this. It is the sort of course that will take you from a software engineer to an embedded software engineer or from a junior embedded software engineer into somebody who can do system design. One of the students recently asked about some sort of similar course, but for hardware instead of software. Oh, yes.

And I directed them towards contextual electronics, but they said that self-directed didn't work for them. They need deadlines. And having the cohort go through things together and be able to get help on this week's thing. I'm a self-learner. I mean, I don't need a cohort. If I want to learn something, I do it myself. I'm very self-motivated i think

and so it was kind of odd to hear that but also very gratifying i need that that's why it's been so hard to do going back to the earlier part of the show music for me is i have to i've had to learn to like set goals and have things that i'm working towards and check them and stuff. But that's real hard. So I get that. And also I want somebody to be mad at me. As you might have heard, being mad at myself is taking the place of that. But I do need somebody to say, you didn't practice this week.

I was mean to them last week because I told them they should have done their homework when most of them didn't. Yes. Usually I'm like, well, if you don't do your homework, you're not getting as much out of the class as you should be. But I was like, come on, this was easy. Why didn't you do it? Yeah. But if I was to take a hardware course, I'd be looking for something like that.

Because I've tried to do self-directed Udemy courses and stuff, and it's tough. It's real tough. The information is usually there, but it's like, how do I know when to move on? So I get stuck in a particular lesson or something. Yeah. So if I was to do a hardware course or any technical thing, I really would prefer to be doing it with a group personally. And they learn a lot from each other. So that part's fantastic.

Are there hard work courses like that? Not from ClassPert yet. I think they want to do one, but they haven't found. They're very focused on, we want an author to teach it. Oh, okay. Oh, and then the course that's starting in August will have a couple of scholarship seats, and we will be having some official way of giving those out. Okay.

I don't know where the form is, but August is a ways away. Yeah. Let's see, what was the other thing? Then we had another question from class from one of the students whose mind was blown that using Uint8 types in a 32-bit processor can be slower than using Uint32T types. Got to get them out of something. Native type is, yeah, unaligned accesses, right? Yeah. yeah unaligned accesses right yeah i mean the processor is dealing with 32-bit instructions 32-bit registers and so it really wants to do things 32 bits at a time and if you ask it to do something on an 8-bit word it has to go into the 32 bits and shift and mask just like you do.

So the question was, do you just declare everything to be Uint32 unless there's a specific need to work with single bytes? Or do you try to show in your code what things really need to be? I did answer this uncharacteristically because it was interesting. No, I always use the type that's appropriate for the thing. And I trust that the compiler and the processor will mostly do the right thing. And if I need more performance and that's the reason why, then sure. But that's never happened to me if that's if you need more performance and that's

the reason why you must have already optimized your system all the way yeah it's time to it's time to buy a new chip but i mean no it's a reason it's a very reasonable question uh and it you know understanding the micro architecture of chips does help you make coding decisions a lot of times um and this is one where yeah i'm sure there are definitely algorithms where it's like yeah it's much better to have and you do this with structures right you don't you don't have structures that are you When you're building a structure, you try to have things aligned in such a way, if you can, that the accesses aren't misaligned. So if you have a preference between putting one field

next to another field such that the accesses remain aligned, you should do that. So there are places where this is very important. But choosing a type, like if you have an 8-bit wide thing, and you decide to put it in a UN32, because that's faster, that's going to lead to bugs. Maybe. Well, your math things will overflow differently,

and things will work differently, maybe in ways you don't expect or forget about. Or the compiler will decide to do something implicit with a type promotion that you didn't want to do. Yeah, I would use the type that's appropriate for your contents. I'm thinking about memcopy and other forms of moving memory from one place to another. Maybe something more complicated like copy every other byte. Yeah. That sort of thing is going to be slower. Yes.

If you're trying to access every byte. Okay. See, this stupid field, there's always exceptions. There's always exceptions. There's always exceptions. There are definitely times where I have used a larger type for something. What's it called when you... Promote? No, it came up in TensorFlow of all things.

Oh, what's it called? Where you take bits and basically make them big things. What? No, no, it's fine. Somebody out there is shouting the right answer. It came up in TensorFlow and Python. It's a way to do computations easier by wasting a hell of a lot of RAM. But it came up in graphics.

Like we had on one of the Fitbits I worked on, we had a one-bit display. And that's really gross to work with. And by one bit, you don't mean one pixel. You mean black and white display. Black and white display. Every pixel was one bit. Yes. And the memory was, you know, every pixel had one bit, was one pixel.

So working with that is a pain. And so there were times where I was considering, let's promote all of these to bigger numbers than we know to do SheptonMaths, but there wasn't enough memory for that. But where I'm heading is there's a thing called bit banding on some of these chips that lets you do things like that, where it will, through magic,

allow you to access things at a finer bit granularity through larger accesses. So like they'd give you a 32-bit address that would correspond to one bit and stuff like that. I think that's how bit banding works. Yeah, and it's often used for registers. Yeah. So that instead of saying bit three in this register, you can just go to a different address.

Yeah. And you end up with that specific part of the register. And that's so you don't have to do a lot of these shifts and masks in your code. Right. So that can be nice. But there's always exceptions. But if you're reaching for that first because you read somewhere that it's faster, then don't probably do that.

I'll ding you on your code review. But yeah, it's always stuff like this, right? It's like, and the more you understand, I feel like sometimes the more you understand the way the chip works, the more you're confused about what the right thing to do is. Oh, yeah. Oh, yeah. Oh, yeah. Okay, I have one more question for us to talk about.

Okay. This was from Justin and led to some fairly hilarious commentary in Patreon, but I thought it might be fun to talk with you about it. Justin said, I just listened to episode 305 with Amanda Wozniak. It was awesome. Amazing guests. Some nice things he said about us. Oh, Amanda talked a lot about engineering being a team sport. I was wondering what you do when the other players don't want to play. They aren't motivated or care about the sport to begin with.

I always seem to end up in teams like this and it's so frustrating. Well, Justin, one thing was hilarious on the embedded Slack was that someone named Justin wondered if they had posted that question and then forgotten about it. That was one of the best things. Yeah. I mean, you've experienced this in school, because I remember you quit a project I was on because nobody was doing anything, not including me. I was doing stuff. You were doing stuff, but the professor didn't even care. So I just couldn't. It was one of these, that was an industry project, right? A clinic thing.

And so we were doing a project for a company. don't get paid the school gets paid it's all you know very strange but uh and there was a team of four i think so it was me you that was five it was five it was me you a friend of ours and two other people and the two other people, and the two other people did nothing. Nothing at all. And, yeah, it was you quit, and then me and our friend did all the work, which was fine. I learned a lot. I went off and did a thesis project that was great.

Yeah, and I did a thesis project in addition to that for reasons that I don't remember. Anyway, so, yeah, but that's school, right? And school is like, well, you take what school gives you. But I felt like this in industry for a long time. Yeah, that's right. And the thing is, maybe this doesn't apply to you, Justin, but the problem was me. If after a while all of the teams don't work that you're in, you have to wonder if maybe it's not them that's the problem. Sometimes.

No, okay, so let's talk about me because it was a problem. Yeah, let's talk about you. I remember having exactly this, why doesn't anyone want to do their work? Why aren't they motivated? Why don't they care? And there are people out there who don't care, but it's kind of surprising the percent of people who do care. And the reason they feel like they don't is because they don't have the same perspective that you do. It's not that they don't want to give you hardware. It's that they didn't know you needed it.

It's not that they don't want to explain how this works. It's that they don't know how it works yet. It's not that they didn't want to get things, get things in on time, it's that something went wrong. And they could tell you all these things, but then they wouldn't be working on the things they needed to do. Or they're being pulled in a different direction by a different boss on a different project. Or they've been doing this for 10 years, and they've been through three failed projects, or they already know that the company takes longer than it says it's going to on something every single time. So I'm not going to kill myself to get this done right now.

I mean, for me... It's a little more cynical, but yeah. I just remember thinking, are they maliciously trying to make this not work or are they just totally incompetent? And now I still know some of those engineers and I can tell you they were not incompetent and they were not malicious. They just had different goals. And one of them taught me how to get things done. You take people to lunch. The price of taking someone out to lunch versus the frustration of them not finishing something is, I mean, it's not on the same scale. Lunch is cheap. And you ask them, this is what I'm trying to do.

Is there something stopping you? Am I doing it wrong? Am I asking for it wrong? Or you just take them out to lunch and ask them how it's going. And you don't treat them like a cog. You treat them like a person who has family problems and car problems and three bosses and five products they're supporting and you listen to them and you know you do this enough times you they do start to pay attention to what you need it's not i don't want it's not you're not trying to manipulate them through food you're trying to make sure that you understand that you are providing what they need as much as you want them to provide what you need. How do you do that in 2022 with

distributed workforces? Oh, crap if I know. Yeah. I do think that's important. I do think there are people who are lazy. Oh, yeah. And don't get stuff done. I saw something about people having two full-time jobs now that you didn't have to go into the office. No, three. Wasn't it? There was a website about how to do that. It was just like, how to have two jobs. It was like, no, that's not a good idea.

Ethics, find them. But the original question is teams when people, I mean, there are genuinely times I have been on teams where there's a bunch of people just not pulling their weight and they're goofing off and you can tell they're goofing off. And I don't know how to deal with that. One of the times that happened to me, I was the person's boss. And truthfully, I was at the stage of not caring that much about the company either. So I didn't't really i had other people on the team who were producing so it was like all right you know not to my credit i just let a lot of it slide but i don't know what to do about that uh besides complaining to people's managers and stuff and you got to be real careful and like you said no no that's really a performance issue

but try to find out if it is an issue. Yeah, right. Yeah, that's what I'm saying. Try to find out if it's just that their expectations are different than yours. Or doing different stuff. I think there have been many times when I was considered an underperformer and it was because I was in a bad team with bad goals being set and being pulled in two directions.

Because in one case Because I was, in one case, I was on two teams unofficially. And one team had high expectations that I was doing X. And one team had high expectations I was doing Y. And X and Y did not overlap. And there was only time to do one of them. And so you're doing half of each. And it looked like you were doing a bad job on both. And I never made progress on either. Yeah. And I left. Because of that and it looked like you were doing a bad job on both and i never made progress on either yeah and i left because of that it was like this is this is unsustainable but it's really really hard especially if you're not if your manager is not good at dealing with that stuff or if you're in a company where that's kind of accepted and it's just a low, I don't want to say low ambition, but a low productivity company, which there are some where that's just the norm. Especially bigger ones that have very large teams. That sort of stuff starts to get diluted to the point where things get done even though people aren't doing that much on average so you asked about 2022 taking

out to lunch yeah um maybe ask them for help say say you're not asking a lot of technical stuff that you just want to have that if if you were together you would ask them to go out to lunch just to find out about their job. You can still have a coffee break with them. Yeah. And ask for that. But stop. I wish I could tell myself to stop assuming other people know what's going on in your head. That was the hardest thing. Yeah.

I said I would need this part in two weeks. Two weeks have passed. Why don't I have this part? Well, the other person didn't believe me. Or you mentioned it once. I mentioned it once. I never brought it up again. I just expected everyone to do what I would do. And that's not a great expectation. And, you know, I still come back to the cynical part. Being young and ambitious and enthusiastic is something that doesn't always last forever. And so, the new people on teams who are fresh-faced and rested and full of recent education and things they want to do and puppy like glee

and ideas for how to do things and ideas for how what you've been doing is wrong i'm not saying this is justin but poor justin no no i'm not this is another the flip side of the coin right is yeah sometimes you want to do more things than are actually possible. And if you did all those things, it might actually be bad. So I'm not saying that's the case with this, but I've seen that instance too, where it's like, okay, you've all been sitting on your butts for two years and i'm here now and i think we should flip the table over and rewrite this because i saw x y and z on you know whatever twice now a company that i contracted for hired someone and that i disagreed with, old client.

And this has happened before where somebody in their interview to a manager says, well, I've taken a look and I'm just going to rewrite it all. Or that project was broken and I came in and I just rewrote it all. And that sounds good, but what I actually hear is I didn't bother to understand the system well enough. And so I just went in and made a whole bunch of different bugs. I wrote a system I did understand, which accomplishes the same thing. And has a bunch of different bugs. It's the, and has a bunch of different bugs is the part that I hear every time someone says that. And what managers should hear is you spent $2 million on this. I would like you to do it again. Not, not I'm here to save you from all of these trials and tribulations that your code base has caused you. Yeah. Software is hard. It is. Because it's people. It's not just code.

It's people. And for whatever reason, much like with music, for me, self-worth is tied up with how well you feel, how good a developer you feel you are. And there's a competitive aspect, which is so weird. So weird to me. It's weird to me in music. Competitive music makes no sense to me, and yet it's an impulse that I find myself having, and I see other people have. And it's weird in software too, because you know, the incentives, there are at least incentives with software, you know, the company, I need to perform well enough to

get a promotion get more money whatever and so to some extent there's a little bit of a competitive aspect there but there shouldn't be a i'm better than this person so i need to demonstrate that i'm better than this person by doing something that makes them look worse or it's the dopamine hit of being right yeah and that glorious correctness and that... It's the dopamine hit of being right. Yeah. And that's... Glorious correctness. And that's where the, I'm going to rewrite this comes in because I have to prove that

what I'm going to do is better than what these people did, even though these people are all the people on my team who wrote this code before. And who had reasons for how they wrote the code. That's a destructive and not a very good instinct. So yeah, some humility and time is useful there. As far as just the general problem of you're on an underperforming team, if you're really on an underperforming team, you have few choices unless you're in charge of the team.

Well, you have a great opportunity. To be the person who takes over and rewrites everything. To figure out how to get the most done that you can do while allowing them to do whatever they need to do. Not take over their projects, just make sure yours is as done and clean and beautiful as possible. And if it's unsustainable and unpleasant, then... But you do that enough times and somebody's going to notice that you're doing a good job and ask you what you want to be doing. And you can say, I want to be team lead and I want to fire all these people, which will

lead you not to be team lead. Just so you know. Depends on the company. Depends on the company. Yeah. There were so many things. You know, I read the book, Thanks for the Feedback, recently, and that was the book that I wish I had read when I was going through this, was that I didn't know how to ask the right questions. And that book had so many good scripts about asking the right questions. And sometimes their lack of motivation had to do with feedback that I wasn't hearing. So yeah, Justin, no great answer for you. But if you build a time machine, please let me send some books back to previous me.

I would say try to figure out the truth of your situation and then make a decision on what you can do about it. Yeah, because there are things you can do, but you cannot fix them. Yeah, you definitely can't fix them. As the amount of yelling that I remember from a computer science clinic did not accomplish much. Not you. Okay. I remember being mad at those guys a lot. What are you doing? Nothing?

That's clear. This is a very long podcast. I think we should wrap it up. All right. Well, then let's wrap it up. Thank you for chatting with me, Christopher, and for producing. Thank you to our listeners for listening. Thank you to our Patreons for supporting the show.

We really do appreciate it. It lets us do things that we might not otherwise, like transcripts and finding new listeners. And it gives us opportunities to think about hard problems that I normally wouldn't spend a lot of time thinking about. And thank you for subscribing to our newsletter, if you do.

And if you have any questions or want to find the newsletter, look at Embedded.fm H-T-T-P-S colon slash slash embedded.fm. Spell out the whole thing. Now how about some Winnie the Pooh? Okie dokie. When we left them, Christopher Robin had seen a half lump,

and nobody else knew what that was, but they pretended. Then they all talked about something else, until it was time for Pooh and Piglet to go home together. At first, they stumped along the path which edged the hundred-acre wood. They didn't say much to each other, but when they came to the stream and had helped each other cross the stepping stones and were able to walk side by side again over the heather, they began to talk in a friendly way about this and that.

And Piglet said, I see what you mean, Pooh. And Pooh said, it's just what I think myself, Piglet. And Piglet said, but on the other hand, Pooh, we must remember. And Pooh said, quite true, Piglet, although I had forgotten it for a moment. And then just as they came to the six pine trees, Pooh looked around to see that nobody else was listening and said in a very solemn voice, Piglet, I have decided something. What have you decided, Pooh? I have decided to catch a half-a-lump.