Embedded - 24: I'm a Total Fraud

Episode Date: October 23, 2013

Listener Jim Gf posed an interesting question about how to tell if you are a good embedded software engineer. Producer Christopher White joins Elecia to fail to give an answer. While they mention the embedded C test, they devolve into "why would you ask that question?", impostor syndrome, and methods for dealing with it.  (Normally our podcasts are recorded during the day but this one was after a long, fairly grueling day for the co-hosts. You may hear the clink of glass as we drank a nice Pinot Noir from Hahn Winery.)

Welcome to Making Embedded Systems, the show for people who love gadgets. This is Elysia White. Today I'm happy to have Christopher White, my producer, on this side of the microphone, speaking with me about how to tell if you're a good software engineer. Hi, Christopher. Thank you for coming back. Yep. So we got mail from a listener via the contact link on Embedded.fm.

I'm guessing the electronic variety. Well, of course. And we do get mail a bit, but he had a question and I thought it was interesting. So I wondered if you had some answers. The email is from Jim GF, and he starts with compliments on the show, for which I thank him very much. He continues saying he started work as an electrical engineer and transitioned to embedded. And now quoting, However, I do not think I'm an expert at C programming, nor embedded systems. Though I'd like to always get better, I feel I'm in the middle, competent where I can do the work and figure things out that I don't know. So I'm wondering, how can I find out if I'm good at, say, C or embedded systems?

Are there standard tests or exercises one can do to see where one stands? I know there's BrainBench, but I haven't paid for any exams yet. I've heard some people put a lot of weight on those and others not so much. If I knew where I stood, I could focus on getting better at the parts I'm not so good at. For example, in my embedded work, I've never used malloc and free, so I don't know much about them. To to summarize do you know any way to see how good one is at c programming and various embedded systems concepts thanks hopefully i'm not the only one who wonders about this and i think he's not what do you think well yeah there's a lot of people who wonder about their own competency in various in the various areas that they work in. Um, I think his question is more

specific than the kind of general worries that most people have about, you know, am I faking my way through this or am I really doing, you know, am I, am I really capable of doing the things that I'm being asked? Um, well, the specifics, there is an embedded C test that's pretty popular. I've never seen it. It's from RBM Consulting. There'll be a link on the show notes. And it's the 010X10

best questions for would-be embedded programmers. And the format is more if you're conducting an interview, how do you look for questions, which is kind of what I do in my book as well, although his are very C-specific and mine are more general interview questions. And it's things like, what are the uses of the keyword static, which we've covered on the show. And embedded systems always requires the user to manipulate bits in a register of variables given given an integer write code fragments the first should set bit three of a and the second should clear bit three of a in both cases the remaining bits should be unmodified and then uh the blog

or the post goes on and says well well, how would you do this? Good explanation of the answers and what the common pitfalls are. It's more about what to look for as an interviewer, not really a test to determine if you're any good at writing. Yeah, it's difficult. I think it's a difficult thing to evaluate for a couple of reasons. One is there's lots of language idiosyncrasies and things that even experienced programmers don't remember.

The trinary operation. The question mark with the colon. I used to work at a company and we used it all the time and then I knew how to use it. But now, if and then else is fine for me. I use it all the time.

But it's an idiom. It's an idiom, exactly. And there are other idioms like that. And some of them are more specific to embedded systems than others, like the volatile keyword, which sometimes isn't even respected by your compiler. So that's one part of it is, can you really evaluate somebody based on whether they know an esoteric concept?

A language. It's kind of how do you divide up competence between rote knowledge, stuff that you could look up if you needed to. Like, oh, you know, I've got to do needed to like oh you know i gotta do x bit twiddling operation that i do once every eight months you know what's the point of having that on infinite instant recall all the time when you could just search and stack overflow would have an answer for you well i mean that's kind of flip but yeah and and so there's that kind of stuff and then there's just knowing how to be an engineer, which is there's plenty of good engineers, I think,

and this is my opinion and my experience. It's all our opinion. Who aren't language experts. And to my second point, he sounds like he's a generalist, he or she. He, Jim. He sounds like he's a generalist. He's got an electrical engineering background, right? Mm-hmm.

And he does some programming and probably works on a team with multiple people. He's more of a multidisciplinary person. And, you know, he can be an excellent generalist, which is the kind of person that embedded projects often need because they can tie all the pieces together. Because I can talk to an electrical engineer, I can talk to a software engineer, I can talk to a program manager.

A pure software project doesn't have all those pieces. It's got software pieces to integrate and you have to be a software engineer and know that. It's a little easier to be a cog that can be replaced by someone else or you can move on to a different area and that's fine. But there's with the interdisciplinary teams, I can't do anything mechanical. So how do you evaluate if somebody is a good generalist? I mean, I think that's a very difficult problem and not one that's suited to tests. I think you have to look at somebody's history. I mean, you know, from an interview standpoint,

I mean, this basically boils down to, I know he's asking for himself, how do I know if I'm good? But the process would be almost the same to determine if somebody you're hiring is good, right? I don't know. I mean, I know it's hard to do that process for yourself, and that makes it impossible,

but the kinds of questions you're trying to answer, what's your history been like? What projects have you worked on? Were they successful? Did you ship it? That's always something I ask in interviews when people are a little, well, I did this and that.

I'm like, yes, but did you finish it? What hard challenges did you face during this project and how did you solve them? That's a lot more important to me than, well, you know, how do you reverse the bits in a bite? I get that question a lot in interviews. You know how to reverse the bits in a bite quickly. How do you reverse a linked list without using a prev pointer or something?

Those are details. This industry has been around for 50 or 60 years. Like any other discipline, stuff gets piled on top of stuff. I think it's really hard. An example. Physics education. If you look at physics education over the last several hundred years, you know.

Oh, this is where I physics. And some of it's revolutionary stuff. And particularly the early part of the 20th century where things just, you know, general relativity and quantum mechanics and all of these things were developed. And if you're a physics student, you have to learn everything that's come before before you can learn what's the current, right? And you have to admit that what is current is unlikely to be correct in 10 years. So some of that earlier stuff needs to be compressed. And even though it's important, you need to go through it quicker and it needs to be boiled down to its essentials. So you can actually, you know, not spend your entire life getting to the point where you can say, ah, now I can work on physics. I think a lot of that's true with computers as well.

There's so much now to have to understand to be able to contribute to a real embedded or software project. Operating systems, design patterns, the languages, and usually people have more than two or three. And everything's connected now so you need to understand internet protocols and web and sometimes you need to know a scripting language here or there so and how it all talks to hardware and what resistors you need for a button versus an led i have no idea well that's the thing you can't always know it all. But you can know where to find all of that.

Yes. And you can know what all that stuff means without knowing the specifics. I can understand how orbital mechanics works and the implications of the two-body problem versus the three-body problem or all those kinds of things without necessarily being able to pull out all the equations on instant recall. But you've done the equations. It's more than having heard of these things. That's true. I've forgotten them.

But relearning something is much easier than learning it the first time. It's the difference between remembering something and remembering remembering something. But where you were going, I was on board for, that to some extent you need to know what you know. And you need to learn lots of things and be able to return to where it is you saw it. Not necessarily the same link or whatever. But I don't know that much about how to put together an inheritance model in C++ to do a GUI.

But I know that doing GUIs often involves inheritance models, and so C++ is more attractive than C. And if I remember that, then the next time I'm faced with putting together a GUI, I can start thinking, well, you know, there's more to this than just slap a picture on a screen. How can I architect a system? It's not just get down and code. But I'm aware of if you asked me to program in PHP in order to do some server thing,

I would just be like, yeah, let me go find you someone else because that's not my area and I could learn it but it would not be fair for a company to pay me to learn it because it is so far outside my range. Having a company pay me to learn a little bit more about how to do internationalization,

that makes sense because it's incremental based on, I need to know a little bit about internationalization and a lot about embedded systems in order to apply that problem together. But something so outside my range, it wouldn't be worth it. To get back to the listener's question. Oh, are we going to do that?

I can't remember what it was anymore, so I'm just going to answer something different. Yeah, we should have recorded this podcast when we weren't tired. You should have recorded it backwards. You could just, you know, you're the producer. You could just put it backwards. Sorry. Okay. How do you measure your goodness as an embedded

systems engineer so i think i touched on this but it's a little hard to say from his situation because i don't know you know what kind of company he's at what kind of projects he's worked on how why is he asking how good am i i mean if this was me 20 years ago i would be asking how good am I? I mean, if this was me 20 years ago, I would be wondering how good am I because I haven't had a job yet and I've been learning out of books and gosh, do I know C? Do I really know C? Do I really know C++?

So let's assume that he's in a company and has been doing stuff. I would say there's two ways to evaluate what other people think of you. Do people want to work with you again? Do people want to work with you again? Do people want to work with you again? I think that's a big one. Have you been successful on projects?

Is the code you've written, if you've written code, and it's not clear to me that he's done a lot of code. Oh, I think he had, yeah. I mean, he was an electrical engineer, and now he's an embedded systems engineer. So is your code working? Is it readable? Well, there was Joel Spolsky, and he had smart and gets things done it's not enough to be a smart engineer you also have to get things

done got it you know i've worked with a lot of smart engineers and don't get things done well it yeah exactly you have to they're always explaining how smart they are. But you have to be able to let a project go and not insist on perfection and yet be detail-oriented enough that you aren't releasing crap. So getting things done is... Are you the person who all the bugs get assigned to because you wrote them all?

Yes, that's a good metric. Are you the one who people are asking a lot of questions about your code, not because it's cool, but because it's incomprehensible? Well, but you may not be able to tell the difference because it's comprehensible to you. I guess if you were the person...

If somebody's asking how your code works on a regular basis, and they're a peer, then I think you're probably doing something wrong. Or your peers are idiots. Well, that's, you know, that's a 50-50 thing, right? There are two choices. The likelihood that all of your peers are idiots is fairly low. But being not good at documenting is not necessarily the same as being bad at coding.

Documenting is one thing, but writing readable code is something separate. You know, I heard this person suggested that code should be written as stories, and they should be interesting to read, and you should really think about what you're writing. And if your code is easier to rewrite than it is to read then you're writing crappy code it should be harder to write and easier to read because that's what we need that's what we need in code going forward unless it's pearl unless it's pearl in which case to hell with that you can't even read it after you've written oh no well or or pick assembly i have to say all of my pick assembly is just not worth.

Mine's perfectly readable. You're zero lines. Yes. It's very, very efficient too. It is more efficient when there's less code. Okay, so we've got a couple of things here. I was also thinking about teaching. When I teach something, I mean, when I wrote my book about teaching when I teach something

I mean when I wrote my book about embed systems I learned a lot because I learned where my gaps were and it goes back to knowing what you're good at blogs are a form of teaching even if it's just talking to yourself talking to your stuffed animal yeah

and it helps you organize what you know, but then teaching other people is more fun, kids and adults both. Yeah, but sometimes it's hard to get an opportunity to do that unless somebody comes in that you're supposed to mentor. No, I would go outside work. Well, yeah, I do tend to go outside more work, but Arduino boards are fun to get people addicted and and the questions they ask will lead you to a deeper grasp of what you already know

and possibly make you scramble to keep ahead and that's that's good that's expanding what you're thinking about um i think that's important. I think also, you know, from a philosophical standpoint, maybe you shouldn't be asking how good you are. You should be asking yourself the reason that you're wondering how good you are. Is it because you feel insecure? Is it because you want to be competitive with a bunch of other people? Is it for the possibly legitimate reason that you want to move up in the world and do something, you know, more challenging? But I think for all of those cases, the answer is not to ask yourself how good you are. It's to continue improving and...

To continue learning. No matter how good you think you are or how good you really are which you may never know it you know stop asking that question and go sit down and do a project and you know come up with a problem to solve and solve it get a dev kit light a light yeah it's interesting even how different processors handle that trivial example of an embedded system. What is the basic code to get that started? And one LED leads to another and then you have light up shoes, which that's cool. It doesn't really matter what you do as long as you're learning and growing and trying to figure out how to expose yourself to new stuff. And I think that can be hard at some companies.

That's why I'm saying maybe you're asking this question because you're doing small maintenance work at a company with a mature product and you never really do anything new. You're not really challenged. You don't know how good you are. No, I don't think it comes up there. I think it's more about these teams.. You don't know how good you are. No, I don't think it comes up there. I think it's more about these teams and I don't know about Jim's situation. But there's so much hero complex and negativity in engineering

where people are like rock stars and ninjas and all of that. Does anybody really talk that way except outside the recruitment area yeah well i mean we work with people who do actually you haven't been looking at their titles on their chats no you should it's kind of interesting because some of the ninjas are not the people i want to work with um but you know there there's a lot there, there's a lot of negativity. There's a lot of, uh, snark, uh, you know, actually, uh, Nate, a friend recently said, uh, that our Twitter feeds, both of us have a lot of snark and we tend to pretend to be

frustrated. Uh, and it, but there's a negative human aspect to it that we are, I don't tend to tell people they're not good. I would rather encourage than discourage, but a lot of engineers want to show they can do it. And sometimes it just ends up being, I'm great and you're not. And that's not the direction I want to go. I, but I, But I see other people doing that too, as though we only tell each other about our success stories. We only tell each other about how we just blazed through this project and got through it and finished.

And it's like we're training ourselves to give up easily. Tell me more about this world where everything is positive. All I ever do is talk about how badly things are going. All my stories about companies are, well, at this place they did this idiotic thing and it didn't work, or this place, you know, we tried this and it was a massive failure. I think that's important, though. I agree.

To talk about the failures, because it's talking about the perseverance and the getting through the technical and political and social difficulties. There's definitely projects I've worked on that could be considered successes. Say that. Considered successes. Five or six times. Projects considered successes. But I only look at them as, oh, my God, you know, that actually worked.

What a surprise. You know, you know, that actually worked. What a surprise. You know, we got through that 18 challenges. We managed to make this impossible thing work. And we learned a lot. You know, in my mind, it's not through any genius. It's through either perseverance or a happy accident. And maybe there was some genius, but I'm not going to acknowledge that because i don't once you've seen the sausage you know there's sausage getting made it's not like you can unsee make it pretty again yeah it is a

lot of luck and sweat but but but go back to these so i i'm I'm interested to hear about people who are saying how awesome. I haven't experienced that in the engineering disciplines. I've experienced it, you know, indirectly from marketing and salespeople who are always at various companies, extremely positive and congratulating each other on every penny that walks through the door publicly. Oh, yes. The group email, yay, we got a dollar. But I really haven't seen that much of that in engineering.

I do see it. But I see either people putting everybody down or if they're unwilling to put other people down. The kinds of putting down that I'm used to is more subtle than directly going up and saying. You suck? You suck. Because that would be so much easier to deal with.

It's the Socratic method where the lead genius on the team asks you an incredibly difficult question or questions the way you're doing something without giving you an alternative to the way you're acting. And then you have to prove a negative. Do you really want to do it that way? Is that the thing you're doing something without giving you an alternative to the way you're acting. And then you have to prove a negative. Do you really want to do it that way?

Is that the thing you want to do? And the answer might actually be yes, and they may not have an idea how to do it any better. They're just being... They're trying to make sure you thought of everything, which is good.

I mean, that's their role to make sure that... Sometimes. Sometimes I think that's true, and sometimes I think it's... Don't't forget there's a genius on the team yes and uh you know i but you know i think i i've done that not not because i wanted to show my superiority which i can't even say it but there's ways of asking that without being a jerk yes but does it matter how you get asked for how you feel afterwards i mean even when i have dealt with people like that if i come up to somebody to say well i'm not familiar with what you're doing

so bear with me but you know why did you could you explain to me your choices? And, well, maybe I'm going to have something to add just because I'm a different pair of eyes and go that way. Instead of, hmm, well, did you know about Frobnitz's third theorem of computer science, which explains that when you take the, you know, infinite loop and recursively Frobnitz it, you know, whatever, and you scratch your head. You've never heard of any of these things, and it turns out they're completely irrelevant to what you were doing, but it was just somebody spouting off. Somebody probably

insecurely spouting off, realistically. Sometimes, yeah. But it doesn't feel that way when they're the lead. It doesn't even matter if they're the lead. I doesn't even matter if they're the lead. I mean, peers that do that, even junior engineers,

I wonder if they know more than I do. Because somebody always knows... I always wonder if everybody knows more than I do. Yes. Somebody always knows more than I do about something. I would hope so. Every person knows something that I don't. Why would you have more than one person on a team?

Yes. Well, even sometimes I've wanted to clone myself and have the same amount of information and have clone Alicia go off and spend more time with her butt in the chair while I go to the beach, but she'd want to do the same. I was just going to say while you were at the beach. But even if we all had the same information,

people come at it from different directions. Not if you're a clone. Well, that's true. I think we're going to be cloning me anytime soon. Yeah. So I guess one of the things we're kind of talking about is this feeling of being imposter a feeling like you don't know you don't know what you're talking about you don't know what you're doing that everybody else is better that everybody else knows something you don't know, that Frobnitz's theorem of interstellar's quantum krabnitz

is somehow important to your daily life, but you can't even look it up on the internet. I mean, you've felt that way, haven't you? I have, less so in recent years, but definitely it recurs from time to time, especially when starting new projects and feeling, you know, recently I've worked on a couple of, um, consulting projects with similar technologies that somehow I've become a quote unquote expert in, which really means I've written some code more than once that does this thing. By the time you write it third time, you are the acknowledged international expert. In this particular field, that's not because of increased intelligence.

It's just because nobody works on it. But so, yeah, when starting the second contract in that field, it was like, well, OK, you know, I guess I can do the same thing I did before, but I'm not really an expert in this. And everybody's, you know, asking deep questions. And so you kind of feel on the spot to be able to provide deep and considered answers, even when you may not have all the information, because now you're the expert. But I definitely felt that way more earlier in my career, especially just for that first few years, um, where you're dropped into a lot of times, you know, kids out of college end up at a big company. And everybody there does in fact know more than you do.

And that's okay. They've been doing it for years. They've been, you know, working on this project for years and you come in and you have no absolutely nothing. And not only do you know nothing, you know, you know well when I started this was the days before Google and and you didn't even have the foothold of being able to go search and see if you could figure it out dinosaurs roamed the earth you know providing hardbound manuals for stuff so yeah it was difficult to even look stuff up.

It was difficult to even know what you didn't know. So there was a lot, a lot of asking questions and feeling like an idiot because, you know, I have no idea what this even, you know, where did this stuff even come from? Why is it done this way? What does that acronym mean? You know, that's what had been one of the hard things for me is then when the dinosaurs roamed and we started our careers, was you could have an acronym and everybody would know what it was. And as soon as you opened your mouth and admitted you didn't, you were also admitting that you were less somehow, that you were stupid.

That's not what that means. Luckily, nobody decoded the acronyms and never cared what they actually meant. So it was never clear to me that anybody knew what they were for but um but i i do think that imposter syndrome is something that a lot of engineers face because we all not we all that's a little bit universal but a lot of engineers we all in the room a lot of engineers come from a socially awkward background which i think has it has a component that feeds into this imposter syndrome thing especially when you're starting a new project with a new team and people you don't know if it's you know it's the feeling if i have to prove myself i don't know what's going on here it's been two weeks and i haven't contributed yet. Or it's been two weeks and I've broken the bill twice

and I still haven't checked in the first time. Everybody's mad at me. Everybody's mad at me. You know, so. They all look at me like I don't belong. So you said imposter syndrome and we've been kind of heading there but not saying those words.

And I did want to talk to you about it. Not because you're an imposter, but you know, because it is something it is something we've talked about off air. And it's something I hear a lot about on the women in technology groups. There's this idea that women feel like imposters. And it's called, let's see, Wikipedia says, it's sometimes called imposter phenomenon or fraud syndrome. Psychological phenomenon in which people are unable to internalize their accomplishments. Despite external evidence of their competence,

those who feel this way remain convinced their frauds don't deserve the success they've achieved. And proof of success, which I think this is actually pretty funny because you said something very similar recently. Proof of success is dismissed as luck, timing, or result of deceiving others into thinking that the person is intelligent and competent. Or worse, the person evaluating you isn't competent to make the decision. Oh, yes. My boss must be an idiot to have been deceived by my skills for this long.

What are they thinking? That's insane. So I hear about this a lot on the women in tech group, and I think... I'm not on that group, so I don't hear about it. I think it's interesting because a lot of the guys I know feel the same way. This is not a women in tech

issue. This is an engineering issue that somehow we're making each other feel bad. Do you think it's an engineering issue or do you just think it's a selection bias problem for the kinds of people who go into engineering? Are we going back to socially awkward? Because I'm really glad that we've labeled all of our listeners

as socially awkward because that's really going to help our numbers here. They know who they are. It's not all of you, just a few. Well, yeah, selection bias toward people who have a bent

towards technical mind engineering. I think it must be worse for women. It must be worse for women. It must be worse for women because they're, quote, new to the field. And I know many women are worried about letting their whole gender down by admitting their stupidity or admitting their ignorance

or admitting that they feel like a fraud. I mean, because as soon as you admit it, everybody, you know, there's a possibility that everybody starts nodding around you and then you're like, oh, crap, they all feel the same way. A lot of people claiming they're frauds and outside of their own internal conversation. I don't think so. I don't think so.

But you are not the only guy I've talked to who has essentially dismissed all of their success due to luck and timing. I mean, it's obviously not all luck and timing, but... There was a lot of perspiration and not a lot of all nights, but certainly a few late nights working on things to get it out and to make sure that everybody who was on

the team had what they needed. Yeah, I mean, it comes down to the question and this goes back to, am I good? Is, was it all just a mechanical effort of grinding the gears for long enough and hard enough? Anybody could have done it. Anybody could have done it. Or, you know, was there some special insights for some of the problems?

I think that's an impossible question to answer oftentimes. Decades of training. Yeah. I mean, that's more than grinding. That's more than just turning the crank to get an answer, but it doesn't make it impossible for everybody else. But if everybody who has decades of training is equally competent, then. Except nobody has the same decades of it. The problem is that you can't apply the scientific method to this, right? You can't take a project that you were on that succeeded or failed

and replace yourself with somebody else and do everything all the same and see what happens. Right? If I was getting a PhD, that would totally be my thesis. There's no control for your life to say, well, yeah, actually I was better than person X, Y, or Z. Or I was the best person X, Y, or Z, or I was the best person in that role at that time because I, you know, had the insight and the background to, to

solve this problem in this special way, but which was exactly what it needed. You had a lot of caveats there. The best person in this role at this time. I was trying to phrase, to go back to are you good, I was trying to come up with a specific metric for, you know, are you not a metric, but a description of what it means to be good. What it means to be good is, to me, is being able to solve problems

that not many other people would have been able to solve. Or at least not in the necessary time frame. And I think not only, I would add not only the perspective to solve the problem, to find a solution, but the drive, ambition, to see it through. Not just to get an idea of, you know,

well, you know. I'm not sure ambition is the right word. I don't think it is either. Drive is better. The butt in chair-ness. I don't think that scans. No, that really isn't going to make it into a haiku anytime soon. Yeah, it's not only the smarts, it's also the gets things done.

So I don't think you can just have it be the right person from an intelligence point of view. No. And oftentimes a really, really smart person might find themselves stymied, right? You know, you can have a genius who gets stuck on something and needs help from somebody else. So to imposter syndrome. I know.

I keep leading us away from that because it's not well defined. I guess you don't want to talk. Well, it was perfectly defined. Wikipedia gave us a definition. How do you deal with it? I think everybody feels it, but how do you deal with it? I gave a little class last year and i just i don't think we ever talked about me giving this little class and i wanted to know

what you thought i'm still here i'm thinking um do you just grow out of it because you get enough experience you just keep pushing that you realize the problems are all the same you're just going to see him again in a different flavor that That's part of it. Part of it... I guess I'm trying to analyze myself now, but part of it is like... Would you like a couch? I just don't care that much anymore. I know that sounds terrible, but that feeling of imposter syndrome is still there, but stuff still gets done anyway.

So it's not important. It's not that you don't care about engineering or what you're working on. You're just not placing a high weight on that feeling anymore. Yeah. And I have other feelings, you know, and I'm old enough that I've seen enough younger engineers now that I have a better sense of who's going to be

a good engineer even when they're inexperienced. I've seen the whole process from the outside a few times I think helps. What makes an engineer good in your book?

What do you look for for an engineer who's likely to be successful in the future? I want to see somebody who, at the same time, knows how to learn, picks things up quickly, and can find information, and at the same time is not afraid to ask for help. So the very thing that makes you get into the imposter syndrome, the fear of asking for help,

for fear that people recognize that you're a total fraud, is actually what you want. I mean, you want people to defeat that fear themselves and actually say aloud, what does this acronym mean? If they can't Google it, they should Google it first. I would hope they would be saving their questions for more important things than decoding acronyms.

But no, no, no, it's important. Sometimes you're in a meeting and nobody knows what L10N means. That, that, oh, geez. I got you on that one because you had to admit Sometimes you're in a meeting and nobody knows what L10N means. Oh, geez. I got you on that one because you had to admit to me recently that you... Yeah, but see, I didn't care. And I still don't care.

L10N means localization. There are 10 letters between the L and the N. It is not really a technical acronym. And let me just say that that is the worst, the absolute worst abbreviation ever conceived by mankind. Internationalization is I-18N. Oh, my God. Okay, I'm sorry, I'm sorry.

Okay, so we want junior engineers to learn. I lost the incredibly important thought I had. Which is deeply profound. You still get credit for that. And was going to push this podcast over the edge. Jump the shark. Jump the shark. I think we did that about 20 minutes ago. When I said I want them to be able to learn and to be able to ask for help, there's a balance.

I don't want somebody who's asking for help constantly. I want somebody who knows when they've exhausted their abilities to find a solution. I'm okay with setting a time limit for some of my junior engineers, but yes, before they learn that skill themselves. But to know when you're beaten and when it would just be faster to ask somebody for help. But not to go there first. Spend an hour on it before you ask me a question.

It might be more expedient for the project. It might be better for the company if they asked immediately. But it's worse for them. But it's worse for them because they're not going to learn how to figure stuff out, and they're not going to learn where to look stuff up. And eventually it's going to be worse for the other engineers because it's a constant interruption when people are asking for help. It's a constant train, yes.

But if they learn how to look stuff up, they learn how to do this stuff, then it's better in the long term. It's a balance. You want somebody who isn't afraid to ask for help, but at the same time is waiting to ask for help until they truly need it so we want them to be partially imposter syndrome people so okay I'm I do want to say what I what I said in that class which some people

have have emailed and said that it was helpful. Because I've been picking on you and saying you feel imposter syndrome, but you're not the only one. I definitely sometimes am just sure that any second now, they're going to realize I have no idea what I'm doing. And not just with podcasting. Even now, after all all the stuff you've done written a book on embedded systems worked for many amazing companies

at least 37 companies in the last 10 years and you still feel that way of course although tell me how that actually feels as you said I don't believe it as much. Yeah. It feels like any minute now, somebody on my Twitter feed is going to say, you have no idea what you're talking about. Here is the answer to everything you've ever meant to look up. Here is,

you know, in one line I can defeat your whole strategy of life. In a hundred word blog post I can summarize your book so that everybody understands it better. So actually what I said in this class and what i do for myself which really helps me your mileage may vary i have a slide deck and i put things that i am proud of in my slide deck

and it's i keep it at 10 slides and anytime i need i'm feeling this way. Anytime I feel like I have failed. Anytime I need to amp myself up to talk to people. If I need to give a presentation, I don't give these slides, but I look at them and, you know, I have my book on a slide and I have a list of patents I have. And I have, I, you know, I have the, the things I have done, I have success stories for myself. And I try, I try to keep it short. But it helps me acknowledge that what I have done useful and good and helped other people. And that makes it so that when I feel like I'm a failure, when I feel like I'm just a waste of oxygen, I can say, look, this is just a feeling right now. Whether it's doing pottery and artistic things.

What brings that feeling on? I mean, you're not just sitting there throughout the day writing code and suddenly, wow, I feel like. No, no, it's when the technical lead or some guy that I don't know very well, who I respect for some reason, maybe just because his title is technical lead, comes up and asks me a question and I go, crap, I have no idea. Or when he comes up and says, what question and I go, crap, I have no idea. Or when he comes up and says, what you're doing is wrong, and instead of saying, I don't think so. I've already written a few I2C drivers. I know what I'm doing, thanks.

I buy into it. Maybe it's because my blood sugar's low. Maybe it's because he's right. Maybe I have done something wrong. He's been working in this industry, this application for longer, and I didn't take into account all the factors. I get that feeling of, well, man, I just suck. You know, I was just thinking that nothing is better for this particular feeling

than working on a really small team with just two or three people on the whole project uh for you know a couple of years and having that responsibility to be a large part of the project and working closely with somebody else in the back and forth and just seeing how much you can accomplish in a small team without being overwhelmed by the structure with, oh, there's the lead, and then there's the senior engineers, and then there's this and that and that, and you're, you know, cog 27.

In a small team, you can see your output more effectively. You can see your output more effectively. And in a large team, you can get lost. Your projects can get cut or never shipped. Well, and you also have less intense conversations with the other people on the team, assuming you get along with them, where you both learn stuff from each other. And I think that dispels some of that feeling because you see, oh, well, you know, this guy who I respect,

he didn't know this. And I did. And we're learning together. And I don't know this. And he does. And we're exchanging information and we're learning together. And I don't know this and he does and we're exchanging information and we're learning from each other and that feels a lot better than the kind of the traditional engineering situation where you're in a team of five to ten people structured by seniority

and somebody comes in and they're either junior or from another field and they're having to prove themselves. And I'm slightly afraid that we're answering this poor guy's question in a completely psychological way when he was just asking for some nice C tests. Well, no, I think the question of why in the world would you ask if you're a good embedded software engineer is a valid one. And where I'm ascribing things to him that I have no reason to believe he feels. But I think that the question in general, am I good enough, usually does come from a feeling that you're not look the

solution is to stand in front of a mirror and say to yourself i give myself 10 warm fuzzies a day no that was the thing they taught us in elementary school okay sorry that you say to yourself i'm good enough i'm smart enough and gosh darn it people like me. I guess that is exactly what my stupid slideshow does, doesn't it? No, well, you can laugh, but I mean that's a common technique for countering sort of negativity is to come up with things that are,

you know, arguments against that. Well, this is the cognitive behavioral therapy that comes up whenever you're in a downward spiral. You need to talk. The part of your voice that is saying you suck or this is horrible or you're doing a terrible job needs to be countered by the angel on your shoulder that says, look, you've gotten

through this before. You can do it again. You just need patience. You just need drive. Or maybe it tells you, you know, you need to go work on this. Go take a class. Go learn something new. Go figure out.

I'm going to come back and say, if you're at all unsure about your competence in a technical area, don't go read a book. Really? Or if you are going to read a book, read a book while you're working on a project. Oh, so reading isn't enough. You think you need hands on the keyboard.

I really feel... Or soldering iron. I've never learned as much as when I've had to sit down and do a project and get something done, even when I knew nothing about how to do it to start with. And there's been plenty of times in my life where I've said early on, gosh, you know, I want to learn C. So I'd grab a C book and I'd read it. And that's really not very effective. It really, really isn't. Maybe if you go through the exercises...

I am kind of a compulsive reader, so... But you can't tell me that you can read a chapter on C and then be able to apply it the next day. No, I completely agree. But I can read a book about design patterns. Maybe if you know C. Maybe if you've been working for a long time and you see, oh, there's a technique,

you can assimilate that. But somebody who's not as familiar? But when I needed to implement a helicopter filter. A helicopter filter. Is this a filter to stop helicopters? It was a filter. It was an acoustic filter to get rid of helicopter sounds so that we could better identify machine gun sounds uh and so i needed a machine learning sort of i needed an

algorithm heuristic to sort out one from the other you had a project i did but I didn't, it was too amorphous. There was no clear-cut path from here to there. And so I needed to go, I took the machine learning class at Stanford from Dr. Eng, and that was fantastic. And I read books, and as I, well, you know, actually, I'm proving your point here. As I went through each chapter, I would apply it to my helicopter filter and figure out if that solved my problem. And then

when it didn't, I would go on to the next chapter. So I was, you're right, I had a project. I guess what I'm saying, and this is something I learned in graduate school, is do the homework. But I think reading about other things matters. I mean, whether it's ocean patterns or the history of swearing or how modern art isn't completely stupid. I was not suggesting don't read. I was suggesting if you want to get better at subject X, don't buy the big book of X and think that just by reading it cover to cover, you're going to be... Oh no, you have to do x as well yeah that's all i'm saying i i like books so i think maybe by the little book of x or the book of x projects or sure and you know you can read that stuff on the side and you do assimilate stuff and you get new ideas but if you're concerned about an area

if you're saying to yourself gosh i don I don't think I really grasp, you know, pointers and see. Go write some damn pointer stuff. Draw a picture, write some code, draw a picture, have it break, fix it. Write yourself a little database program. You know, just make, don't have something totally nebulous.

Yeah, all right. Yeah, do the homework okay and buy that well let's see we covered uh i covered the imposter syndrome maybe a little bit more than anybody wanted uh learning by projects and by books, teaching. There actually is a C exam, although you can only take it once. What good does it do? I'm sure there are more. Yeah, Bar has one too, the Bar group.

But that one you have to sign in, you can only do it once, and I've never done it. I think there's sites with a bunch of interview questions too and those are you know good little coding exercises um i think that when you read those or when you read actually when you read books about an area you think you kind of grasp figure out if you would put the information together a different way. That helps me trying to figure out, do I agree with how this person is teaching it? But that's kind of a teaching exercise, and we already talked about that.

Yeah. I guess what I would come back to is, why are you asking yourself this question? And if it's just areas you think you're weak in, well, go try it. Yeah, the great thing about computers and computer software is you can screw up 999 times

and only get it right the thousandth and nobody will know. Unless you check it in every time and then somebody will know. Jim mentioned Free and Malik. And Jim, all I have to say about that, if you're doing embedded systems, I am all for you never knowing what those mean.

I have no idea what you're talking about. In his email, he said that... No, I know what you're talking about. I just find that to be a bit of a hardline position. Malik. There are embedded systems now that come with RAM in quantities greater than a few K. Why?

So that they can do stuff. That's just cheating. You've got more than 16 K on there. Some embedded systems have operating systems. Oh, man. Operating systems. Some of them even talk to the internet. I defy you to write a protocol stack

without dynamic memory. All right, yes. And at some point we will be talking about how to tell if you need an operating system. And I agree. Once you have an IP stack in there, you need an operating system. Well, I think we've exhausted the question.

Do you agree? Anything else? Exhausted me. All right. That'll do. Thank you for joining me. Yeah. And thank you for producing the show.

You have high standards for how good we sound, and I really appreciate it. And you, listeners, if you have any comments or questions about this show or ideas for future shows, please send them along. Hit the contact link on embedded.fm or email show at embedded.fm. And Jim GF, thank you very much for your email and for letting me read it on air. It's nice to know people are listening.