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