413: Puppy-Like Glee
Transcript from 413: Puppy-Like Glee with Elecia White and Christopher White.
EW (00:00:06):
Hello, and welcome to Embedded. I am Elecia 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.
CW (00:00:20):
I mean, yeah. Good morning.
EW (00:00:24):
How's that cappuccino treating you?
CW (00:00:26):
It's decaf, which seems to have the same effect as caffeinated on me, because I have a quirky metabolism. Title.
EW (00:00:34):
What are we talking about this week?
CW (00:00:36):
I thought we would talk about lumber, papermaking techniques, dog pharmacology, and the difficulty of playing funk beats on the drums.
EW (00:00:54):
Let's start with that last one, I guess.
CW (00:00:58):
Okay. What?
EW (00:01:02):
You have been working on practicing.
CW (00:01:05):
That sounded very accusatory. "You."
EW (00:01:08):
Sorry. You, my dear love, have been practicing at getting better and self-critique.
CW (00:01:18):
I've been practicing at practicing.
EW (00:01:20):
Yes.
CW (00:01:20):
Yes.
EW (00:01:21):
And ... I pretended to be you on Discord.
CW (00:01:26):
Quite unsuccessfully. It was Slack.
EW (00:01:28):
Slack, okay, where we talk to our patrons.
CW (00:01:31):
Yeah.
EW (00:01:32):
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."
CW (00:01:40):
True.
EW (00:01:40):
Oh, and, "I watch myself play and think I look like a dork when actually I'm super cute and just concentrating."
CW (00:01:46):
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 who I've talked to 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.
CW (00:02:09):
And I've gone to teachers, and they have a curriculum. 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.
CW (00:02:25):
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.
CW (00:02:43):
And so 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're doing it wrong. So even if you're doing lessons, it's hard to get good criticism.
CW (00:02:59):
And I don't mean criticism in the sense of you suck and 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.
EW (00:03:14):
Sure. That's the role of a good teacher, -
CW (00:03:18):
Yeah.
EW (00:03:18):
- telling you kind of the easy things you're doing wrong that can make help you make strides, -
CW (00:03:24):
Yeah. Yeah.
EW (00:03:25):
-and guiding you towards things that look non-obvious, but lead to good things right after.
CW (00:03:30):
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.
CW (00:03:48):
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.
CW (00:04:02):
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."
EW (00:04:14):
But you've been getting that from YouTube.
CW (00:04:15):
No.
EW (00:04:17):
And you've signed up for course too.
CW (00:04:18):
No, what I get from YouTube is, "Here's some stuff to work on." YouTube doesn't tell you what you're doing wrong.
EW (00:04:23):
No, of course not.
CW (00:04:24):
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. ... There's always people who are obviously better than you at something that you can find, right?
EW (00:04:39):
Yes.
CW (00:04:40):
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.
CW (00:04:56):
Because 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.
CW (00:05:08):
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.
CW (00:05:27):
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."
CW (00:05:37):
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.
EW (00:05:49):
Yeah.
CW (00:05:50):
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.
EW (00:06:06):
And not just play back audio-wise.
CW (00:06:09):
Right.
EW (00:06:09):
Because you had been recording audio.
CW (00:06:11):
I'm recording video of me playing.
EW (00:06:12):
Right. I mean, that just sounds like torture.
CW (00:06:15):
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.
CW (00:06:35):
And so I've been videoing 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.
CW (00:06:56):
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.
CW (00:07:18):
And then I played it back yesterday, and I was like, "This is a complete mess," rhythmic stuff all over, messy, stuff I didn't notice.
CW (00:07:26):
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 the little hint of, "Oh, you're making a mistake," that I get in the moment would be enough to correct me over time.
CW (00:07:43):
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," is driving me crazy.
CW (00:08:01):
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 I'm going to put a video on YouTube. I don't want to look like a total goofball.
CW (00:08:22):
But yeah, so I think that's a key aspect of practice. ... You can practice a lot and make no progress.
EW (00:08:31):
Sure, if you're practicing wrong, or you're practicing the same thing over and over again.
CW (00:08:34):
That's another thing 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.
EW (00:08:48):
That's a good thing to realize.
CW (00:08:50):
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.
CW (00:09:06):
So I've been working a lot on that and thinking about that in a more general sense, just outside of drums, "How do people get better at stuff when they're working on their own?" And that applies to software as well, right? So how do you get better at anything?
CW (00:09:23):
Because most of the time you're not getting a lot of feedback in the moment. When you're writing software, you get feedback from the compiler, which is great, I guess. That's kind of like, "This doesn't work," or "You've typed something wrong."
CW (00:09:38):
But it's doesn't tell you, "This code is inelegant," or inefficient. And you get feedback from your peers, and that's probably the best stuff is, when you'd have a code review happen. But if you're in a small team, or you're working on your own Mojave project, how do you get better? How do you self-critique writing software?
CW (00:09:57):
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 there's application here of, "How do you get better at self-criticism in general to learn things better?"
EW (00:10:12):
I read a book about the 10,000 hours of practice. And one of the things it said was about being self-critical as 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.
EW (00:10:34):
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.
CW (00:10:53):
Oh, that's interesting.
EW (00:10:55):
And so you have been playing drums for years, decades, and -
CW (00:10:59):
Really?
EW (00:11:01):
Don't think about it. And so you have the basics down.
CW (00:11:09):
Some of them, but that's where I'm getting most mad at myself. But yes, go on.
EW (00:11:14):
You have the basics down enough that you notice when you don't.
CW (00:11:17):
Yeah. I have the capacity to self-criticize, because I know what's wrong.
EW (00:11:22):
Right.
CW (00:11:23):
Yeah.
EW (00:11:23):
And to self-criticize about things you can and should fix.
CW (00:11:28):
Yeah. And that's harder with something like software. Because like you mentioned earlier, 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."
EW (00:11:47):
I mentioned on Twitter that if you were having trouble on a HAL or example that you had code for, working with a library, that the example they gave you didn't work, or 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.
EW (00:12:13):
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.
CW (00:12:25):
There was no code to read.
EW (00:12:27):
Exactly.
CW (00:12:28):
I mean, there were books with snippets.
EW (00:12:31):
And there was the Linux kernel.
CW (00:12:33):
Well, some of it. It was barely out.
EW (00:12:38):
So now there is a ton of code to read. You can watch other people program.
CW (00:12:43):
Yeah.
EW (00:12:44):
You can watch other people's results of their programming. I mean, all of LeetCode, which, 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.
CW (00:13:01):
What's LeetCode?
EW (00:13:03):
Oh, it's this place where they give you interview-like questions.
CW (00:13:08):
Oh, okay.
EW (00:13:09):
And I mean, it's -
CW (00:13:10):
It's probably great for practice.
EW (00:13:12):
It is great for practice.
CW (00:13:13):
I hope they're not -
EW (00:13:14):
But it's a little painful when people tell me how many LeetCode things they've solved on easy or hard. And I'm just like, "That's nice. It's nice to have boxed problems."
CW (00:13:25):
What have you shipped? Yeah. I sense that probably those things are being used in interviews, like, "Here's a LeetCode," okay. Anyway, well, yes. ... But that comes back to, "Don't practice the wrong things too much."
EW (00:13:42):
Right. At some point you can stop reading driver code. At some point you can stop playing with linked lists, because you understand them enough.
CW (00:13:53):
Yeah. And I would say sometimes you can stop playing with stuff because you know where to find how to do it quickly enough.
EW (00:13:58):
That. Exactly.
CW (00:13:58):
And 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.
EW (00:14:08):
And then there are some other things we do. You mentioned compiler warnings, compiler errors.
CW (00:14:15):
Yeah.
EW (00:14:17):
Well, we should be using linters.
CW (00:14:18):
Yeah. Yeah.
EW (00:14:20):
And when you get started, using a linter is just, I mean, "How can I deal with hundreds of errors?"
CW (00:14:28):
When you say linter, what are you referring to in 2022? When I hear that from 15 years ago, I'm thinking, well, there's PC-lint, and that's it.
EW (00:14:38):
No, I mean, Clang.
CW (00:14:39):
Okay.
EW (00:14:40):
That seems to be the default. And it's a good one.
CW (00:14:43):
And GCC is getting better too.
EW (00:14:45):
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 you're trying to build in your mind is, "How do things work, and how do things fail?"
EW (00:15:03):
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.
CW (00:15:16):
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.
EW (00:15:27):
He made me watch this. It was pretty hilarious.
CW (00:15:29):
Well, it's a 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 ten short phrases, less-than-a-bar-length phrases.
CW (00:15:52):
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.
CW (00:16:10):
But the second part was the video person, and I'll link to it. It's by a guy named Ben Levin who's a very strange but interesting music YouTuber.
CW (00:16:21):
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.
EW (00:16:33):
And this advice is good for interviews too.
CW (00:16:36):
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."
CW (00:16:48):
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."
CW (00:17:03):
"Because your physiology will be all amped up, and you'll be tired, or what have you. Try to do it when you're hungry or haven't slept well. Just try to practice when you're not at your best, because you're not going to be at your best when you're nervous."
CW (00:17:18):
And that doesn't really apply to the immediate thing we were talking about with code. But I do think it's interesting that a lot of times we judge ourselves on what we can do when we are at tip-top condition mentally and physically, and a lot of the time we're not.
EW (00:17:36):
But it's so easy when you are self-critiquing to say, "Well, I could do better if I wasn't tired."
CW (00:17:44):
Yeah. And then you just let it slide, right?
EW (00:17:45):
Right.
CW (00:17:46):
Yeah. And I find that with work, a lot of the time, there'll be a section, 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.
EW (00:18:11):
You could.
CW (00:18:12):
It's not good. So yeah, 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 let that turn into, I'm terrible at this and get discouraged.
EW (00:18:35):
You're not doing all that well at that one.
CW (00:18:36):
No, I'm not. It's very, very, very hard. It's very hard. And I've had to work very hard to 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.
CW (00:18:51):
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 -
EW (00:19:01):
It's pretty easy to stop practicing, because it's just so overwhelmingly bad feeling.
CW (00:19:06):
Well, that doesn't happen to me, because I get very mad. That's the reason I went to grad school. But that's a very idiosyncratic personal trait that I will get mad enough to keep doing something, 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.
CW (00:19:35):
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, and over.
CW (00:19:45):
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.
CW (00:20:00):
And I think all 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.
CW (00:20:21):
Like, "Here's how people learn. And this applies to you. And this is why the things we are 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."
EW (00:20:42):
I think they are teaching five-year-olds 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.
CW (00:20:58):
Yeah.
EW (00:20:58):
You're not a bad student.
CW (00:21:00):
Yeah.
EW (00:21:00):
You just don't know this yet.
CW (00:21:02):
Yeah.
EW (00:21:03):
This is hard. And I bet if you put enough effort into it and get some help, you can do it.
CW (00:21:10):
Yeah. Yeah.
EW (00:21:11):
And I don't really remember hearing those things.
CW (00:21:14):
I got some of that.
EW (00:21:15):
You got your grade, -
CW (00:21:15):
I got some of that.
EW (00:21:15):
- and that was it.
CW (00:21:18):
But I think it was based on expectations. If there was a student in my class who was consistently getting C's, I don't know that they got that kind of feedback. But if there was a good student who got A's all the time and then got a D on a test, I do think they got that kind of feedback.
EW (00:21:37):
But I got the kind of feedback that I was a good student, -
CW (00:21:42):
Yeah.
EW (00:21:42):
- not that I had done well on an assignment.
CW (00:21:45):
Okay.
EW (00:21:48):
And that's two different kinds of self-image there.
CW (00:21:52):
Yeah.
EW (00:21:53):
And one of them you can get better. And the other one, you're fixed.
CW (00:21:57):
Well, you're maxed out. You're at the max level this game supports, so what more do you want?
EW (00:22:02):
Or even if you're not at the max level, maybe you're a bad student. That's not a -
CW (00:22:06):
That's what I'm saying about the C student, expectations. Yeah.
EW (00:22:09):
It's not a fixed identity.
CW (00:22:10):
Yeah.
EW (00:22:11):
Your identity needs to be fluid. It needs to be about, "I am not good or bad. I am learning this."
CW (00:22:18):
I'm just bad at offset metronome practice. Yes.
EW (00:22:23):
That thing that you learned a week ago, and then got really good at it, and then kind of didn't, and then got good at again. And now you're saying you're bad at it? Because you've only known it for a week.
CW (00:22:35):
Who, me?
EW (00:22:36):
Yeah. Offset metronome practice.
CW (00:22:38):
Oh, I'm not good at it.
EW (00:22:39):
No.
CW (00:22:40):
I never said I was good at it.
EW (00:22:41):
But you got better pretty quickly.
CW (00:22:44):
Sort of. Yeah. No. I mean, no, I agree.
EW (00:22:46):
You're just so hard on yourself.
CW (00:22:47):
No, no, no. But that's the thing is, it's hard to measure. It's hard to measure a lot of kinds of progress.
EW (00:22:55):
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.
EW (00:23:11):
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 metastep of, "How do I decide that this is done well?"
CW (00:23:32):
Yeah. And I've tried to do that for myself, but it's a double self problem. I have to make up my own rubric to grade myself on. So there's a lot of bias that creeps into that.
EW (00:23:43):
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.
CW (00:23:52):
Yeah, I think we have a question about that that we will get to in a minute.
EW (00:23:55):
Well, we're kind of going through it too. Alright.
CW (00:23:58):
Well, I'd like to mention it explicitly, but anyway. Yeah, 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?
EW (00:24:19):
You do it.
CW (00:24:20):
Yeah. But you have to do it right.
EW (00:24:23):
To some extent.
CW (00:24:24):
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.
EW (00:24:35):
You'd improve at some things.
CW (00:24:38):
Maybe.
EW (00:24:39):
It depends on where you are in your learning cycle.
CW (00:24:42):
There is a point at which you do not improve further. Yeah. That's the thing. 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.
EW (00:24:55):
So the question you were alluding to is from Bicycle Repairman.
EW (00:24:58):
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.
EW (00:25:28):
And yet, sometimes I do them.
CW (00:25:31):
I am going to be a bit of a contrarian on some of this.
EW (00:25:34):
Okay. Warnings. Do we agree on that?
CW (00:25:36):
I agree on warnings, but mainly because it's a cognitive load thing. A lot of warnings aren't important, and they're just noisy. But you shouldn't have warnings, because any warnings makes you ignore warnings that are important.
EW (00:25:51):
That's the thing. You fix the warnings that you don't care about so that the warning that says, "Did you really mean to have X equal this instead of X equal equal in the if statement," you can see that. If you have a hundred warnings, you're not going to see that one.
CW (00:26:04):
Or some weird type thing that doesn't seem like it matters. "Oh, this is being converted. That's fine." Until it isn't.
EW (00:26:10):
"Did you mean to put a star here, or maybe an ampersand? Something? Because these aren't the same types."
CW (00:26:14):
So 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 have the alarm bell going off all the time, and then you miss the alarm.
CW (00:26:25):
And that's something that's been discussed in a lot of books about airline disasters, and things, and how to design warning user interfaces is, if the alarm's always going off, the alarm is never going off. Linters, yeah, linters kind of fall into that same category, I think.
CW (00:26:42):
Take the easy wins on quality, I think, and the easy wins are turn up the warnings and have a robot tell you when you've possibly done something wrong.
EW (00:26:51):
And for the files you can't change, the library files, the BSP files you get, that's okay. Mark those -
CW (00:26:58):
Yeah.
EW (00:26:58):
- as, "Don't have the warnings. Don't do the linter."
CW (00:27:03):
Yeah.
EW (00:27:03):
Just don't let them hide your good warnings.
CW (00:27:08):
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.
CW (00:27:33):
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, "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."
CW (00:27:51):
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.
CW (00:28:06):
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 latecomer, "Hi, your code base confuses me, because I've looked at it for a day, and I don't get it."
EW (00:28:26):
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?
EW (00:28:45):
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.
CW (00:28:54):
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.
CW (00:29:13):
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.
EW (00:29:36):
And so this isn't excusing -
CW (00:29:38):
Overly complex, no -
EW (00:29:39):
Bad, -
CW (00:29:40):
No.
EW (00:29:40):
- poorly commented code.
CW (00:29:42):
No, no, no.
EW (00:29:43):
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.
CW (00:30:08):
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.
CW (00:30:23):
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.
EW (00:30:38):
That's a nice one.
CW (00:30:40):
I don't think that would work. The design port that 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.
CW (00:30:58):
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.
EW (00:31:15):
What do you mean? Why would you not test your code?
CW (00:31:21):
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 I think -
EW (00:31:42):
And if we don't, it must be bad.
CW (00:31:44):
- 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.
CW (00:32:02):
I do think when your company writes a hundred 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.
CW (00:32:18):
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 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.
EW (00:32:38):
Oh yeah.
CW (00:32:38):
And if it's easy to write a unit test for, it's easier to write the 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? ...
CW (00:32:58):
So I'm of many minds on unit tests, and I'm certainly not in the test-driven development camp. And I think I was at one point.
CW (00:33:08):
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.
EW (00:33:26):
Unit tests make it so that things can be safely refactored. Do you know how often I refactor my SPI driver? Never.
CW (00:33:37):
Yeah.
EW (00:33:39):
When I have another team, 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?
EW (00:34:01):
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 -
CW (00:34:15):
Yeah.
EW (00:34:15):
- you commit? I don't know, because -
CW (00:34:20):
Do you need a suite of 15-minute-long unit tests?
EW (00:34:23):
That's the thing ... 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.
EW (00:34:40):
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.
CW (00:34:49):
Yeah.
EW (00:34:50):
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, ... I mean, you should look at your unit test, but there are so many things. Like making a flash driver, I'm not going to write a mock for the chip.
CW (00:35:17):
Right.
EW (00:35:18):
That seems like a terrible use of my time.
CW (00:35:22):
Yeah.
EW (00:35:22):
I might do something higher level, where at the very top level, when I'm reading and writing to SPI flash, and I'm making 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.
EW (00:35:37):
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, I would rather have a command line test.
CW (00:35:48):
Yeah. And 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.
EW (00:35:57):
Yeah. And I mean the people who believe more strongly in unit tests, okay. I'm not saying that's wrong. I'm saying I don't do it for a reason.
CW (00:36:09):
Yeah.
EW (00:36:09):
Not I don't do it because I'm lazy.
CW (00:36:11):
I think 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.
CW (00:36:28):
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.
CW (00:36:38):
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?
CW (00:37:05):
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 so that's another thing about unit tests that bugs me sometimes. ...
CW (00:37:23):
"Well, I'm doing unit tests so the code runs right so I can elide a lot of this error handling or assertions." And I think that's a big mistake too. So sometimes the tests need to be built into the code for quality.
CW (00:37:40):
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?
CW (00:37:55):
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?
EW (00:38:09):
Because there's limited time.
CW (00:38:10):
Yeah. And money.
EW (00:38:12):
And money. And 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 -
CW (00:38:27):
Automatic.
EW (00:38:28):
- automatic.
CW (00:38:28):
Yeah.
EW (00:38:30):
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.
EW (00:38:50):
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.
EW (00:39:19):
And so many times 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.
EW (00:39:40):
Now that we have Clang, I just, 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.
EW (00:40:05):
And then when you have another developer, you explain. But eventually you should let the robot do it. Your processor is bored. It wants to do things. So let it do the linters. And sure, you're going to have to tell it which files not to use. So that's why I think ... some developers aren't interested in some of these things.
EW (00:40:32):
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. We should do this."
CW (00:40:43):
I mean, a lot of managers have been in our position before and are now managers, right?
EW (00:40:49):
Yeah.
CW (00:40:50):
I've gone back and forth. I know it's trite, but there's the old, "Fast, cheap, and good. Pick two."
EW (00:40:58):
Yeah.
CW (00:40:59):
Or pick one, is what usually happens. But fast, cheap, and good. You can pick two, and there's a triangular, 2D space, which 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.
CW (00:41:19):
"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.
CW (00:41:34):
And a lot of times you've got to do the quality things that have the biggest bang for the buck that fits into the timeframe you have and the resources you have, ... depending on the product. You also don't want to do NASA or FDA-level quality things on a Tamagotchi.
EW (00:41:59):
Right.
CW (00:41:59):
Right? You're wasting your time. That's not important. But you don't want Tamagotchi quality on an FDA product either. So it comes down to risk assessment.
CW (00:42:14):
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.
EW (00:42:28):
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 burned out. I'm taking the summer off of coding, or -
CW (00:42:54):
Yes. Yes!
EW (00:42:57):
- off of teaching.
CW (00:42:58):
Oh.
EW (00:42:58):
Not coding.
CW (00:42:59):
Oh, alright.
EW (00:43:00):
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.
EW (00:43:16):
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.
CW (00:43:33):
Yes.
EW (00:43:34):
And I directed to 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.
EW (00:43:51):
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.
CW (00:44:13):
I need that. That's why it's been so hard to do. Going back to the early part of the show, music for me, I've had to learn to set goals, and have things that I'm working towards, and check them, and stuff. But that's real hard. So. I get that.
CW (00:44:29):
And also I want somebody to be mad at me. As you might have heard, being mad at myself has taken the place of that. But I do need somebody to say, "You didn't practice this week."
EW (00:44:40):
I was mean to them last week, because I told them they should have done their homework when most of them didn't.
CW (00:44:45):
Oh, no. Oh, no.
EW (00:44:45):
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?"
CW (00:44:56):
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.
EW (00:45:16):
Yeah.
CW (00:45:17):
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.
EW (00:45:25):
And they learn a lot from each other. So that part's fantastic.
CW (00:45:28):
Are there hardware courses like that?
EW (00:45:31):
Not from Classpert yet.
CW (00:45:32):
Okay.
EW (00:45:32):
I think they want to do one, but they're very focused on, "We want an author to teach it."
CW (00:45:39):
Oh, okay.
EW (00:45:40):
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.
CW (00:45:51):
Okay.
EW (00:45:52):
I don't know where the form is, but August is a ways away.
CW (00:45:57):
Yeah.
EW (00:45:58):
Let's see. What was the other thing? Oh, and then we had another question from class, from one of the students whose mind was blown that using uint8_t types in a 32-bit processor can be slower than using uint32_t types.
CW (00:46:15):
Got to get them out of something. Native type is, yeah. Unaligned accesses, right?
EW (00:46:23):
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 -
CW (00:46:42):
And grab it out.
EW (00:46:43):
- and shift, -
CW (00:46:43):
Yeah.
EW (00:46:43):
- and mask just like you do. So the question was, "Do you just declare everything to be uint_32 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?
CW (00:47:00):
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
EW (00:47:25):
If you need more performance, and that's the reason why, you must have already optimized your system all the way.
CW (00:47:33):
Yeah. It's time to buy a new chip. But I mean, no, it's a very reasonable question. And understanding the microarchitecture of chips does help you make coding decisions a lot of times.
CW (00:47:51):
And this is one where, yeah, I'm sure there are definitely algorithms where, yeah, it's much better to have, and you do this with structures, right? ... When you're building a structure, you try to have things aligned in such a way, if you can, that the accesses aren't aren't misaligned.
CW (00:48:12):
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, if you have an 8-bit wide thing, and you decide to put it in uint_32, because that's faster, that's going lead to bugs.
EW (00:48:34):
Maybe.
CW (00:48:35):
Well, your math things will overflow differently.
EW (00:48:39):
Yeah.
CW (00:48:40):
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.
EW (00:49:00):
I'm thinking about memcpy and other forms of moving memory from one place to another, maybe something more complicated, like copy every other byte.
CW (00:49:09):
Yeah.
EW (00:49:10):
That sort of thing is going to be slower -
CW (00:49:17):
Yes, okay.
EW (00:49:18):
- if you're trying to access every byte.
CW (00:49:19):
So, okay.
EW (00:49:21):
See, this stupid field. There's always exceptions.
CW (00:49:24):
There's always exceptions. There are definitely times where I have used a larger type for something. What's it called when you -
EW (00:49:34):
Promote?
CW (00:49:35):
No, it came up in TensorFlow of all things. Oh, what's it called, where you take bits and basically make them big things?
EW (00:49:46):
Fonts?
CW (00:49:46):
No, no, it's fine.
EW (00:49:51):
Somebody out there shouting the right answer.
CW (00:49:52):
It came out TensorFlow and Python. It's a way to do computations easier by wasting a hell of a lot of RAM. But this came up in graphics. We had one of the Fitbits I worked on, and we had a 1-bit display. And that's really gross to work with.
EW (00:50:10):
And by 1-bit, you don't mean one pixel. You mean black-and-white display.
CW (00:50:14):
Black-and-white display. Every pixel was 1-bit.
EW (00:50:16):
Yes.
CW (00:50:16):
And the memory, every pixel had 1- bit, was one pixel. So working with that is a pain.
EW (00:50:23):
Yes.
CW (00:50:23):
And so there were times where I was considering, "Let's promote all of these to bigger numbers, and then we don't have to do shift and mask, but there wasn't enough memory for that.
CW (00:50:30):
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.
CW (00:50:50):
So they'd give you a 32-bit address that would correspond to 1-bit and stuff like that. I think that's how bit-banding works.
EW (00:50:59):
Yeah. And it's often used for registers.
CW (00:51:01):
Yeah.
EW (00:51:01):
So that instead of saying bit 3 in this register, you can just go to a different address.
CW (00:51:07):
Yeah.
EW (00:51:08):
And you end up with that specific part of the register.
CW (00:51:12):
And that's so you don't have to do a lot of these shifts and masks in your code.
EW (00:51:15):
Right.
CW (00:51:15):
So that can be nice, but there 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?
CW (00:51:32):
And 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.
EW (00:51:40):
Oh, yeah. Oh, yeah. Okay. I have one more question for us to talk about.
CW (00:51:49):
Okay.
EW (00:51:50):
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." Da, da, da, some nice things he said about us.
EW (00:52:09):
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."
EW (00:52:26):
Well, Justin, one thing that 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.
CW (00:52:43):
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.
EW (00:52:54):
You were doing stuff, but the professor didn't even care.
CW (00:52:57):
Yeah.
EW (00:52:57):
So I just couldn't.
CW (00:52:59):
That was an industry project, right, a clinic thing?
EW (00:53:03):
Yeah.
CW (00:53:03):
And so we were doing a project for a company. We don't get paid. The school gets paid. It's all very strange. And there was a team of four, I think.
EW (00:53:14):
Four.
CW (00:53:14):
So it was me, you, no, it was five. It was five. It was me, you, a friend of ours, and two other people. And the two other people did nothing, nothing at all. And yeah, you quit. And then me and our friend did all the work, which was fine. I learned a lot.
EW (00:53:35):
I went off and did a thesis project. That was great.
CW (00:53:38):
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. When you're in a -
EW (00:53:50):
But I felt like this in industry for a long time.
CW (00:53:52):
Yeah. That's where -
EW (00:53:53):
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.
CW (00:54:12):
Sometimes.
EW (00:54:14):
No. Okay. So let's talk about me, because it was a problem.
CW (00:54:17):
Yeah. Let's talk about you.
EW (00:54:19):
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.
EW (00:54:47):
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 in on time. It's that something went wrong.
EW (00:55:09):
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.
CW (00:55:20):
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 kill myself to get this done right now."
EW (00:55:36):
I mean, for me, -
CW (00:55:37):
It's a little more cynical, but yeah.
EW (00:55:39):
- 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.
EW (00:55:59):
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 just not on the same scale. Lunch is cheap.
EW (00:56:20):
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.
EW (00:56:33):
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 do this enough times, they do start to pay attention to what you need.
EW (00:56:56):
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.
CW (00:57:09):
How do you do that in 2022 with distributed workforces and people -
EW (00:57:13):
Oh, crap if I know.
CW (00:57:14):
Yeah. I do think that's important. I do think there are people who are lazy -
EW (00:57:20):
Oh, yeah.
CW (00:57:21):
- and don't get stuff done.
EW (00:57:22):
I saw something about people having two full-time jobs now that you didn't have to go into the office?
CW (00:57:27):
No, three. There was a website about how to do that.
EW (00:57:29):
I don't know. It was just -
CW (00:57:30):
It was like, "How to have two jobs."
EW (00:57:31):
No, that's not a good idea. Ethics. Find them.
CW (00:57:37):
But the original question is, teams when people... I mean, there are genuinely times I've 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.
CW (00:57:57):
And truthfully, I was at the stage of not caring that much about the company either. So I had other people on the team who were producing. So it was like, "Alright." Not to my credit, I just let a lot of it slide.
CW (00:58:11):
But I don't know what to do about that besides complaining to people's managers and stuff, and you've got to be real careful. And like you said, know that it's really a performance issue.
EW (00:58:24):
But try to find out if it is an issue.
CW (00:58:26):
Yeah. Right. Yeah. That's what I'm saying.
EW (00:58:28):
Try to find out if it's just that their expectations are different than yours.
CW (00:58:32):
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, bad goals being set and being pulled in two directions. Because in one case, I was on two teams unofficially.
CW (00:58:49):
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.
EW (00:58:59):
And so you were doing half of each, and it looked like you were doing a bad job on both.
CW (00:59:03):
And I never made progress on either. Yeah. And I left because of that. It was like, "This is unsustainable."
CW (00:59:09):
But it's really, really hard, especially 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.
CW (00:59:35):
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.
EW (00:59:46):
So you asked about 2022 taking out to lunch.
CW (00:59:48):
Yeah.
EW (00:59:50):
Maybe ask them for help. Say you're not asking a lot of technical stuff, that 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 someone.
CW (01:00:07):
Yeah.
EW (01:00:08):
And ask for that. But I wish I could tell myself to stop assuming other people know what's going on in your head. That was the hardest thing.
CW (01:00:23):
Yeah.
EW (01:00:23):
"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.
CW (01:00:34):
Or you mentioned it once.
EW (01:00:35):
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.
CW (01:00:46):
And 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, -
EW (01:01:05):
And puppy-like glee.
CW (01:01:07):
- and ideas for how to do things, and ideas for how what you've been doing is wrong, and I'm not saying this is Justin, but -
EW (01:01:13):
Poor Justin.
CW (01:01:15):
No, no. I'm not. 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.
CW (01:01:33):
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," whatever.
EW (01:01:54):
Twice now a company that I contracted for hired someone 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."
EW (01:02:22):
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."
CW (01:02:35):
"I wrote a system I did understand which accomplishes the same thing."
EW (01:02:39):
And has a bunch of different bugs.
CW (01:02:40):
Sure. Yeah.
EW (01:02:41):
It's the, "And has a bunch of different bugs," is the part that I hear every time someone says that.
CW (01:02:46):
And what manager should hear is, "You spent $2 million on this. I would like you to do it again."
EW (01:02:52):
Yes. Yes.
CW (01:02:53):
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.
EW (01:03:03):
It is.
CW (01:03:03):
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 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.
CW (01:03:29):
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 there are at least incentives with software. At the company, I need to perform well enough to get a promotion, get more money, whatever.
CW (01:03:49):
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 - "
EW (01:04:03):
It's the dopamine hit of being right.
CW (01:04:06):
Yeah. And that -
EW (01:04:06):
Glorious correctness.
CW (01:04:08):
And that's where the, "I'm going to rewrite this," comes in, because, "I have to prove that what I'm going 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 that's a -
EW (01:04:19):
And who had reasons for how they wrote the code.
CW (01:04:21):
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.
EW (01:04:38):
Well, you have a great opportunity
CW (01:04:40):
To be the person who takes over and rewrites, everything? I mean, -
EW (01:04:44):
To figure out -
CW (01:04:45):
Yeah.
EW (01:04:46):
- how to get the most done -
CW (01:04:47):
Yeah.
EW (01:04:48):
- 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.
CW (01:05:01):
Yeah. And if it's unsustainable and unpleasant then -
EW (01:05:06):
But you do that enough times, and somebody's going to notice that you're doing a good job -
CW (01:05:09):
Yep.
EW (01:05:10):
- 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.
CW (01:05:19):
Depends on the company.
EW (01:05:20):
Depends on the company. Yeah. There were so many things. 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, "Are they malicious or incompetent," problem. It wasn't that I was getting feedback. It was that I didn't know how to ask the right questions.
EW (01:05:44):
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.
CW (01:06:08):
I would say, try to figure out the truth of your situation, and then make a decision on what you can do about it.
EW (01:06:16):
Yeah. Because there are things you can do, but you cannot fix them.
CW (01:06:22):
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.
EW (01:06:34):
Oh, okay.
CW (01:06:35):
I remember being mad at those guys a lot. "What are you doing?" "Nothing." "That's clear." This is a very long podcast, and I think we should wrap it up.
EW (01:06:47):
Alright. 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.
CW (01:07:09):
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.
EW (01:07:19):
And if you have any questions or want to find the newsletter, look at embedded.fm, https://embedded.fm.
CW (01:07:28):
I thought you were going to spell out the whole thing.
EW (01:07:31):
Yeah. Now how about some Winnie the Pooh?
CW (01:07:33):
Okey-dokey.
EW (01:07:35):
[Winnie the Pooh excerpt].