Transcript from 529: The Narwhal Looked Amazing with Chris Svec, Christopher White, and Elecia White.

EW (00:00:06):

Welcome to Embedded. I am Elecia White, alongside Christopher White. I am happy to say that Chris Svec has returned to talk with us about training up new engineering hires. And if you think we are going to stay on that topic, welcome newcomer. You have clearly never listened to the show.

CW (00:00:24):

Thought we were going to talk about another movie. I guess not. Hello.

CS (00:00:29):

We can talk about Wimbledon. We can talk about World Cup. Actually, I have not been watching as much World Cup as Wimbledon, but any of these topics.

CW (00:00:36):

All right. You have joined us. Welcome. Welcome back.

CS (00:00:39):

Welcome. Good to talk to you both again.

EW (00:00:44):

We know you, because we have actually met you in person.

CS (00:00:47):

Amazing.

EW (00:00:49):

Could you tell us about yourself, as if we had never met you, and we were just meeting you, I do not know, on the train to Palo Alto?

CW (00:00:58):

Why would I be going there?

EW (00:01:00):

He would.

CW (00:01:01):

Okay.

CS (00:01:02):

At first I would probably say, "Can I have that wallet back, please?" But then I would say-

CW (00:01:06):

You sound like Chris Spectre.

EW (00:01:07):

<laugh>

CS (00:01:11):

<laugh> I am Chris Svec, Director of Embedded Software Engineering at Insulet. At Insulet, we make a tubeless insulin pump for people with type 1 and type 2 diabetes, to help people who have diabetes to live better and to simplify their lives.

(00:01:25):

I have spent, somehow, 25 years now in hardware and software. I basically love all things embedded systems. I have been friends with you two for forever.

(00:01:35):

Over the last ten years, I have really focused more on how to build and grow embedded systems teams. More about the psychology and the sociology about how we work together, and a little less on the technology.

(00:01:50):

But yeah, that is my elevator pitch for the subway. Not subway. I have actually never ridden the transport in the-

EW (00:02:02):

Caltrain.

CS (00:02:02):

Caltrain? Caltram? Caltrain.

EW (00:02:04):

Train.

CW (00:02:05):

It is a train. It is an actual train. I am on the train. There is BART, which is the Metro kind of thing. And then the Caltrain, which is a train train.

EW (00:02:12):

Weirdly, we are off topic already.

CS (00:02:14):

Already. Very on brand and off topic.

CW (00:02:18):

That is a holiday.

EW (00:02:18):

And you used to work for iRobot?

CS (00:02:22):

I did. I did spend 11 long and good years at iRobot. And then I have done chip design before. I have done various embedded systems within chip companies. And then outside of chip companies. I have done more embedded systems lately.

(00:02:35):

I spent last couple years at a medical device company. I had never done med device. So I have spent the last couple years learning how to spell FDA and what that brings with it, the responsibility and the process and everything with it as well.

EW (00:02:50):

I do not think we really need to do this, but just for crossing Ts and dotting Is, you are not talking for Insulet as part of this podcast. This is all just you.

CS (00:03:03):

That is a great reminder. Yep. I am not speaking for anyone other than myself, just my personal self. I do not speak for any company, past, present or future. Thank you for that legal reminder.

CW (00:03:11):

Well, all right. That forecloses a lot there.

EW (00:03:15):

Okay. So let us get to lightning round.

CS (00:03:17):

All right. I am going to flip this. I have got some lightning round questions for you. This is the relationship test edition of lightning round. I am going to ask you questions for each other. So Elecia, you have to tell me what do you think Chris would answer, and vice versa? Elecia, you are going first.

CW (00:03:34):

You should keep in mind I edit this podcast.

CS (00:03:36):

That is true. I look forward to hearing how this ends up.

(00:03:38):

So Elecia, if Chris had to play a rock gig with one piece of drum equipment, what one piece of drum equipment- It is like he gets a one bass drum, he gets a snare drum, he gets a high hat, one cymbal, he only gets one. What would he play with?

EW (00:03:52):

A snare.

CS (00:03:53):

All right. And if he gets two, what would he play- Two pieces. What would his second piece be?

EW (00:03:58):

A snare and a drumstick.

CW (00:04:00):

<laugh> A drumstick.

CS (00:04:01):

Ooh. Drumstick.

CW (00:04:02):

I think a drumstick was included.

EW (00:04:03):

<laugh>

CS (00:04:04):

No, I like it. I like it. I like where she is going with that. Bonus points. Bonus points for that one. Chris, if you could insert like a lightning sound here, to show that she gets the bonus points, that would be great.

(00:04:16):

Chris, you have to answer for Elecia. Mountain or valley fold?

CW (00:04:21):

They are equivalent if you turn the paper upside- Mountain fold, obviously.

CS (00:04:26):

All right. Obviously. Obviously. Elecia for Chris, AI via the terminal, or via a web interface?

EW (00:04:35):

No AI.

CS (00:04:36):

No AI.

(00:04:36):

All right. Chris for Elecia, PID or Kalman filter?

CW (00:04:43):

<sigh> PID.

CS (00:04:45):

Chris is really getting into this, I can tell. Elecia for Chris, Geddy Lee or Neil Peart?

EW (00:04:50):

Neil Peart.

CS (00:04:51):

Neil Peart. Okay.

EW (00:04:51):

Peart.

CS (00:04:51):

Peart.

CW (00:04:51):

<laugh>

CS (00:04:51):

Chris, what is the right pronunciation of his last name?

CW (00:04:58):

Peart.

CS (00:04:59):

Peart. Okay. Peart. Peart.

(00:05:00):

Chris, what is Elecia's favorite sea creature?

CW (00:05:06):

Octopus.

CS (00:05:07):

Octopus. All right. And this-

CW (00:05:09):

Probably whale.

CS (00:05:09):

Whale?

CW (00:05:09):

It changes, depending on what she has read about recently.

EW (00:05:13):

Could be a nudibranch, could be a narwhal.

CW (00:05:16):

Could be a nudibranch, could be a narwhal, could be-

EW (00:05:17):

Gosh, there are so many options.

CS (00:05:20):

I saw some passport- Some friend got a new passport recently, and there was a narwhal on. I think it might have been Canada's passport. Canadian passport.

CW (00:05:26):

How do we get Canadian citizenship?

CS (00:05:28):

I just want the passport. Just the narwhal looked amazing.

(00:05:30):

All right. Last question for each of you. Elecia, if Chris had to use only Rust, or only code with AI for a year, which would he choose?

EW (00:05:41):

Oh, it does not matter. If those were his only two options, he would just go into the forest and not use any code.

CS (00:05:48):

Okay. Okay. Easy enough.

(00:05:49):

Chris, if Elecia had to have an LED blinking in her office for a year, but she would be paid let us say $10 million at the end of it, would she do it?

CW (00:05:58):

No.

CS (00:06:00):

No. Absolute. All right. Thus concludes lightning round. Thank you for playing.

CW (00:06:05):

<laugh> Those were very good.

EW (00:06:10):

Okay. I have called you here together to talk about new college grads. To some extent, this show is ideally going to help some new college grads as they acclimate to industry from school. But I want to take it from the other side, is you are a manager. I have been managing folks.

(00:06:35):

What is your strategy when you hire a new college grad? They get there. There is the first two weeks, which is special. They get their computer. They learn about 401(k)s. They get the fire hose of information that is culture, and the tasks they are supposed to work on. And there is just this incredible period of learning. I do not care about that so much, because you have to do all that.

(00:07:08):

It is the how do you develop someone from being a new college grad, bright potential, smart person, lots of knowledge, into being an engineer who can work on their own?

CS (00:07:23):

Great question. The default question I have started asking myself and asking my team and having people ask, regardless of what we are doing at work lately, is what problem are we trying to solve?

(00:07:35):

Because engineers, we love coming up with solutions without understanding the problem first. Humans do this all the time, but I think engineers are really good at saying, "Oh look, I made something, and now where can I find somewhere to use it? " Instead of stepping back and saying, "What problem are we trying to solve?"

(00:07:52):

I would say the problem here is you are saying, "Hey, we got a new hire, new college grad, a relatively junior person. Maybe they have interned, maybe not. And that is the situation we find ourselves in."

(00:08:05):

The way I would ask the question, "What problem are we trying to solve?" you have answered some of it. You have said we are ignoring the first two weeks, but how do we get them to be able to be understanding enough to do pull requests and so on?

(00:08:19):

I would go one step further and say, do we have a goal of saying in six months we want them to be able to be on the team, on a scrum team, or on a project team and reasonably independent? Or is it in three months we want them to do that? Or in six months, we want them to have researched this new area for our project we are giving them?

(00:08:40):

So I would say step back and say, for this particular human in this new hire, what do we want them to be able to do in six months? And we do not have to answer that here because obviously that is specific to whoever you are onboarding.

(00:08:55):

You need to keep that in your mind as the hiring manager and as the team absorbing this new person, so that you make sure that they are heading in the specific direction you want them to have. As opposed to, "Well, just throw them at the codebase and let us see what comes out the other end." Does that make sense?

EW (00:09:13):

Yeah, but it was not what I was going for at all.

CS (00:09:16):

All right.

EW (00:09:18):

Yes, we definitely need that, what does this person need to do in six months?

(00:09:23):

But I wanted to talk more about the teaching them to be a senior engineer, to not have to be told what they are going to work on next. But to be able to see the system as a system and say, "Oh, that is what the next important thing is." And I do not think it is a six month journey. At least a year, probably five.

(00:09:49):

I do not want it to be particularly company related. I am going back to when I started, of course. I went to HP, long before HP and Compaq did their thing. HP Way had just come out. It was the old HP. I joined as a cohort. They hired hundreds of new grads. In my building there were like 40 of us.

(00:10:22):

Chris, you were kind of part of a cohort as well. No?

CW (00:10:28):

No, I do not think so. Cisco was not that big at that time. I do not remember too many other... There were a couple, but it was not like HP where they- You probably had meetings with all the new people or something like- They would not do that.

EW (00:10:44):

Only once or twice.

CW (00:10:46):

Yeah. No, I was just a new person on a team.

EW (00:10:51):

But I did feel like HP had this idea that you should help the new college grads, the new people to the team, to become senior engineers. To not just have that be a side effect of seeing too many problems and developing cynicism.

CS (00:11:10):

Got it. Got it. Yeah. So then the problem you are trying to solve- I will bring it back to me here, bring it back to my question. The problem you are trying to solve here is not the specifics of what this person is going to do even in the one, two year timeframe.

(00:11:26):

But instead, how do I start with a new hire, fresh out of college person, and in five years, how do I have somebody who is senior, who can go on independently and figure out what problems to solve? Who can sort of make schedules and figure out what are the risky elements? What should we do first? Learn the judgment and taste that goes along with the senior engineer. Is that a little what you are thinking?

EW (00:11:51):

Yes. And if I can do that for three people, then I can promote the person who is currently in the senior position, and they can do my job and I can retire to an island.

CS (00:11:59):

Fantastic. Yeah. Putting yourself out of work is always a good goal. I love that.

(00:12:03):

I have a few general thoughts. I know that we talked about this a little bit before the show, but I will just launch into them, and obviously interrupt and we can dissect them as we go here.

(00:12:17):

There are a couple things that I think you need to do, to really get a new hire sort of- I am going to use the word "empowered." I do not like that word, but the default for a new hire is to come into your company scared and quiet and with imposter syndrome.

(00:12:35):

There is a phrase "going dark." When a new hire comes in and if they are too scared to ask questions, if they are too scared to appear ignorant, and if they do not feel like they can ask what they perceive as dumb questions, or be perceived as someone who does not know something they should know, you are going to shut them down. You are setting that up for failure that way.

(00:13:02):

So the single best skill and behavior I think to have as a new hire or anyone who is new into a team, is the willingness to ask questions, is to admit ignorance. I actually think it is a superpower to be able to admit ignorance publicly.

(00:13:16):

And so as you onboard a new hire, I am explicit with people who I hire and who I work with who are junior and say, "Hey, you are not going to know a lot of stuff here. You are going to be confused. You are going to be frustrated, because it seems like, 'Why is this so hard to learn?'"

(00:13:33):

"The working world is not designed like a class with a well-worn syllabus, that okay, we teach you thing A, we teach you thing B, and that leads to things C. The working world is just not like that."

(00:13:45):

Now as a hiring manager, it would be great to set up the scaffolding for the new hire. I think Elecia, that is kind of what you are trying to do here. But it is hard. It is tough. It is not going to be linear. It is going to be a very non-linear journey.

(00:13:58):

Setting up the expectation for the new hire that, "Hey, you are going to be confused. That is fine. Please ask questions." The biggest danger for a new hire is if they go dark for a week or two or three, and you do not hear from them, they do not hear from you. They are just toiling away in confusion and sadness. They do not get anything done, and everyone loses.

(00:14:17):

So I will stop there. Any comments on that? Am I going on the right track for what you are thinking here, Elecia?

EW (00:14:24):

I really want it to be from the tech leader or new manager perspective, which is to flip around what you said. You really need to praise new hires for asking questions.

(00:14:36):

Even though it may be interrupting what you are doing. Even though it may be irritating, because why did they not just read it? I spent so long writing a wiki that now is a thousand pages.

(00:14:47):

Asking questions is good, especially in the beginning.

CS (00:14:54):

Yes.

EW (00:14:55):

If they lose that, they are going to end up dark.

CS (00:14:59):

Yes. 100%. 100%.

EW (00:15:04):

Yeah, actually what you said is right. What I would like is a year long course, on moving from being a junior engineer to being solid in your engineering practice. Maybe it is an hour meeting, and two hours a week of homework.

(00:15:24):

It would of course have to be per company, per project. But there is a lot of commonality in embedded on what you should expect.

(00:15:39):

Asking questions, praising people for asking questions, is definitely one of the things that we need to do and we need to model. I really try to do that where I am like, "Yeah, okay, there is this part of this project I am working on that I do not understand well."

(00:15:55):

So I am totally willing to ask completely stupid questions, because I find it is probably a good thing for people to realize that I do not know everything and that I am happy asking questions. And I am also happy not knowing everything.

CS (00:16:14):

Yes. And you are happy doing it publicly, so that everyone around you can see that, "Hey, Elecia does not know everything, even though she is a guru, she has got a podcast, she has got a successful company, and she has written the book on embedded systems."

(00:16:25):

If someone like you can say, "Hey, how does that work? I do not get it. Can you explain that again?" that is huge. That is such a great example. So again, totally agree with that.

EW (00:16:36):

So in the list of things managers should think about, is model the behavior. That should always be what you do, but modeling the questioning behavior is a really good one.

CS (00:16:47):

Yes. And not just for the manager themselves, but the cranky old-timer on the team who might be predisposed to saying, "RTFM, kid. I wrote it there for you."

(00:16:59):

Maybe have a talk with the whole team and say, "Hey, look, this person has not worked for 20 years. This person has not been in our codebase for five years, or even five minutes. They are going to be confused, because code is not self-documenting as much as we would like it to be. So have patience. Remember, try to remember, what it was like when you were 22 and new to everything," so that everyone can model that.

(00:17:24):

And then publicly praise people on your team. Public or private, it is up to you. Especially the senior people say, "Hey, thank you for asking that question in that public forum." Again, admitting ignorance publicly is a superpower.

CW (00:17:39):

I have saved up a bunch of questions. Do you want me to derail?

EW (00:17:42):

Yeah.

CW (00:17:42):

Do you have a direction after this? I am sure you do, but I do not want to screw it all up.

EW (00:17:51):

It is all good.

CW (00:17:52):

I want to go back to a fundamental question, which you all have not answered. Why hire new grads? If this takes all this extra work, and there are people out there who are seasoned- I am being devil's advocate. People out there who already know how to do all this stuff, why not just find somebody who is five years out of college or ten years out of college, and hire them?

(00:18:12):

Why hire a new grad which takes extra work, and they are just going to leave after three years to go to a new startup?

EW (00:18:20):

Because they are cheap.

CW (00:18:22):

Are they?

EW (00:18:23):

Sometimes. Does the amount of effort to train them cost money? Yes.

CW (00:18:28):

I am not saying it should not. I just want to know from a company's perspective, what is the benefit of hiring a new grad?

CS (00:18:37):

Cost is one thing. Zero years experience costs less than five years experience, costs less than ten years experience, and so on. That is not always true, depending on how quickly salaries are changing in a market, but that is generally true. Additionally, especially-

CW (00:18:53):

But are you getting what you pay for? Because the productivity might be the third of a five year-

EW (00:19:00):

But you are training them the way you want them to be trained.

CW (00:19:02):

That is fine. Okay.

EW (00:19:03):

So yes.

CS (00:19:05):

They may not bring in bad habits that have been learned elsewhere. Newer people to the industry also bring in newer skills and newer ways of thinking. And some new ideas that they learned in college or from their friends or whatever, because they are not set in their ways after doing something for 25 years.

(00:19:24):

They have never heard of IAR or Keil. And when they see IAR or Keil, they say, "Hey, have you heard of this thing called GCC or VSCode or Cursor," or-

CW (00:19:35):

We should try that.

CS (00:19:35):

Literally anything. So that is a very real, real thing.

EW (00:19:40):

New tools.

CW (00:19:40):

Have you heard of this thing called "vi"?

CS (00:19:43):

Vi. Vim. Have you heard of Vim?

CW (00:19:44):

Have you heard of Edlin?

CS (00:19:47):

Edlin. I love it. I love it.

CW (00:19:48):

Okay.

EW (00:19:49):

No, wait, no. There is more on that.

CW (00:19:50):

Mm-hmm.

CS (00:19:51):

Oh, there is definitely more.

EW (00:19:53):

They are not cynical, and they do not-

CW (00:19:55):

Wait a minute.

EW (00:19:56):

They do not-

CW (00:19:57):

You went to school with me.

EW (00:19:58):

I went to school with you. Yes. You have always been cynical.

CW (00:19:59):

<laugh>

EW (00:19:59):

They do not bring in the "No," is always the first answer. They often bring in an excitement and a joy, that if we can nurture that, the whole industry becomes more fun.

CS (00:20:14):

There are a couple of good company side answers too, especially for a larger company. Something that a global HR team will look for, and or an HR- The organizational structure side of things, is you want a team that is built up of people of a variety of everything.

(00:20:35):

So diversity is good just in general. Diversity of background, diversity of gender, diversity of all the things is good because you get different inputs, different experiences, different eyes on things. And one of those is skill level.

(00:20:50):

The inexperienced person is going to have very different observations on something, than the person who has been doing this for 30 years. There is more of a beginner's mind. And so there is some of that.

(00:21:00):

In addition, some HR departments will simply say, "You have got to have a bell curve of staffing levels. If you have 20 people on your team and they are all senior, then that is not super healthy. You need some really senior people, and you need some junior people, and you need some people in the middle."

(00:21:20):

So some companies will actually say, "When you hire, you have to keep in mind what your seniority distribution looks like." And again, they do that for a variety of reasons. But some of the good part of that is just getting the diversity of thought and experience.

(00:21:35):

Another thing is- This bit is a little bit even tricky to talk about. But someone who is junior, someone who is learning, is going to be able to do some of the work that is maybe, I am going to call it "grunt work."

(00:21:49):

I am not meaning to demean the work. Assuming that you are only making real work that actually is useful work that needs to be done, then you know what? There is some work that needs to be done for every project that has not been automated yet.

(00:22:03):

Having someone who is new who has not done it before, is a better use of the company's money, than having someone whose time and energy and budget should be focused on higher leverage, higher value things. And so having someone who is junior to do, I will say some of the grunt work, is maybe more valuable to the company than someone who has been doing this for 30 years.

EW (00:22:28):

Going back to the diversity, I think you can find more diversity in college students than you can in engineering. And if you have a good plan for helping them grow, maybe we can add diversity to the whole industry.

CS (00:22:41):

That is fantastic too. If you look around anyone who has had- The average 20 year experience embedded systems person looks a lot like me. It is a middle-aged white dude who grew up in tech.

(00:22:53):

If you just want to have that for your company, then I guess that is what you can do. But yeah, if you want to get more diverse anything, you got to look outside of that.

CW (00:23:02):

Do you train everyone on dealing with new grads?

(00:23:05):

You talk about these things, like talking to the senior people who might be a little disgruntled or not wanting to deal with newbies. Is that an individual thing where you pull Gary from QA aside and say, "Look, you got to talk to Sarah and be nice to her. She is a new grad. Stop acting like your normal self," or what?

(00:23:31):

Or is there a plan? "Okay, here is the team. Let us sits the team down. We have new grads. Here is how we want to bring them up. It is all formal."

CS (00:23:40):

I think you do it with the whole team. If you are buying into anything that we are saying here, and if you think that, "Okay, yeah. Let us encourage the new hire to ask these questions. And let us reward curiosity instead of punishing it." Then I think honestly, even if you did not have a new hire, you should do this with your team.

(00:23:59):

Because I guarantee there are people on your team who are scared to ask questions, because they do not want to look dumb. Even if you never hire anybody again. I think there is value to saying, "Hey, everybody. Let us put our ego aside a little bit. Let us all be a little quicker to admit our ignorance internally."

(00:24:15):

"Oh, and by the way, we have got a new hire coming, who is going to have imposter syndrome at the wazoo, and really needs us to encourage curiosity."

EW (00:24:26):

I could see having a new hire being an excuse for having that meeting and talking about it. But in general, no. A new hire does not mean that I would have a meeting that says, "Be nice to the new hire."

(00:24:38):

I would go to Gary, grumpy old Gary, and say, "Would you like to mentor so-and-so?" And when they say, "No, I am much too grumpy. I am a curmudgeon." Then you say, "Well, could you at least be nice to her?"

CS (00:24:55):

That sounded like Eeyore. I would just like to point out.

CW (00:24:57):

Yeah. Well, there are only so many voices.

CS (00:24:59):

No, that was a good voice. It took me right to the right personality. I have got a very good visual picture, or mental picture, of them.

CW (00:25:07):

One of the things when I was new, was nobody sat me down and said, "Hey, it is okay to make mistakes. That is what code review is for. That is what the source control system is for. Do not hover over the enter key on your PR for an hour sweating before pushing the button, just because you are so nervous about merging something."

(00:25:27):

Nobody told me that. So I spent a lot of time in that mode, like, "Oh boy." And my code was godawful in my first two years.

CS (00:25:37):

I thought you were going to say your code was perfect, as a result.

CW (00:25:40):

No, no, no. It was- Orthogonals of the issue of me being nervous to commit it, it was still bad. I think that was good, because Cisco gave me permission to put bad code in, I guess.

(00:25:53):

But yeah, do you sit down and say to the new grad, "Look, you are going to have imposter syndrome. This is a new experience. It is okay to make mistakes. Everyone here has made mistakes. Everyone here makes mistakes on a monthly, weekly basis. You will make mistakes. Nobody is going to yell at you, unless you push to production on a Friday night."

CS (00:26:18):

Even then, we should have systems that keep us from doing that, instead of allowing it to be. Yes. Getting into more tactical stuff, I think we have been sort of bigger picture. So what I like to do is to assign a buddy to every new hire.

(00:26:32):

That buddy is somebody who cannot be the manager, should not be in the line of reporting. Ideally it is one or two or three levels above the new hire, seniority wise. That buddy should be there- The manager should also say this, but the buddy should then say, "Hey, look, you are going to make mistakes."

(00:26:52):

"Here are two bugs that I pushed to production in the last six months. Here is how we found them. Here is how we fixed them. And no one is getting fired over it. No one is getting yelled at. We might do a retro. How can we avoid that kind of bug in the future? But not a big deal."

(00:27:09):

A general principle that I think I try to do- Actually I need to follow up with somebody at work, I just remembered about this. Is that companies do lunch and learns. "Hey, I learned this new topic. Here is how a PID works. Here is how Claude does this neat thing. Here is this new embedded systems chip that I found, that has a cool peripheral, blah, blah, blah."

(00:27:29):

But something else we should do lunch and learns about is bugs. "Hey, here is this bug. We found it only in the wild, in the world. Here is how we tracked it down. Here is the debugging techniques we used. Here is how we fixed it. And here is some ways we will try to make it never happen again."

(00:27:44):

So that people can see that the person who wrote the bug, and then hopefully they are also the person who found the bug, they have lived to code another day. They are not punished.

(00:27:54):

The joke is, "There are two phases to programming. There is debugging and there is bugging. And those are the only two phases." So if you are not debugging, then you are bugging. That is kind of a joke. It is very tongue-in-cheek. But setting that expectation is good.

(00:28:12):

The other thing about having a buddy there, is I would have the buddy sit with the new hire, and the buddy is working on a task of their own. The buddy should be thinking out loud as they are working through the task and then saying, "Okay, I have a new task. This Jira ticket is to go and implement some new little feature. Here is how I think of it? Here is how the system works. Do you have any questions?"

(00:28:36):

They are going back and having a conversation with the new hire. Showing them how they are actively thinking through the feature or the bug or whatever it is they are working on. And then have the new hire sit there and maybe they code together. Maybe they do a little bit of pair programming. "What do you think of this? What do you think of that?"

(00:28:57):

Then actually show them as they put the PR up. And then their PR will not be perfect. So hopefully other people on the team then do pull request comments. Then show the new hire that, "Oh look. Gary over there, he actually found this giant hole in what I implemented. Good for Gary. Glad he caught that."

(00:29:16):

And then, "Let us fix it together." So that the new hire can see an example of someone getting active comments on their PR. And see, "Okay, it is okay. It is okay to not be perfect. That is part of what the PR is for. Pull requests are for catching errors. They are also for having everyone learn about the system."

(00:29:37):

Does that answer some of what you were talking about there?

CW (00:29:40):

I think so. Yeah. Yeah, no. It is a question of formality. How much is there a, "This is our company process for the new grad," on the new grad side, and on the team side? It sounds like it is a mix of things, which is appropriate and probably depends on the company and the size of your company.

(00:29:57):

If your team is three people, no, you probably do not need a new grad hiring process that everyone follows. If you are HP with a cohort, then I suspect HP had a binder with 8,000 pages and contingency plans for every sort of failure. Yeah. Okay.

(00:30:16):

Well, I have one more thing, but I think I will hold it for later because it is a kind of a shift.

EW (00:30:25):

Thinking about this- I am thinking- We had some new people added to my team. They are pretty junior. I am having a good time trying to make sure that they understand that what they are going through is totally normal. The ignorance is not their fault. It is just their turn. We all go through this, and we all start to understand more.

(00:30:55):

What I really have not been able to articulate to them, is that there is often a loneliness in this. Svec just said "pair programming." We cannot do that right now. We actually need them to be working on their own things. So the more senior engineers are trying to mentor them through PRs. We are all frantically doing things for a little while, and it will get better.

(00:31:23):

But the idea that we need to tell them, "It is okay to make mistakes," is so important. I do not think I have done that enough. I have tried to say, "You did a good job on this," but I do not think I have let them know that- A few times I have said, "It is okay if it goes wrong. Just let me know, and we will untangle it together."

(00:31:48):

But I definitely am trying to let them make their mistakes and not stress about it, just to show them that, "Yeah, it is fine. We can figure it out. Go ahead, do the merge. If it goes bad, let me know right away and I will come clean it up."

CS (00:32:04):

Nice. That is a great attitude about that. Yeah. Your position is like, "Look, we are going a million miles an hour. We have got an investor demo. We have something, and so we cannot quite do a full pair programming or have them sit down."

(00:32:19):

What I like to do there- Honestly, eight hours a day of pair programming is not typical. That is not even what I was saying. But if you really do not have that much bandwidth to do, then at a minimum, a bare minimum, what I say is that, "All right. You have a clear thing. Here is a ticket for you, new hire. Work on this thing."

(00:32:43):

And then what you do is you say, "I will meet with you every day for an hour." 9:00AM or whatever, have a regular time. "After 10:00AM, so 10:00AM to 5:00PM, you are working on your own."

(00:32:53):

"Here is the Slack channel to ask any questions. Here are the three people who you can bug about it. Here is the weekly team meeting about it. Come to the stand-ups." Invite them to all of that stuff so they are part of the team. "Here are the people to bug about it."

(00:33:07):

But they have a time limited window. "You have seven hours to work. Write down every question that you have, that you do not get answered for some reason. And then we will talk about it during tomorrow morning's one hour one-on-one. I expect you to have questions. I expect some of these things to be confusing. I expect you to write bugs. This is the way we learn."

(00:33:28):

What did you say a minute ago, Elecia? You said, "Ignorance is not their fault. It is their turn." I actually wrote that down because I love that. It is their turn to go through this process. This is the natural process. Yeah, I love that.

CW (00:33:42):

Hey, and all of us go through it every time we switch projects. Turns out, you may have more experience, but every time you are faced with a- If you come into a company or a project that has been going for a while, there is a lot of code. There is a lot of thought that has been put into it, design.

(00:33:58):

Every time it is like, "Wow, I do not understand this. I do not understand these choices. None of this makes sense." After six months of working on it, you are like, "Oh, this is how this works. This is why this was-" I think that is experience that we have over and over and over in our career. It is good to not only say, "It is your turn," but, "It is going to be your turn throughout your career."

EW (00:34:24):

Over and over again. Just get used to it. <laugh>

CS (00:34:27):

I love that, Chris. That did not even occur to me. But I am going to plus one that, and then say that the act of walking into something, being ignorant, being a beginner and figuring things out, that is a skill. That is a muscle, that is not an inborn trait. None of us are good at being beginners, out of the box.

(00:34:47):

Especially in the software engineering context, learning how to learn, learning how to onboard yourself, learning how to ask questions, that a skill. That, like you said, Chris, you are going to do that until you retire. And hopefully after you retire too, because hopefully you stay active learning new things as well.

(00:35:01):

I love that. That is an extra motivation for both your current team like, "Hey everybody, we can all remember that we have to learn how to learn." And so the new hire knows that, "Oh yeah, this frustration that I am feeling, that I will feel, this ignorance, this being lost feeling, that is expected."

(00:35:22):

Pushing through that literally develops the mental muscle of a skill, that will serve you for the rest of your career. Literally building mental muscle is not a grammatically accurate phrase, I do not think, but I am going to go with it.

EW (00:35:38):

I am reminded of a blog post I wrote that I am still very proud of, that is called "Resilience is a Skill." I do not know if you remember it, Svec.

CS (00:35:49):

The title rings a bell. I can imagine what it is about, but please go. What is it?

EW (00:35:55):

We had a listener write in about how they really were hating some of their non-technical classes. And were thinking about just- I do not remember entirely, but were thinking about dropping them and getting rid of school, because why did you have to take writing or business or whatever? Accounting?

(00:36:18):

My response was, "Yeah, you have to practice sitting there. You have to practice being resilient to the things that you do not want to do, to failing. This is an example of one of those times where you can though thoughtfully consider, "How do I make this palatable? How do I make this okay? I have to do it."

(00:36:43):

Do you make the effort to figure out how you would teach this better? Do you make the effort to just get through it, power through it, be done? How do you build the skill of going through, instead of constantly trying to go around whatever the problem is? Sometimes you just have to go through.

(00:37:08):

Whatever you use to push through, is a muscle. It is a skill that you build. It is not a one and done. It is like ignorance and learning. This is something you are going to have to continue to do. If you can make it easier for yourself, do so.

(00:37:29):

If you do not make it easier for yourself, at some point you will find an obstacle and there will not be a way around, and you will be stuck. And that is no good. So start taking on those obstacles as though they are learning experiences.

CS (00:37:45):

I love that. I love that. Yeah, that definitely rings a bell now. I remember reading that. But yeah, that is fantastic.

CW (00:37:53):

Before we move on, as a corollary to the ignorance thing and feeling lost, and maybe having the feeling like this is overwhelming, there is an instinct- I have it sometimes.

(00:38:03):

I think a lot of new people who come out of school and feel very smart, maybe they succeeded in school, they are in a company, they mistake that feeling of being lost or not understanding things for, "This has not been done right."

EW (00:38:19):

Ah. Yes. The story of the new college grad who suggested that maybe if the company made more revenue, it would be more successful.

CW (00:38:28):

Well, that is- What?

EW (00:38:31):

I do not know if it is apocryphal. It was a tweet. But yes, there was the story of the new college grad who was just like, "Well, why do not we just make more money, and then we will be more successful?" And everybody is looking at him like...

CW (00:38:45):

Yes. That is an extreme example. But I was thinking more of like, "This code is crap. I cannot understand it."

EW (00:38:50):

Right.

CW (00:38:51):

Or, mistaking a large project complexity for spaghetti code. Or-

(00:38:56):

Sometimes you are right. Sometimes after three years the code is not great. But that is what happens after three years of- I am going to use my favorite word. Accreting things and bug fixes and demands from management and changes and things. Code gets worse the longer it has been worked on, just in terms of-

EW (00:39:14):

Entropy is real.

CW (00:39:14):

Entropy is real. But that is a fact of development. We all have to fight against that.

(00:39:20):

But that does not mean you get to come in and mistake your, "Wow, this is hard to understand. I am lost," for, "We should just start over." Or, "You did a terrible job, you guys. I am the new smart kid." That is one way to make the senior people not help as much.

CS (00:39:39):

Well, that is not just for junior people. For any new hire onto a team, "The first thing, let us rewrite it in Rust. This is garbage. If only we would have done it the smart way. You people are dumb."

(00:39:50):

Hopefully as people get longer in their careers they- Maybe you cannot even learn this until you spent five years in a codebase that you have helped to accrete, to contribute to the accretion. I am not sure what the grammar is here.

(00:40:09):

But until you have been part of that, and you look back and you are like, "I am not a dumb person, but we are here because we are here. Rewriting the system is not something we can tackle today. So how do I make progress?" Maybe the progress is to rewrite part of it or to add modularity to some part of it or to encapsulate some part of it. That might be the right answer.

(00:40:28):

But usually the answer is not, "I am new here. I understand that you all are dumb, or that this is a dumb way to do things. Therefore, let us change it." That is never a good way to endear yourself to a team.

CW (00:40:40):

No, it is not. But it is a common defense mechanism.

EW (00:40:44):

I have felt that way. Yeah.

CW (00:40:44):

I have felt that way. I have even been right once or twice.

EW (00:40:47):

How do we feel that way, and still have imposter syndrome? This code is crap. I am crap.

CW (00:40:52):

Everything is crap.

EW (00:40:52):

I can rewrite it better.

CW (00:40:59):

Yeah. Well, I think part of the solution is to give people a sense that, "Yes, there are always problems in codebases. They are big. They are complex machines built by many people. Everything is a compromise."

(00:41:10):

"But while you are working in the code, try to leave things better than when you found them. That does not mean rewrite whole swaths. But if you see something while you are working on a bug that is not related to your bug, fix it. Open a new PR, open a new ticket for it. Take some initiative to, 'Oh, that looks like something that I could clean up. It does not have to be a big thing.'"

EW (00:41:31):

Pick up the litter.

CW (00:41:33):

Yeah, exactly. Pick up the litter where you see- Even if it is just a typo in a comment, anything like that, it can be done in a PR that has nothing to do with it because it is trivial.

(00:41:42):

Or if you see somebody, "Ope, they did not check null on this function." Throw that in there. Just add some extra checking, add some extra error handling, add some logging if you are missing it. Stuff like that is really helpful. That is pushing back at the entropy.

(00:41:59):

Instead of starting from scratch and building another complex system, which in five years you as the new person will be senior, and the new person will come in and say, "This is crap."

CS (00:42:12):

Well, it is funny because I have been at my new company for two years now. I just passed two years at Insulet. Coming in, I am not writing any of the code.

EW (00:42:21):

It has only been two years? Huh. It has only been two years?

CS (00:42:26):

It has only been- Yeah, it has been two years, two weeks ago or one week ago, or something like that. Time flies. But as the new- I am a director, so that is pretty senior. And I have been writing code for a long time. Now I am not writing code here, but I am trying to understand the code.

(00:42:41):

Coming in, there are a lot of things I see as a seasoned person saying, "Huh, why do we do that? I do not understand how we do that." And so instead of coming in and saying- "I do not understand why you are doing this," is not the same as, "This is dumb."

(00:42:53):

So if you are curious, instead of accusing, then that will help not make people mad. And it will actually help you learn the codebase faster.

(00:43:03):

So whether you are a new hire or someone who has been doing this for 20 years, come in and say, "Hey, I see that we are doing blah, blah, blah. How did we get here? Can someone explain?"

(00:43:13):

Normally there are going to be people who will say, "Oh my gosh, yeah. We do not like it like that, but here is how it used to be. Here is how we try to change it. And then we had to meet the deadline, and they changed the scope on us at the last minute. So we did it this way. And you know what? We should create a story. We should create a ticket to go fix that next quarter."

(00:43:37):

Okay. So you have not actually changed any code, but you have got the story behind it. You have got a little more of the history behind the team. You have been seen as somebody who is not accusing, but instead you are wanting to understand the code.

(00:43:49):

Maybe then you remind the team that, "Oh yeah, we could actually improve this thing in the future." And so you are not coming across as a know-it-all or someone who is hating on the new code. Instead you are, "Hey, help me get to know the code."

EW (00:44:02):

I feel like you two are both reading my PRs. One of them recently said, I was very clear, "I pushed 'needs modification,' not because I am unhappy with you or the code. It is because there is something we are not seeing eye to eye on. It may be me. So let us just talk about a couple of these issues."

(00:44:21):

Then there was another one where I was like, "You do not have to check null every time. If this is null, the whole file has just self-destructed."

CW (00:44:31):

Should have used Rust? <laugh> Sorry. Sorry.

CS (00:44:32):

Nice.

EW (00:44:36):

They are getter setters on what would be a class in C++. And so we pass- Never mind.

CS (00:44:43):

Yeah, that is a great learning opportunity, right? Because you come out of school, you are defensive. You do defensive programming meaning. And so yeah, that is fantastic.

EW (00:44:50):

"I can check null every single time."

CW (00:44:52):

At the entry to every function, I check all the memory spaces for null.

CS (00:44:58):

All the memory spaces. All the zeros.

CW (00:44:59):

I look through all of RAM and create a list of things that are zero, and then I log it to flash.

EW (00:45:08):

And now you are kidding.

CS (00:45:09):

If any byte is zero in all of RAM or flash, then I just assert.

EW (00:45:13):

You guys are just mean.

CW (00:45:15):

Yeah.

CS (00:45:15):

Well, my code has no bugs. There are no failures, because it does not run. So it is actually quite perfect. Do not do that.

(00:45:21):

I had something probably uniquely brilliant to say, but I just forgot. Forgotten with my stupid thought.

EW (00:45:29):

But I have something else.

CS (00:45:29):

Okay, please.

EW (00:45:30):

You are a director. You are not a manager anymore. You are managing managers. I want to be able to develop some of the people who have potential for management.

(00:45:43):

So what I wanted this podcast to be about, was not necessarily what we should do, either as new hires or as mentors for new college grads. But what we should be teaching our managers and our tech leads about how they should be handling new college grads.

(00:46:08):

You talked about have a buddy. Okay. Yes. We tell our new manager, "Make sure that the new person has a mentor. And it cannot be you, because you are in their management structure. So who do you want to be their buddy, who can balance your time and their time and blah, blah, blah?"

(00:46:27):

Do you have any advice for how to train a new manager to help a new college grad? This is sort of a meta question.

CS (00:46:42):

Yeah, yeah. You have gone up one level. Have them think through- So the point is not just getting one person from point A to point B. The point is how do we create a team that can onboard new people? How do we change the culture of our team, to be one that accepts new people, accepts ignorance, rewards curiosity?

(00:47:11):

So ask them like, "Hey, how do you think the team would do with a new hire who is ignorant? Who on the team could you trust to be a mentor?" And if the answer is, "No one," then, "What are you going to do about that?"

(00:47:28):

Stepping aside a little bit, as you talk about promoting people, you are associate software engineer or you are senior or you are staff or you are principal. One of the things that you usually need to demonstrate as you go up the ranks of seniority, is mentoring, is coaching, is helping others develop themselves.

(00:47:48):

So are you as a manager, or I guess make sure as a manager, that as you are thinking about, "Hmm. Is Jill, is she ready for the promotion to senior?" One of the things is, "Can she mentor?"

(00:48:00):

"Is she ready for promotion to principal? Can she mentor mentors? Has she demonstrated that?" And if the answer is, "No," then as a manager, your job is to give them that opportunity. Of mentoring, managing co-ops, interns, new hires, that kind of a thing.

(00:48:17):

That answers a small part of your question, Elecia. Not very much of it though.

EW (00:48:22):

You are giving them the opportunity. But you could give me the opportunity to fly a jet, and it would go badly.

CS (00:48:28):

<laugh>

EW (00:48:28):

You have to give them more than the opportunity. You have to give them the tools. And so my question is what are the tools that we can give to people, to help them be better mentors, better managers, better leaders?

CS (00:48:47):

Yeah. I wish I had a better set of tools. I have got a few books. I tend to learn from books. I love reading as a hobby, and I love reading about leadership, management, people, tech, all that kind of stuff.

EW (00:49:00):

So Camille Fournier's "Manager's Path." Yes. We recommend that one all the time.

CS (00:49:05):

100%. "Resilient Management" by Lara Hogan, which is L-A-R-A H-O-G-A-N. "Resilient Management" is an excellent book, that is about the human side of engineering management. Honestly, it pairs really well with "Manager's Path" by Camille. Those two books are my first things that I recommend.

(00:49:23):

I have learned this by osmosis, and by having a manager who demonstrated something. I do not have a specific tool set, other than having conversations like what we are having right now. Have these with your managers, have these with your mentors, have these like, "What do you think?"

(00:49:42):

We talked about building resilience as a skill. You need to face some pressure, and you need to face things you do not want to do, or you need to face the ignorance of something you do not know about, and you need to learn how to learn.

(00:49:57):

I think that with management, barring any really good training class or something like that, you need to present to your managers or to your staff, "Hey, how do you think we should onboard new people? How do we make curiosity a rewardable skill? How do we do these things?" By having people think through it on their own, they are going to own it more. They are going to have to think through it.

(00:50:19):

Then you can suggest a couple of books here, a couple of blogs. Go out into the internet, see what the internet has to say about it. They will probably come up with things you do not think about, and they will own it more. They will internalize it more, instead of like, "All right, Elecia gave me checklist. I guess I will follow the checklist."

(00:50:36):

But that is a little bit of a wishy-washy answer. If I had a really good training regimen, I would probably just suggest that.

EW (00:50:43):

Of course. Yes. "This training regimen works. Make it your own." Lacking that, ask them how they would go about it, and hope that the mental exercise of considering it gives them better tools than if they just went and did it.

(00:51:02):

That is true for most engineering. Do not just go off and write the code. Tell me how you are going to write the code. It does not really matter if I am listening at that point, because that process of telling me how you are going to do it, is what is going to build the actual good code.

CS (00:51:19):

Right. And then after you have done it, sit down- So you, the manager, sit down with them and say, "Okay, what did you do with a mentor or with a mentee or whatever?" And then, "How did that go?"

EW (00:51:27):

Yeah. I am not usually that direct. It is like, "Are you happy with that?" is as direct as I get on that, but yeah.

CS (00:51:34):

Sure. I guess I am thinking as a director, if I have a manager who works for me and then they have a new hire, every week in our weekly one-on-ones with the manager, I will say, "Hey, how is Jill doing? How is her progress? What have you given her? Who is her mentor? How is that going?" So you check in.

(00:51:52):

Then they will hopefully say, "Oh, actually they got distracted by doing X, Y, Z." "Okay, cool. So how are you handling that?" You are also trying to model to your managers, to your team, failing is just fine. Making mistakes. People are going to go off track.

(00:52:09):

Whether it is writing a bug in the code, or whether it is giving someone poor instruction. Or letting them go on their own too long without checking in, and finding out they were confused for a week without talking to anybody. "Okay. It is a learning opportunity. How do we not do that again?"

EW (00:52:24):

Yep. Do not get mad. It is just not worth it.

CW (00:52:27):

Get even. Nope. Sorry.

CS (00:52:28):

No, that is- Wait. What? No.

EW (00:52:33):

I do still wish I had a list. A book a month club of new college grads. "Here are the books. Here are the skills." I have seen the skills trees. That is okay, kind of.

CS (00:52:47):

"Pragmatic Programmer" is another book that has... I only read the older edition. I have not actually read the 20th anniversary edition. But "Pragmatic Programmer" had a lot of something like, "How to think like a senior engineer," kind of stuff.

(00:52:59):

I would be interested if listeners of the show, if they could- I am going to give you email now. But if people have seen anything that helps them think more along these lines. Whether it is a new manager, or whether it is how to manage new hires, or even the book club that new hires can go through. Is there a book that was particularly helpful? Yeah, those would be great.

(00:53:24):

Another book- Hang on, let me find it in my bookshelf. Where is it? It is called "A Philosophy of Software Design" by Jonathan... I cannot read it. John Ousterhout. We will find the link afterwards.

(00:53:37):

That book is a very philosophical book about software engineering, software architecture. It is very high level though. It is nothing super specific. The guy is, I think he is a Stanford professor, but he has also worked in industry some.

(00:53:53):

Having a new hire, new college grad or not, go through that with a team or with a few people, also gives you a chance to talk about, "Hey, what did you think about that? What did you agree with, or what did you disagree with?"

(00:54:05):

There are some of the more technical books like that, like "Pragmatic Programmer," or this "Philosophy of Software Design," that can give you some of the technical discussion that you might be able to learn with.

(00:54:17):

Joel Spolsky, who was a super, super prominent blogger and he actually was the co-founder of Stack Overflow. But he wrote a couple of books that were based on blog posts of his. It was written in the early 2000s. A lot of it is dated right now, just in terms of the thinking.

(00:54:34):

But he was very good at writing about how software should be developed. Those might make good book clubs just in terms of saying, "How should you organize your day? How should you keep distraction free? Why should you never rewrite a project or rewrite a piece of software, in a completely different language?"

(00:54:53):

His answers are not always correct. But they get people thinking about how to manage people, how to manage tech, how to do that kind of thing. So those are a couple suggestions. They may be good, they may be bad, but things that I have found helpful in the past, that might be good reading material, supplemental material.

EW (00:55:10):

For the skill side, I guess I am supposed to plug my book, but yeah, "Making Embedded Systems."

CS (00:55:19):

I will plug that a little more here. You did ask, I think, "Hey, what is a training program to get somebody from zero to five, from junior to senior?" And your book, "Making Embedded Systems, Second Edition" is a very good, broad and specific enough look at like, hey, if a new hire goes through that, they will be exposed to 90% of what we do every day in embedded systems.

(00:55:47):

Finding resources like that. Put someone through that. Have them do some little projects if you can. Put a cohort of people through that kind of a thing. You have done, was it Classpert, Elecia?

EW (00:55:59):

Yeah.

CS (00:55:59):

So you have literally put together that curriculum before. Would you recommend that for companies and for people to put their people through?

EW (00:56:07):

Well, Classpert is not doing new classes yet. I have been thinking about open sourcing some of that, but I am not ready yet. My book was definitely designed for that. "Okay, I know a little bit of hardware or a little bit of software. Now how do I become an engineer who thinks about design?" But in the short term, the skills trees are helpful.

(00:56:32):

Nathan Jones has "Embedded for Everyone," which goes through a whole bunch of different places that he has found things. It does not always have to be books. I like books. I agree with you. Reading for fun, reading for professional development, great.

(00:56:48):

But the repository for my book has a bunch of games. And I find myself really suggesting those to people who are not readers. You want to know more about assembly? Great. SHENZHEN I/O. You want to be a better typist? Typer Shark. Do not let, "I do not want to read," or "I find these things boring," hold you back, because there is probably a way to make it fun.

(00:57:18):

But yeah, there are so many good books, and it changes all the time. It is hard to suggest Spolsky. And "The Pragmatic Programmer," we went through it in the embedded.fm Slack recently. I kind of did not like the new edition. There were a lot of editions that... I do not know, maybe I just did not like it. I remember liking it before.

CS (00:57:46):

Yeah.

EW (00:57:46):

But I was not at a point in my career where I needed it.

CS (00:57:51):

Right. Right. It could be that the additions in the edition were not something you found helpful. You are just in a different place than you were 20 years ago or whatever.

EW (00:58:01):

Yeah.

CS (00:58:01):

These are true.

(00:58:06):

Oh yeah, I want to get back to one thing, because I wrote this down earlier. It was about the PRs thing we were talking about. So Elecia, sorry for going back to this, but you were saying that you would intentionally block a PR and you would say, "It is not because you are a bad person," but you would say, "It is because I want to address this question," or "It is because I want to do this thing." That is normal and that is fine.

(00:58:28):

Something that I would say I see teams falling into, is that they communicate only via typing in stuff to a PR.

EW (00:58:36):

That is not a good idea. No.

CS (00:58:37):

That is not a good idea. It is fine. It is very good to put your technical thoughts in there. But at some point, if you are like, "Hey, maybe I disagree with the way this is being implemented, or maybe I have more fundamental questions about this," just grab a quick meeting. Just grab a quick ad hoc, "Hey, can we have a Zoom call? Or can we get together in the office for 15 minutes?"

(00:58:55):

Because if I am just hammering at you with texts saying, "This looks like a bug. Have you thought about this? Have you though about that?" It is really easy for text communication to be understood as like, "I am being attacked. You think my code sucks. Therefore you think I suck."

(00:59:09):

Instead, all I am actually thinking is, "Hey, did you think about this? I am worried about the implementation because of blah, blah, blah." I can communicate that in a much more friendly way and less aggressive way by talking to you. Because you can hear me saying, "Did you think about this?" with a question mark at the end, instead of an accusation that you are a bad software engineer.

(00:59:27):

So if you find yourself thinking through or making a few too many, "What about this? What about that? I have a problem with this," jump on a call, grab a person in a conference room and just have a quick face-to-face. Because that is going to be so much less likely to be misconstrued as aggressive or negative, than anything in typing.

EW (00:59:49):

I do type chat a lot, but I will take it off the PR. I do it in whatever Slack or chat method we have, where I will be less formal and all that. But I recently did PR with a new college person and I shared my screen because I wanted to show what I meant, and they did not know about the files changed tab.

CS (01:00:20):

Hmm. There you go.

EW (01:00:21):

And it is like, "Oh, right. Why do I expect you to be able to-" There is a lot happening on the PR page.

CW (01:00:30):

The files change should be the second tab after conversation. I think they have got that wrong in the user interface.

EW (01:00:35):

Being able to just show that was enough for the person to go off and handle a whole bunch of things. And yeah, that would have been 9,000 back and forth types. It was basically 30 seconds of, "Oh, I did not even know that was there."

(01:00:57):

Which is the thing with the new college grads we need to be aware of, is there are going to be a lot of, "Oh, I did not know that was there," sorts of problems. Because they come in, for the first time they are learning about 401(k)s. They do not know what you do.

(01:01:16):

They do not know how to be in a professional team like this. They do not know how to necessarily understand that their skill level is not professional yet. And they can be intimidated easily.

(01:01:36):

Sometimes you just have to, "Okay, it does not really matter what is wrong. Let us just sit down and chat for a second." That approachability has always been really hard for me. <laugh>

CS (01:01:51):

Yeah. We are usually a bunch of introverts. We are not known for our dazzling social skills.

(01:01:56):

But yeah, that is a good reminder that yeah, you are coming in, you do not know all these things. And it is a good reminder. I always think it is funny when I am explaining something complicated to someone newer that like, oh my gosh, our industry, our field is so confusing. There are so many little tiny gotchas that are not obvious at all.

(01:02:18):

Like the UI on the PRs. Oh yeah, if you do not know that there is a second tab there that has these things, which is not exactly shouting out at you because by the way, you have never seen a PR interface like that before. It has got 4,000 visual elements on it. How do you know which ones to click on? But yeah, this is confusing stuff.

(01:02:36):

So it is humbling even as a senior person to realize, "Oh my gosh, I have learned a lot over the years. I have learned it because patient people showed me things along the way, or I have stumbled along things." So have that patience and grace for the newcomers who are showing up.

EW (01:02:54):

Chris, you had a question you wanted to come back to?

CW (01:02:59):

Mm-hmm. We have been talking about how to help new grads who are feeling ignorant or confused, or maybe confused that they are confused. Maybe they do not know that they do not know things. All that stuff. And preparing your team for that and all that stuff.

(01:03:14):

How do you prepare your team for new grads who come in and just are that good? They are right. They are not saying rewrite it in Rust. They are raising good points and arguing with senior people, and they are right.

(01:03:32):

This has happened once or twice in my experience. And I think it is more difficult to deal with, than the people who need a lot of handholding.

EW (01:03:43):

Why?

CW (01:03:44):

Because senior people do not like it.

EW (01:03:47):

That is not-

CW (01:03:49):

You can argue with the senior people. They are wrong, but it is a management problem.

EW (01:03:56):

Ahh. Yes. I have had a few of those folks. They are such a joy. The chaos they can create is just so fun!

CW (01:04:06):

<laugh> Okay. I see your answer is just to step back and laugh.

EW (01:04:11):

"Let us see how this plays out."

CS (01:04:14):

I think like anything else there, it is a balance. We try to be data driven as engineers. We lie and we tell ourselves that it is a meritocracy and we will always-

CW (01:04:26):

We are scientists, which we are not.

CS (01:04:27):

Scientists. That is right. We will always believe in the data. And-

CW (01:04:30):

<laugh>

CS (01:04:33):

We are not. We are not that analytical. We are not that unbiased.

CW (01:04:37):

There is an entire industry that has outsourced its work <laugh> to random number generators.

CS (01:04:44):

True. True, true, true. Yeah. Back when determinism was a thing, right? But. There is a coaching opportunity for the new hire to say, "Hey, let us remember everyone has biases. You are challenging them, you are challenging people's worldviews, which is fine. Can you identify what is the pain point and what does your idea solve?"

(01:05:10):

If people can agree that, "Hey, here is a pain point. Here is something that solves that pain," then that is the only way you are going to change minds. Then you get to say, "Let us say this person has a hundred ideas that are the absolute correct thing. Objectively, let us say everyone even agrees, 'These are the hundred things we need to change.' You cannot change a hundred things overnight."

(01:05:31):

There is an organization, a team, a codebase. There is a capacity for change, which is sort of intrinsic to the organization. Facebook has the famous phrase, I do not know if they use it anymore but, "Move fast and break things." So if you are in an organization that you live by the phrase, "Move fast and break things," then you can see a new hire being successful going in and ripping stuff up. And as long as they are not breaking too much, the mantra is break things. So that is perfectly fine.

(01:06:01):

If for instance, you work in an FDA regulated industry where breaking things means that you literally kill people, maybe you cannot do that. Maybe your organizational capacity for change is smaller, is lesser over a year. Because it takes more inertia, more checking. There are more horrible consequences if you get it wrong.

(01:06:21):

So as a leader, as a senior engineer on the team, as a new hire, everyone has work to do to understand what is the pain point? Does this solve the pain point? What is the right time to do a change like this, if ever? And how do we organize around that?

(01:06:38):

It is a lot of ego. That is all psychology and sociology and very little technology there. So that is the fun part about being a leader. If you are someone who thinks, "Ooh, that is an interesting challenge," then maybe you should be a manager.

(01:06:48):

If you are someone who is like, "Nope, I do not want to ever even have this conversation and I am physically uncomfortable listening to a podcast about it." Maybe you do not want to be a manager someday.

(01:06:58):

But that is the fun stuff. That is the stuff where it is like, "Okay, okay. Let us figure out how we can make this happen in a good and sustainable way."

EW (01:07:10):

To be slightly more serious, what that person, that super genius new kid, needs is the system level view that includes the people. What they need actually is management training.

CS (01:07:28):

Mm.

CW (01:07:30):

Oh, you are going to take some-

EW (01:07:33):

I am going to take your best shiny new genius kid, and I am going to make him into a manager. Is that not awful?

CW (01:07:40):

It is. I do not agree with it.

EW (01:07:41):

I do not-

CS (01:07:42):

I have two thoughts. I have two thoughts here. Two thoughts here. One is a something I forgot to add later. I actually put this in the outline, but I totally forgot it. Is that what I do with every new hire, whether they are manager, new college grad, whatever, is that- Insulet was already doing this when I got here, and I am definitely stealing this for the rest of my life.

(01:08:00):

But we make a list of who else your new hire should talk to in the company, and make sure it is a broad list of people within the engineering. Software, other software engineers. For the embedded software, the iOS software engineer, the Android software engineer. The systems engineers, the EEs, the MEs. The product managers, the program managers, the scrum masters.

(01:08:22):

Their job for their first month is to talk to these 18 people and to basically say, "What do you do here? Please tell me about your job. Tell me about your background. Tell me about what are the challenges? What is the hardest part about your job?"

(01:08:36):

What you are doing is two things. So Elecia, your talking about it is the people side of things kind of kicked me to remember this, is that you are meeting people, you are building relationships, you are learning who else you can talk to about things.

(01:08:47):

And you are learning that, "Oh, my little embedded software part of the company is 5% of what actually goes on here." You are building sort of the systems knowledge. Now you also can build the systems knowledge by actually learning how the entire system works.

(01:09:03):

But this is a good, easy on-ramp to, "Okay, here are the 18 people you got to talk to. You are going to learn something about 18 different people and systems and things along the way." So that is fantastic.

(01:09:17):

The second thing, I actually forgot we even had this at iRobot. This guy, Justin Shriver, fantastic engineer, fantastic engineering manager. He actually created a kind of a bootcamp. It was called "Tech Lead Bootcamp."

(01:09:31):

And Justin- I am trying to remember the agenda he had for it. But it was basically a two or three day thing, that was for people who wanted to be tech leads. It had a two hour session on what does a program manager do? How do schedules work? And then like, two hours on what does a test lead do? Two hours on what does a dev lead do? Two hours on what does actually getting a manufacturing build for the factory look like?

(01:09:59):

Basically it was a several day program on, "Here is an overview of what going through the whole life cycle of a program looks like." So people got a quick look at all of the different people and decisions and schedules and go, no go, conversations that mattered in a program.

(01:10:17):

That gave people the context for what it takes to actually ship software, besides just writing a bit of C code, updating a unit test and pushing it to Bitbucket. If that makes sense. So that is possible. I wish I had thought of that earlier today, because that answers some of the question here.

EW (01:10:34):

Because you could have looked at those slides, and just done this podcast yourself?

CS (01:10:37):

Exactly. I would have just sent those to you, and then no one would have to listen to me prattle on for an hour here.

EW (01:10:43):

You also had another thing in the list that we were going to talk about. That is to have each new hire add to "the stuff to know as a new hire" page. And edit it ruthlessly, so that you do not end up with a thousand little bits. But the new hires build the on-ramp for the next person.

CS (01:11:04):

Exactly, exactly. Because they are going to trip over all the stuff that was not clear from the last person, and they are going to hopefully fix it. That way it stays updated as your tools change, and as your instructions on how to get into Slack change. The new hire edits it.

(01:11:19):

Plus by encouraging them and really forcing them to edit this communal wiki page, or Confluence page or whatever you have, the documentation, it also gets them owning it more. They are not just a newcomer who is like, "I do not know what is going on," but instead they are helping to train the next person. That is ownership. That is empowerment. There is that word again.

(01:11:39):

That is engaging. Like, "Okay. I belong here. I am helping to make things better. Even if I have not committed the best new feature yet, I am helping myself and I am helping other new hires to get through this.

EW (01:11:52):

"Do you think new hires really need that much more praise than everybody else?

CS (01:12:01):

I do not think so. Honestly, I think we all... I do not want to be like, "Oh, everyone needs a trophy every 15 minutes." But I think that we all should think about thanking each other more, just in general and saying, "Hey, you did a really good job in that presentation. Hey, you did this. Hey, you did that."

(01:12:19):

Not in a performative way, not because I think you need praise. And if Elecia does not get 17 praises every week, she will be grumpy. But instead, looking around and thinking, I want to work in a place where good things are recognized.

(01:12:34):

When I see one of my people deliver a presentation that was really clear, I should tell them, "Hey, that was really clear. You took something that was confusing and you made it clear." Or, "Hey, that was a really insightful question." Just doing little things like that and having that become sort of a habit for everybody, there is no downside there.

(01:12:52):

Again, I am not saying this is performative, that you must do 17 of these a week, else your fragile ego will be crushed. Instead, I am saying I would rather work in a place where people are like, "Hey. Jill helped me this week. Shout out to her."

(01:13:05):

On some programs that we have internally here, we actually have a shout out channel. That is a channel that is dedicated to, "Shout out to Chris and Elecia. They went above and beyond this week and they did this thing." It can be a little thing. It can be a big thing, but it is normalizing the public thanking of each other.

CW (01:13:25):

<laugh> I am sorry. Reminds me of something from college-

EW (01:13:28):

Kudos. <laugh>

CW (01:13:28):

Where I was the Usenet administrator. I would create local Mudd.whatever groups on Usenet. Kids, if you do not know what Usenet was, look it up. It was something from the time of dinosaurs. Basically it was social media. We invented social media and then you all forgot about it.

EW (01:13:45):

<laugh>

(01:13:45):

Anyway, one of the groups we created was Mudd.flame, because you had to have a flame group for every top level group domain. So we had Mudd.flame and people used to argue and yell at each other and call each other names on that all the time.

(01:14:00):

One of the CS professors hated this. He could not stand it. And so he made me- God rest his soul, Professor Keller. He made me create an alternate group called Mudd.kudos where people could say nice things about each other.

(01:14:17):

At the time, we all though this was ridiculous. And it was ridiculous. Now I have more sympathy toward the notion, toward the impulse there. But Mudd.kudos was empty.

(01:14:32):

Which only made it worse.

CW (01:14:33):

Nobody ever posted on Mudd.kudos. Anyway, that just reminded me of that, the Slack kudos group, which I think is a good idea. I think people in companies would use it more. People in a college probably would not respond to it as well.

CS (01:14:47):

Yeah. That is kind of tough. At iRobot, we had a kudos thing in Slack. One of our tools team people created it. Basically it was a Slack command, where you could just like Slack, you could give someone kudos. You would say, "Kudos to Chris for doing X, Y, Z." We could argue whether this was good or not, but what that would do then is that would increment your kudos.

CW (01:15:09):

Oh no, no, no, no, no. No ma'am.

EW (01:15:11):

You cannot make it a competition.

CW (01:15:12):

You cannot have MeowMeowBeenz. No MeowMeowBeenz.

EW (01:15:14):

<laugh>

CS (01:15:15):

But the thing about the MeowMeowBeenz, somehow it actually worked. In this culture, we ran it for a number of years. Now the company went bankrupt. Pretty sure those were not related.

CW (01:15:23):

<laugh> Sure, that were not related. Sure.

CS (01:15:27):

But it actually worked. What ended up happening is the few people at the top of the pyramid, you were like, "Those really are the most helpful people." I remember who those humans are. John Dorich, for instance. Oh my gosh, that guy was super smart and he was always helping everybody. He deservedly was at the top of the kudos list because darn it, he was that helpful.

(01:15:52):

By elevating that behavior, I think we helped encourage the culture to be one of helping. We did not give raises based on it. No one was penalized if they did not get enough kudos, that kind of a thing. We internally, I think, handled it well. The culture was coming from a good place anyway.

(01:16:08):

And I could absolutely see that being weaponized and being a horrible, horrible thing. So I...

(01:16:15):

So the people on the top of the list did not get their own conference room, and did not get to sit in there and drink out of goblets while wearing togas?

(01:16:22):

Not that I know of. No.

CW (01:16:24):

That is probably fun. We will link to the episode in question that I am referring to, of a show that-

CS (01:16:30):

"Community." Good show.

EW (01:16:32):

Yeah. I wrote down "MeowMeowBeenz."

CS (01:16:33):

I did not expect Usenet or MeowMeowBeenz to come up on this show. But flame wars, people were bad to each other on the internet before-

CW (01:16:42):

People were bad to each other on the internet, the instant the internet occurred.

CS (01:16:46):

It is true.

CW (01:16:46):

It is just the way we are.

CS (01:16:48):

It is true. People are also wonderful to each other on the internet sometimes. Like in the embedded.fm podcast-like group.

CW (01:16:54):

Occasionally.

EW (01:16:58):

Pretty good place. I am happy with it.

CS (01:17:00):

It is a pretty good place. I remember when you started it publicly, I was thinking like, "Ooh, how is this going to go? A bunch of randos on the internet." But it is actually perhaps uniformly just a good place for people to ask questions, express ignorance and get questions answered and kind of have a good time.

(01:17:16):

You got some cute pictures of dogs on there sometimes too. It is kind of a win-win.

EW (01:17:21):

Svec, you are employed at Insulet, and you are thinking about doing a little bit of side consulting.

CS (01:17:30):

Yeah. Yeah. Thanks for that wonderful plug for me. But yeah, I have done some leadership and management consulting for smaller companies, for medium companies, just for individuals. As hopefully you can tell by this podcast episode, I love thinking about this stuff.

(01:17:47):

Again, the psychology and the sociology of teams and getting them to think better. Getting your particular team to figure out the context of how you can be more effective, more whatever, is something that I have really gotten more excited about and got more interested in, especially in the last five to ten years.

(01:18:06):

I have worked with a couple of companies. I am working with a couple of companies, doing a little bit of coaching. Whether you call it leadership consulting or leadership or management coaching, words that kind of describe the same thing.

(01:18:18):

But if you are interested in having a thought partner, even just like a rubber duck to bounce things off of to someone who has- Obviously I do not know you, I do not know your company. But someone to bounce things off of and give you some ideas and just talk about things with, reach out to me.

(01:18:33):

I love having these conversations. I love helping people. I have made enough mistakes that I have learned a few things. I always have more to learn. We all do. And if you are interested in having these conversations for yourself in your career or for your company or group, please reach out to me. I would love to talk.

(01:18:51):

Get in touch with me at svec@chrissvec.com. The spelling of that will be in the show notes. Svec is just S-V-E-C. It is a terrible name, but at least it is pretty unique.

EW (01:19:05):

It is a good name.

CW (01:19:05):

It is fine.

CS (01:19:08):

It is a fine name, but I have to spell it every time I ever say it. So it is awful.

EW (01:19:11):

Oh yeah. Complain to me about how your name is spelled.

CS (01:19:15):

What is that? "Eleshah" or "Elesher"?

EW (01:19:19):

"Alekia" is one of my favorite mispronouncements.

CS (01:19:22):

Alekia. I want to start calling you that. I think every guest who comes to the show needs to call you Alekia.

EW (01:19:26):

Feel free to call me Elle.

CW (01:19:27):

It is the ancient Greek pronunciation.

CS (01:19:29):

Alekia.

CW (01:19:31):

Or the Sindarin.

EW (01:19:34):

Svec, do you have any thoughts you would like to leave us with?

CS (01:19:36):

Just to recap the thing I have said a few times here, is admitting ignorance publicly is literally a superpower. If you can do that, especially if you are a senior, especially if you are someone in a position of influence, authority, power, whatever in your company.

(01:19:50):

Being seen as someone who can say, "Huh, I do not get that. I do not understand that. Can you please explain it to me?" That will help encourage everyone to see that, "Oh, we all got to be learning. We all got to be admitting it. Totally fine to not know something." Because if you do not admit you do not know something, you will never learn it.

(01:20:09):

So that is my spiel there.

EW (01:20:14):

Our guest has been Chris Svec, Director of Embedded Software at Insulet. He does some management leader coaching consulting. If you want to talk to him, it is svec@chrissvec.com. We will not have a link in the show notes, but if you contact us, I can pass it along.

CW (01:20:34):

Thank you, Chris, for joining us again. It was lovely to talk to you.

CS (01:20:39):

Yeah, thanks. Always fun. Always fun. Thank you both.

EW (01:20:43):

Also, thank you for filling in at the last minute.

CS (01:20:46):

Oh, I did not realize I was a felon. Well, in that case, I take it all back.

EW (01:20:49):

All right then.

CW (01:20:50):

A felon?

CS (01:20:50):

A felon. A fill in?

EW (01:20:53):

At least he is finally admitting it.

CS (01:20:56):

<laugh> It is court ordered.

EW (01:20:57):

Thank you to Christopher for producing and co-hosting. Thank you to our Patreon Slack group for, I do not know, being kind of cool. Thank you for listening. You can always contact us at show@embedded.fm or hit the contact link on embedded.fm.

(01:21:14):

And now a quote to leave you with. This one is kind of long. "I could have become a mass murderer after I hacked my governor module. But then I realized I could access the combined feed of entertainment channels carried on the company satellites. It had been well over 35,000 hours or so since then, while still not much murdering, but probably, I do not know, a little under 35,000 hours of movies, serials, books, plays, and music consumed. As a heartless killing machine, I was a terrible failure."

(01:21:46):

That is from Martha Wells' "All Systems Red." She was on the show and of course we did not talk much about technology. Just about fun.