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