78: Happy Cows
Transcript from 78: Happy Cows with Christopher Svec, Elecia White, and Christopher White.
EW (00:00:06):
Welcome to Embedded, the show for people who love gadgets. I'm Elecia White, back with my co-host Christopher White. Our guests this week is Chris Svec. And we're going to talk about Empathy-Driven Development. Before we explain that, could I ask you for a tiny, tiny favor to listeners? It was my birthday recently. So if you want, you can consider it a gift to me. I'm totally fine with that. But if you could please go to iTunes and give us some stars, it would be awesome,
CW (00:00:37):
And I promise I'll stop asking soon.
EW (00:00:39):
Or at least put it back at the end of the show. So now back to the fun. Having two Chrises on the show shouldn't be confusing at all.
CW (00:00:48):
Hi, Chris two. This is Chris one, like there's no meaning behind the ordering there. Sorry. Thanks for being on the show.
CS (00:00:55):
Thanks Chris. Wait, is that T-O-O or T-W-O? I'm not even sure anymore.
CW (00:00:59):
I think we should just leave that behind.
CS (00:01:01):
All right. Excellent. Excellent. This is what you and I have grown up with. So we're used to it.
EW (00:01:06):
Could you tell us a bit about yourself?
CS (00:01:09):
Sure. Being a Chris, which sums up a lot, I'm an embedded software engineer. I work for iRobot right now and I work on the home robots. So I actually work on the next generation Roomba vacuum cleaning robot that you may have seen a bunch of commercials for recently. But yeah, I'm an embedded software engineer. I started on the EE side. I used to design chips and for Intel and AMD and I sort of moved up the hardware stack to actually, you know, designing the chips at first and then writing software that ran internal to the chips. And now I write software that simply runs on the chips and I am a mere consumer of the chips. So yeah, that's kinda EE to software.
CW (00:01:50):
Not an unusual path.
CS (00:01:53):
Yeah. I work with a bunch of people who, you know, followed similar chip company to software company.
EW (00:01:58):
I've always wanted to know about iRobot. And my big question is, do you actually test with cats?
CS (00:02:06):
We test at home. I mean, like, we send robots home with our employees, of course, for internal stuff. And so, yeah. You know, cats, kids, dogs, whatever you got. Although I do have to say we enjoy the YouTube cat videos at work quite a bit.
EW (00:02:22):
I like the ones where the cat is like bopping the dog whenever the vacuum cleaner goes by. Those are my favorite.
CS (00:02:28):
Yeah. I feel bad for the dog, but those are really funny.
EW (00:02:34):
So when we started talking about doing a podcast, you had an idea, you called it Empathy-Driven Development, which, is that where you start giving emotions to the vacuum cleaners?
CS (00:02:46):
That's maybe the next few years, yeah. Shortly before they take over. That's what we're doing. No, no, no.
CW (00:02:53):
Look what you designed me to do, how could you do this to me?
CS (00:02:56):
Exactly.
EW (00:02:56):
Thou shalt not kill humans.
CW (00:02:57):
I suck dirt off the floor for a living.
CS (00:03:00):
There's a great, what is it, it's called? Oh, shoot. I'll have to, we'll put it in the show notes, maybe. There's...somebody has a, I think it's...self-aware Roomba is the name of the Twitter account. And it's basically a very depressed Roomba who goes around all day. Apparently it's self-aware. I'm sure our company doesn't sanction it, but it's still pretty funny. Anyway.
EW (00:03:24):
Empathy-Driven Development.
CW (00:03:25):
The reason that I'm here.
CS (00:03:28):
Yes, Empathy-Driven Development is just something I've been kind of...it's been cooking around in my head for a while and it's just kind of crystallized in the last six months. It's a way of trying to bring empathy into engineering, specifically software engineering. There's plenty of talk in our field and the overall field about having empathy for the customer, empathy for the end user. And especially like, the design community is really big about this. The web community is pretty big about this. In the embedded world, I haven't seen as much of that.
CS (00:03:56):
And then within a software development team, when I say embedded, when I say Empathy-Driven Development, what I mean is that we should have empathy as software engineers, to other software engineers, to the people who will take over our code when we move on or to the new hire, who's just getting hired into your team. Who's, you know, straight out of college, they're smart, they're bright, they're motivated, but they don't have 10 years of experience working in the code that you're working with. So you want to have empathy for them.
CS (00:04:26):
It's also the notion that you should have empathy for your future self, where, you know, I'm going to write some code and a year from now, I'm going to find a bug and I'm going to wonder what fool wrote this code in this foolish way. And I'm going to do, you know, a SVN blame or whatever version control tool you like, I'm going to blame.
CS (00:04:43):
And I'm gonna realize that fool was me and I'm gonna, you know, you're going to feel bad for yourself. You're gonna think about, "Why didn't I leave myself some breadcrumbs? Why didn't I document this better? Why didn't I make this clearer?" So it's the whole thing of being, empathy towards other software engineers, new hires, or experienced people and also your future self. So that's a longer description than I wanted, but that's kind of it.
EW (00:05:04):
I mean, that makes sense. It's, I do hear about empathy towards your users and I strongly believe that because why would you not be nice to your users, but this idea of being nice to your coworkers? I don't know. I don't think that's how engineering is done.
CW (00:05:23):
Well, it's not just coworkers, it's coworkers you may never meet.
EW (00:05:27):
Yeah.
CW (00:05:27):
Or people who follow you. I think it's a fascinating idea. And you know, when I read the description before the show, it sort of struck me, "Oh yeah".
EW (00:05:37):
Like, "of course you should be doing it?"
CW (00:05:38):
Of course people should be doing that. And then I started thinking about, in my career and what things that I had done that go contrary to that and things I've seen other people do that are contrary to that, even to the point of making it a point of pride, you know? Oh, well, the next guy is going to have fun with this or, or the reverse. Well, the guy before me wrote this code, well, I don't know who that was. It wasn't, must not be very good so I'll just throw it out.
EW (00:06:04):
Just throw it out.
CS (00:06:04):
Right, right.
CW (00:06:04):
And I think we're all guilty of that. So it's fascinating to me that somebody's actually -
EW (00:06:09):
Talking about it?
CW (00:06:09):
Come to the realization that that's a bad thing, because yeah, it should be a bad thing.
CS (00:06:15):
Yeah, you definitely, I mean, you know, it's Empathy-Driven Development. I sort of named it that. I just needed a, you know, hat hook to hold something, to hold the concept on. But, you know, it's almost something that shouldn't be capitalized. It's pretty general, right? I mean, like you both said, like I've said, you know, the user experience community certainly is all that empathy. But yeah, you should...definitely have empathy for, you know, the person who's using your product. They're not a software engineer. You can't expect them to know how it works, but you should also expect the 22-year-old who just graduated college to not know how your software is designed and you should expect, you know...
CS (00:06:48):
I'm someone, I've been at iRobot for about a year now and I'm a pretty experienced person. I worked for 12 years, 13 years. But when you're the new person on a project or at a company, you know, you don't have five, 10 years of kind of the context that everyone else has. And so being the new guy on the block, I think also helped kind of kick my thinking to this. And it kind of plays into something that I remember Jack Ganssle said, I think when he was on this show which was basically being professionals. And I think that was his concept, right?
EW (00:07:21):
Yes, definitely.
CW (00:07:22):
Yeah. Being a grown-up.
CS (00:07:23):
Being a grown-up. Yeah. And so being a grown-up means treating those around you like grown-ups and being professional towards them and leaving breadcrumbs for them. And, you know, not just being a jerk and, you know, leaving impossible to maintain code behind while you go away.
EW (00:07:37):
Well, empathy is putting yourself in someone else's shoes and looking around to see how it looks there. And we've all been that new guy or girl, woman, why am I the person having trouble with that? Anyway, we've all been that, that new person-
CS (00:07:54):
'Cause Chris and I just avoid it because we're scared of it.
EW (00:07:55):
So it makes a lot of sense. You know, you should be nice to them, but why aren't we? So why isn't this "Well, duh, of course we should all be good, nice people, understanding of other people's newness and forgetfulness and humanness"? Why aren't we doing this?
CS (00:08:22):
I think...it's more than just being nice. I think a lot of it is, well, first of all, you know, in the tech community, right, we sort of have very, unfortunately, sort of praised the lone hero, like the firefighter who can single-handedly, you know, we write the code over a weekend and no one else can understand it, but man, that stuff works and, you know, whoever it is, that hacker she's awesome.
CS (00:08:47):
She went off, she hacked this thing together and it is an absolutely genius piece of software that no one else can even approach. And that's kind of, I don't want to say that's our role model, but that's certainly our, that's kind of our ethos. Or that's kind of our...I dunno, that's what we have a history of praising, I feel like, and that used to work, I think 10, 20, 30 years ago when software systems and any systems were smaller. And you could get by with a team of one to three really smart people, and maybe you didn't need to communicate or really, you know, pass the baton back and forth between programmers 'cause maybe a software project was, didn't have to be as big or complicated.
CS (00:09:27):
But, I think something that, you know, the longer, certainly the chips projects, the chip projects I worked at at AMD, we had like 300 people working on some of those projects or 200 people working on some of those projects. So to do meaningful work nowadays, takes more and more people, more and more communication. And I think we need to let go of the old lone hacker geek in her bedroom, hacking away something that's genius and sort of realize that, "Hey, we're a team here. We need to work together. We can work together and actually have more fun and enjoy our jobs more if we sort of use empathy in...writing our code and dealing with each other".
EW (00:10:06):
So you have two ideas there. And I totally agree about the empathy, but I admit that I got into engineering 'cause I was a bit of a loner.
CS (00:10:17):
Mhmm. Mhmm. [Affirmative]
EW (00:10:17):
And I have found the teams to be difficult sometimes. I've gotten a lot better over my career, but in the beginning it was a little off-putting to have to work in such large teams. And if I hadn't been building such neat things, I would've left. 'Cause it just, all this communication and having to worry about people's feelings, it was difficult to learn.
CW (00:10:44):
Well, I wonder if it's a product of our education, because when we're going through school, in college, and learning, you know, the tools that would become the skills that we need for these jobs, we're competing against other people, at least academically, right? It's like, well, you know, there's a curve, we're being graded. We are kind of working together, but everybody's working on their own project, their own personal project, which is their own education.
CW (00:11:13):
And then you're dumped from that straight into, okay, now you're in a company with a team and you're smart and other people are smart and everybody's still trying to prove that they're smart. And there's not really a bright shift, bright-line shift between one mentality and the other. And so you end up with the rock star mentality, which is the word I've heard thrown around at all the jobs I've ever been at when we've been hiring people. Oh, so-and-so's a rock star.
EW (00:11:37):
I only want green M&M's.
CW (00:11:38):
No red M&M's, yeah.
CS (00:11:44):
That's interesting. That's interesting. I had not considered sort of the, you know, coming out of college, coming out of university. And yeah, there definitely is the, you know, you're on own. You work on a team, but your grade is your own, your education is your project. That's an interesting history or genealogy of that. It's interesting.
EW (00:12:02):
But we went to a school with a lot of study groups and we had a lot of group projects. I didn't really participate in the study groups 'cause see part where I said "loner".
CW (00:12:10):
One or two group projects, but they were -
EW (00:12:14):
Yeah, I guess even clinic was still very -
CW (00:12:17):
You didn't have a lot of experience. And you were thrown together with people who were random, just -
EW (00:12:22):
With different skill sets.
CW (00:12:23):
You still were working on your own thing. And even within those groups, your grade was your grade, right?
EW (00:12:28):
That's true.
CW (00:12:29):
To a certain extent. Yes. It was a team project, but other people could sink you. And it wouldn't be like at a company where if somebody's doing poorly on a project, you try to step up and "okay, we need to get this done". It would be, you're going to ruin my grade.
EW (00:12:45):
And actually that made the rock star syndrome worse for me, the times that I worked on a group project and someone slacked off. And so I worked really hard in order to make sure that we at least met the bare minimum across.
CW (00:12:59):
Right.
EW (00:13:01):
And so I did the overnight hack it together and hope that it all works out. So, yeah. I'm sorry, Chris, I interrupted you. You were starting to talk about university and college and -
CS (00:13:15):
Oh no, no. I was just saying that that's interesting. I hadn't gone there. I hadn't considered kind of, it is a change. I wonder if another change is also, in college, you generally start from scratch on every new project, every class, every homework, you're starting over. You're not being thrust into some piece of software that's been alive for 10 years with a team.
CS (00:13:33):
You know, maybe if you're a freshman and you get put on a team of seniors, who've been working on a project for three or four years, maybe that would kind of simulate more of the whole, this project is bigger than you. It's bigger than your A or B at the end of the semester. Whereas, you go into the working world and you know, you're working with people, who've started this system before you were born, maybe, depending on what you're doing, or at the very least had been working on the software for 5, 10 years and you are thrust into the middle of it.
CS (00:14:02):
So you have a starting point. You're not starting with a blank slate, but you also are starting with a bunch of assumptions that you just don't have a clue about. So I wonder if there's some way to kind of tie more of that into a university. I know that some universities are starting to do projects where you, you know, you get in and you're part of some bigger project your whole four years or your whole time there. And you're working with juniors, seniors, freshmen, sophomore. So there is kind of more of this life cycle to it. I wonder if that sort of more holistic sort of a project helps people avoid some of that rock star mentality and helps people, you know, feel like, "Oh, we're in this together" and know how to work in a team. I don't know. I'm just thinking out loud here.
CW (00:14:40):
Certainly understanding and getting a sense of a history of a project -
EW (00:14:43):
Even how to use version control in order to figure out what's going on.
CW (00:14:47):
Well, yeah.
EW (00:14:47):
We had like one class where we had a six-month-long project and you had to do version control or you really regretted it. But that was it. I mean, there wasn't a lot more that was important for continuity and six months, you can remember what you were doing for the whole six months...
EW (00:15:04):
One of the things about the Empathy-Driven Development that I liked was empathy for yourself in the future. I often write the comments for me in a year, who's forgotten this and is really tired. And so I, you know, I try to put in enough detail to describe stuff, but not so much that it's overwhelming. So, yeah. You mentioned offline about imposter syndrome. We did a show about that, but it was like seven years ago in dog years. So, you know, there's a lot of women in tech conversations about imposter syndrome, but that's not the only place it exists.
CS (00:15:51):
No, no, no. And in fact, when I started doing this talk, when I started kind of pulling together what ended up being a talk, at iRobot, you know, about this Empathy-Driven Development, I started realizing that this is not, you know, I'm, again, I'm not trying to create some methodology or anything like that. I'm just trying to sort of get us all thinking about each other, quite frankly, like, communication 101 is empathy, and how can we sort of relate to each other better? How can we relate to this, again, the 22-year-old coming out of college who was in a dog-eat-dog world, how can we relate to them not knowing about version control? How can we do all this kind of stuff?
CS (00:16:26):
I thought, well, part of the problem is that we have kind of, some of us have some defense, we're kind of defensive. We feel insecure. We feel imposter syndrome. And as I started talking about that around the office, I realized that a lot of people had it. And it was interesting. I gave a talk to 60 software engineers at iRobot and I put a slide up there that just had imposter syndrome on there. And a couple of people just like raise their hands right off the bat, like before I said anything. And I said, "Alright, well, who here knows what it is and admits to having it?". And a bunch of people raised their hand. And I said, "okay, you know, here's what imposter syndrome is, it's basically feeling like you're a fraud". And I would say about two-thirds of the people in the room raised their hands and that's well, because of the, you know, we have a reasonable percentage of women at iRobot, but it's still more men than women. So two-thirds of the room raised their hands. So that's men and women.
CW (00:17:18):
Yeah, that's definitely, I mean, my personal experience, anecdotally, you know, I've often felt that way. And I think what you said early on in your description, you know, the defensiveness, it's both wanting to be that rock star and being afraid that you're not.
EW (00:17:37):
And that you never will be. That you never were.
CW (00:17:39):
That you never will be. And so I think it's sort of a toxic thing that seeps into how you work and maybe how you write code and maybe how you approach the next person, because yeah your insecurities flow into all the kinds of decisions you make, sometimes. And I think getting over that, I think is an important step in getting to what you're saying about being more empathetic.
CS (00:18:06):
Yep. Yep. And I think just admitting that, "Hey, you know what, I'm not perfect". And I remember one on the women who raised her hand. She is probably one of the best software developers I've ever worked with. And she has worked on the systems that, the robots for a long time, she knows everything and she's super easy to work with. And when I saw her saying, "Oh, she feels like that. I'm kinda like, how, how can you, how can you think that? Like, you're awesome." She's like, "I don't think so."
CS (00:18:30):
And so, I mean, just realizing it's everywhere, I think is an important first step for all of us to realize, "Hey, we're human, we screw up. We don't know something." We assume that everyone else knows more than us. Like we assume that, I have a slide in the talk, and I've seen on the web, other places, where we assume that like, we know some amount of information and everyone else knows what we know plus a ton more, right?
CS (00:18:52):
And this is part of the whole insecurity thing. And then the truth is that I know a bunch of stuff and you know a bunch of stuff and, you know, everyone knows a bunch of stuff and we're all coming at it from different angles 'cause you used to work at a hardware startup and you used to work at, you know, Dell, some, you know, a huge company and you used to work in this other company and you are fresh out of college.
CS (00:19:11):
And so you have, you know, you have the youth that me and my 37-year-old self don't, you know, don't have quite a finger on the pulse of that 22-year-old anymore. So we all come to the table with different skills and experiences and like, we just need to not undervalue what we bring to the table and realize that everyone brings something of value.
CS (00:19:33):
And this is getting a little more touchy-feely than I really wanted to, but it is realizing we're all human and we can embrace that and make our software better, more maintainable. Make it easier to work with, easier to jump in as the new person. And also just more enjoyable to work on yourself. If someone else has taken the time to document their code well, or to, you know, make it easy, to jump into the new code, you're going to enjoy your job more.
CS (00:19:59):
And, you know, I spend too many hours at my job every day away from my family and my home and, you know, doing whatever else, that I want to enjoy my job. I don't want to, you know, go into work and be like, "Oh, I've got to touch this code that I'm scared of, that, you know, is just going to break all around me if I even look at it wrong. I want to be able to just walk in and just enjoy my job every day. And I think having empathy for my colleagues, having this kind of real, we're all real here mindset can help that.
CS (00:20:29):
And as I've talked about this in my job and other people have kind of picked up on it and people will now... I see it actually having some small benefits over the weeks and months since I've started talking about this, at iRobot anyway, of people, you know, being a little more open with each other, people talking about empathy, and it's not just a buzzword. It's not just, you know, this touchy-feely, feel-goodery kind of stuff. But this is like I said, communication, basic communications.
EW (00:20:53):
So, okay. Basic communications, but what do you want us to do with Empathy-Driven Development? What, tactically, how is it going to change my day tomorrow?
CS (00:21:08):
Yes, that is maybe in my next talk...what it really boils down to is, I think at first, if we admit that this is something that can be good, that it's good to think about who is going to be consuming your code. And maybe that's an end user in the products standpoint, but the person consuming a code is your fellow software engineer. So step one is just realizing that. Step two, like you said, empathy is putting yourself in someone else's shoes.
CS (00:21:40):
So when you finish up a function and when you're, before you check in your code tomorrow, or before you, you know, think about starting a design, stop and think, "Alright, who else is going to have to work on this? So in the case of a function that you're about to check in, you're making some sort of a bug fix, and you could just check in the bug and just, you know, you fixed the four lines that are required or whatever.
CS (00:22:02):
And you could just check it in and close the bug and be done. Or you could write a little bit in the comment for the bug or in...your bug tracking system or in the code itself, or what was actually the cause of the bug and you know, how you could fix it or how you did fix it. Or maybe even what future problems do you think it might cause, but you didn't have time to fix today because, you know, we needed to get this in for shipping the next round of the product or whatever it is. So that's just off the top of my head, an example of something you can do.
CW (00:22:36):
Well, I think you can codify certain actions. You can say, you have to run a static checker on your code before you commit it. You have to run these build check scripts. You have to do certain things so that you don't, at least in the very short term, make things worse for other people.
CW (00:22:51):
I mean, I don't know what we're talking about long-term, sort of the next developer, or at least your colleague who might see your code in weeks or months, but, you know, there's ways to screw up the code right now for everybody else and ruin their weekend, that can be made a little bit easier by saying here's a process for making sure that you're not doing something that's going to harm somebody else. And maybe it's code that, you know, another team needs for a different project that you could hold up and isn't important to you necessarily right now, but it might be very important to them.
CW (00:23:25):
The thing I also wanted to kind of touch on was that I could see imposter syndrome and this sort of mixing together. And maybe this is a personal problem, but turning into sort of fear-driven development, where I'm kind of paralyzed by, "Oh, God, I don't want to touch this code because I might make it bad for the next person, or I might make a mistake that affects the next person or affects this other group." And I actually find myself doing that sometimes, you know, depending on which area of code I'm in, "Wow, I am being really careful." And I know it's a good thing, but the emotion I'm feeling is not necessarily warm feelings to the next person, it's...
CS (00:24:10):
Are you a perfectionist by any chance?
CW (00:24:12):
You'd have to ask the other host.
EW (00:24:17):
Sometimes, definitely sometimes. And you know, it depends on what we're working on. I know iRobot has more than vacuum and home robots. They have the bomb disposal robots. And if I was working on the software for that, I don't know if I would care as much about my next person being happy, that I would care about their shoes being good so much as making sure that my robot worked and that I was not afraid at any point that I was going to make my code break.
EW (00:24:53):
And so I can see what my Christopher is saying, that there is an element of don't screw up, even with Empathy-Driven Development that you have to make sure you can, I don't want to say justify our actions, 'cause that seems wrong. But have this awareness of, there are multiple masters in software. You're working towards shipping on time, shipping a product. You're proud of shipping a product that consumers want, shipping a product that has good code that future people can live with, my colleagues. And I, you know, usually I have this pyramid of cost and time and features. And where are you on this pyramid? And now if I add another corner, that's, I don't know, that's empathy? That doesn't quite work.
CW (00:25:53):
Well, you could break it down to common terms like maintainability.
EW (00:25:56):
Yes.
CW (00:25:56):
Testability.
EW (00:25:56):
Reusability.
CW (00:25:59):
Reusability. These are all things that we use as terms in software design that are sort of vague, but I think, you know, implementing those and making sure you understand what those mean and designing your software in such a way that it is extensible. It is maintainable, reusable. That does make it easier for the next person. And that's at a higher level than just your day -to-day pounding on a keyboard, but -
EW (00:26:24):
And if you could do that with empathy in mind.
CW (00:26:27):
Right.
EW (00:26:28):
Then I think that would be better. If you just had the directive to make your code reusable, that is not as good as make it reusable -
CS (00:26:38):
Because -
EW (00:26:38):
Because of empathy.
CS (00:26:40):
Yeah. Right. And well, and make it reusable specifically with the new hire from, new grad from college, make it, you know, make it so that someone who does not know that the system architecture looks like this, 'cause of course, everyone knows that the system architecture looks like this because everyone's worked here for 10 years.
CS (00:26:56):
You know, I think empathy is actually, one of questions, Elecia, that you asked me beforehand was, you know, Empathy-Driven Development, is that like another, you know, Capital M methodology, just like Agile or Test-Driven Development or something like that. And I don't, it's definitely not anything like that.
CS (00:27:14):
Frankly, I think the concept of empathy sort of scales very well through any of the three legs of the triangle that you're talking about and sort of anything we do. And if we can get comfortable thinking, alright, who's going to have to use what I'm working on that can help us make it more reliable or more maintainable or more usable, or, you know, especially with, like you're saying the bomb-disposing robot, or, you know, someone who's writing code for a pacemaker, you know, you have your empathy, what will sort of be more for the end user in that case than from your fellow software engineer.
CS (00:27:46):
But then again, you don't want your next fellow software engineer to have a hard time modifying the code and screw something up and potentially kill somebody. So it's all a balancing act. But I think the concept of empathy, I think you can scale, it'd be really, really helpful for us to sort of admit that it's a first class sort of design problem or, and design resource.
EW (00:28:10):
And I think that Christopher had it right with, there are these other terms we use and what they should stem from is empathy and not from directive. And so I was going to ask you, well, how much should we, how much should this additional empathy cost us? I mean, you talked about taking a minute. You, you look at your code, you look at your function and you see, is this the best I could do? Not only for right now, but for the next person's understanding. And that takes time and you know, we're contractors. So time equals money.
EW (00:28:50):
It's a very direct relationship for us. It should be a direct relationship for everyone, but that's a different rant. For us in particular, an extra 10 minutes costs somebody some money. So can we justify it? And yes, if you say I'm making it more reusable, I'm making it more maintainable, then absolutely. We can justify it. I'm making it more empathetic - that should be a justification, but it's not yet.
CS (00:29:19):
That's a hard sell. I mean, the word empathy is just sort of, it can be a very throwaway sort of thing. It sounds, you know, quite frankly, I will have this conversation with people. I will mention the word empathy, and, you know, geeks don't like feelings. I'm just going to be stereotypical there. Geeks don't like feelings and empathy sounds like something that requires feelings or involves feelings. So again, I'm playing a stereotype here. If you want to complain, go ahead and email Elecia, don't email me about it.
CW (00:29:41):
Yeah, we have other people we can have them email.
EW (00:29:46):
We can't send it to the Amp Hour again.
CW (00:29:52):
I wasn't going to send it to them.
CS (00:29:52):
Go send it to the Amp Hour. Is that what you said?
CW (00:29:55):
No, no, that wasn't where I was headed.
EW (00:29:56):
A couple of times we've mentioned -
CS (00:29:57):
Oh, okay. They have a good podcast too.
EW (00:29:59):
Yes.
CS (00:29:59):
Let's see, what was I saying? I forget.
CW (00:30:02):
Geeks don't like empathy because they love Spock. I don't think you said that part, but I added that.
CS (00:30:10):
No, no but that's pretty much -
EW (00:30:10):
No, but it was implied.
CS (00:30:11):
But as a geek, as soon as I mentioned feelings, you went to Spock. And so there you are. But, yeah, we don't tend to like the word empathy and it's hard to sell, right? You go to your VP of sales and he asks you why you're two weeks late and it's costing him a million bucks a week and you say empathy, that's not really a way to go.
CW (00:30:26):
That's a quick way out the door.
CS (00:30:30):
Yeah. But, but, okay. So turn it around, so you're empathetic. So you think, okay, your VP of sales, put yourself in his shoes, he's got customers banging down his door. His CEO says, look, you're out of here if you don't give me a million bucks a week in revenue. So, you know, you understand his constraints, even if you completely disagree with his decision to push this feature out the door before documenting it more or making it more stable or doing whatever it is you want to do. Realize he's coming at you with this business case, with this, you know, deadline, for some reason, you may completely disagree with that reason.
CS (00:31:03):
But if you can put yourself in his shoes and understand that reason...you've got at least a little bit of a leg up and at least a little bit of advantage in having a conversation with him about the trade-offs. If you just think, "Oh, he's dumb. And you know, sales is bad. Engineering is good. Engineering is smart. Sales is dumb", which is again, the stupid stereotype that engineers have. You've sort of given up, you're playing a foolish game. And I think recognizing that the other party may have other motivations and information and sort of putting yourself in their shoes, I think can go a long way to helping the work relationships.
EW (00:31:43):
This is so embarrassing. I remember Ytalk.
CW (00:31:49):
Yeah.
EW (00:31:49):
Chatting with my Christopher and saying, about someone, I don't know whether they're being malicious or just stupid. And I do want to kind of go back and say, you know, really that person is neither one of those things. They just don't have the same information, the same background that you do, they have something else and that something else is valuable. You just don't know what it is yet.
CW (00:32:17):
I think what you're saying is, right, I think it's a really tall order for a lot of people to do what you're saying, but I also think that a lot of engineers don't understand, and this is a little bit of a tangent, but don't understand the rest of the business.
EW (00:32:32):
Yes, exactly.
CW (00:32:32):
And so it's hard for them. It's hard for them to put themselves in other roles' shoes because well, you know, engineering is the important thing, the rest of you people -
EW (00:32:40):
We make things.
CW (00:32:40):
- the rest of you people in marketing and sales or whatever -
EW (00:32:42):
Leeches.
CW (00:32:42):
- you collect your huge bonuses and sit in your desk and play solitaire, whatever we imagine they do. But really businesses are designed along these roles for a reason, and -
EW (00:32:54):
They're not less important. Not really. In fact, they may be more important.
CW (00:32:58):
Yeah, you as an engineer, go try to sell your product to, you know, a million people and see how well that goes. And so it comes back to education, educating other people that, look, you may disagree with this person, but you better understand their job at least somewhat as well as they do before you can really disagree with them about a decision they made. And that's a tall order.
EW (00:33:23):
Cross-functional development is really important. I mean, the more I do hardware, the more I understand how some of my hardware engineers have just been, "No, don't, put down the soldering iron and walk away. I will do that for you".
CW (00:33:34):
But that goes both ways.
EW (00:33:35):
Oh, it absolutely goes both ways. And I've had some of my electrical engineers, "Here's how you learn to solder. And here's how you decide what you're going to do." And those are people that I will be friends with for the rest of my life. It definitely goes both ways.
CS (00:33:49):
I think it's a couple of really interesting things in there. And so, you know, the whole discounting the other parts of the business, I can remember, you know, I was, I was 22, 24 coming out of college. And I remember thinking like, "I don't know what all those business people do," just like you're saying there. And I really thought, you know, what matters in my company, making money. It's, 95% of it is us engineers doing our awesome stuff. 'Cause you know, of course we're all smart. And the problem with a lot of engineers is that, you know, we tended to take hard classes and we thought they were harder than any liberal arts classes and whatever. We were just a bunch of arrogant -
EW (00:34:22):
We have proof. We've proof that engineering is harder now.
CS (00:34:24):
Right. Sure.
EW (00:34:25):
There are lots of studies that say that.
CW (00:34:27):
Wait, what.
CS (00:34:27):
Yes.
CW (00:34:29):
We wrote the studies.
CS (00:34:32):
That's the problem. That's the problem. But yeah, so we, you know, we come out and it's, 95% of what drives a business success and drives my paycheck is, must be engineering. And the other 5% I'll accept that that's some businessy thing, but it's not really necessary. And like, as I got older and as I worked at a couple of different companies and as I started, especially working at smaller companies, you realize that that is just not true.
CS (00:34:55):
And in fact, you know, I would say engineering, the actual technical part of a product, let's say it's 30% of the overall puzzle. And I would say the other 70%, obviously I'm just making numbers up here, but the other 70% is absolutely not technical.
CS (00:35:11):
Furthermore, I think, and I make this point in my talk that sort of having a product, whether it's a web product or an embedded product or web software, hardware, whatever, having a product that simply works and does what it says on the box. I feel like that used to be sort of enough, at least in the software world to get you, you know, maybe some revenue and have a business around. I feel like the bar has lowered for, you know, creating, especially web apps and for creating usable pieces of software. And so merely having a use, a software that does what it says what it does on the box is sort of table stakes nowadays. And so you have to have something else along with that to actually make money, to be a viable company. Yeah.
CW (00:35:55):
And that's not to say that companies can't be screwed up and that people can't be incompetent in other roles. It's just, you ought to know the difference.
CS (00:36:02):
Yup. Yup. Well, and you know, us engineers, we think we don't make mistakes and, you know, whatever. It's foolish right. It's absolutely foolish to think that.
CW (00:36:10):
Bug tracking systems for a reason.
EW (00:36:12):
Every time I think that I look at my Twitter feed and how many typos I have. It's so embarrassing.
CS (00:36:19):
I'm sure when I listen back to this and hear myself talk, I'm going to be like, what, why did I say like, that doesn't even make sense like, that doesn't even grammatically parse. What are you talking about?
EW (00:36:28):
The key is not to listen back.
CW (00:36:29):
Yeah, we've gotten over that.
CS (00:36:31):
Do you just not listen back, I guess, Chris, you do -
EW (00:36:32):
Sometimes I do.
CW (00:36:33):
I have to edit them so -
CS (00:36:35):
Yeah, you have to hear it a lot. That's probably why you resisted to being a co-host for so long.
EW (00:36:42):
So do you have a manifesto for Empathy-Driven Development?
CS (00:36:46):
I don't, I don't have any good tagline.
CW (00:36:50):
The Hippocratic Oath for engineers?
CS (00:36:51):
Maybe -
EW (00:36:53):
Actually in your slides you had readable.
CS (00:36:57):
Oh, right, right.
EW (00:37:00):
And that seemed to be -
CS (00:37:00):
Yeah. That is the one word sort of like, I feel like the most important sort of thing that came out of that talk. What generated that talk in the first place and this whole thing in the first place, the sort of concrete thing was that I wrote about, we came up with a set of best software, best practices for the organization. And it was a few of us who kind of, more senior guys and we kind of put together a three or four page word doc that had, I feel like a pretty good, concise list of things we should do. And we tried not to be too prescriptive. And, you know, at iRobot...we have embedded software, like I'm writing very, very low level sleep code on a Cortex -M3 microprocessor.
CS (00:37:39):
And then we have people writing Java on robots and we have Linux running on robots and we have, we actually have Lisp code running in a bunch of our robots. And I really hope that, I think that I can say all these things. My legal staff at IRobot are nice people. So I think we're okay, but we have tons of different software. We have iOS software, we have Android software, we have tons of different software, so there's no way that you can, you know, write down a list of rules. And so, I was going to present these, this list of software best practices to the organization. And as I tried to think about the best way to do that, I thought there's really nothing here that isn't sort of coming out of a, just make sure your code reads well for the next person who has to come in after you.
CS (00:38:25):
And that kind of, that was kind of the last straw. After I thought about that, then this talk sort of spilled out and this whole concept of Empathy-Driven Development sort of spilled out. So yeah readable, I feel like is also a good hook to hang your hat on. Because if you think about what's readable to a compiler like, your code, it kind of has two audiences. The first audience is a compiler, right? And the compiler accepts garbage, right?
CS (00:38:54):
You know, there's Obfuscated C contest that shows just how bad code a compiler will accept. And the example I give in the talk, I think, is some code that is in the shape of like a nuclear radiation sign or something. And I don't even know what it compiles into but the compiler is happy with just inane garbage. Now granted, the compiler is necessary, but it is not sufficient. So pleasing the compiler is necessary, but not sufficient to writing good maintainable extensible code. And so making it readable for your future self and for the new grad at a college who comes after you, I think is maybe not a manifesto, but it's certainly a good one word sort of call to action.
EW (00:39:35):
But you had more words in your slide deck that you'd come up with as part of this.
CS (00:39:40):
I did, I did, yeah. Readable, reasoned, reusable, reused, repeatable, and reliable. So these were just the six.
CW (00:39:49):
And alliterative.
CS (00:39:49):
Yeah. The six alliterative names that -
EW (00:39:51):
Six "R"s. I made, pirate jokes in the emails
CS (00:39:54):
You did make pirate jokes. Yeah. I'd never thought, I'd never realized that before, and I will not be able to -
EW (00:39:59):
You're totally going to use it in your slide deck, aren't you?
CS (00:40:02):
Oh, absolutely. I'll put your picture up there.
EW (00:40:05):
With a little patch drawn over?
CS (00:40:08):
No, but the, yeah, these are just kind of the six things that we sort of could classify, our six, the sort of six best practices we boil it down to, but I don't even use that in the talk anymore. I think I used that in the first time I gave the talk, but I feel like just getting the notion into people's heads that, "Hey, think about each other. Think about your future self. Think about each other" is a big enough topic that everything else will kind of work itself out. If we can all get better at thinking about each other and thinking about, you know, putting yourself in each other's shoes. And I think everything else will take care of itself.
EW (00:40:44):
Has it made a difference? When was, how long ago did you give the talk for the first time? And have you seen any changes?
CS (00:40:52):
So I gave the talk the first time, let's say in July of this year, I think.
EW (00:40:56):
So short sample time.
CS (00:40:58):
Yeah, not very long. I've given the talk a couple of times, I'm giving it in a couple of weeks. I have seen it resonate with people. People have come up to me and first of all said..."Thank you for talking about imposter syndrome. Like I thought I was the only one."
EW (00:41:13):
Yeah, that's always one of the symptoms.
CW (00:41:15):
Yeah.
CS (00:41:15):
Absolutely. Absolutely. But, so that's been like, if nothing else, that's been a very positive thing, but I have seen people talking about sort of the empathy side of "Okay, we're doing a new system. Let's actually get together and put down on paper how this is going to look, because we both know that, you know, you're going to end up on a different project in six months" or you know, "I just designed this really nasty thing, yeah, I need to go and sort of, because of empathy, I need to go and make it more explainable or more understandable to somebody. Let me put that on the Wiki or let me put that in the OneNote" or whatever. So I've seen little bits and pieces of it, too early to say, you know, whether it's actually a net positive or a net negative, who knows, but...what I've seen, gives me hope. And I think it has some legs and I think it has some use. So I'm hopeful.
EW (00:42:09):
Good. Do you think we all need to be writers in order to make readable code?
CW (00:42:16):
Hmm.
EW (00:42:18):
I say this because I wrote a book and you know, I get to say things like that.
CW (00:42:22):
Do you think your code is more readable now?
EW (00:42:23):
No.
CW (00:42:24):
Okay.
EW (00:42:25):
But, you know.
CS (00:42:27):
I think, the way that I actually stumbled upon empathy was I was thinking about what it is that we do. You know, we have these six, like the readable reason, these six "R"s, the pirate software, best practices,
EW (00:42:43):
Pirate code.
CS (00:42:43):
Exactly.
CW (00:42:44):
I can't stand it.
CS (00:42:48):
Is she making pirate faces at you across the mic there?
CW (00:42:52):
No.
CS (00:42:55):
And I mean, there's going to be some...what are we doing here? And I, you know, I flash back to the office space, the two Bobs sitting across the table, you know, what would you say you do here? And I sort of say, we really, we really write fiction like that. All this software stuff is actually very, very fictional, right? So we create worlds and we create classes and we sort of get to create, it's fiction, it's kind of a generalization, but we sort of, we're writing fiction. We actually even create the constraints that we are later bound by. And so then I started thinking, well, what is it that fiction authors have to do? You know?
CS (00:43:33):
So look at J. K. Rowling, she has to put herself in the head, she's the Harry Potter author. Her job is to put herself in the shoes of both Harry Potter, both her character, like, what's he going to do? What's he going to be motivated by, you know, will he really fall in love with Hermione? Will he really hate Snape as much as he does? Will he identify with Voldemort even a little bit? And she also has to put herself in the shoes of her readers, you know, the 12-year-old kid, who's going to be reading her books. The 30-year-old guy, who's reading the book on his own, the 40-year-old guy, who's reading the book to his kids. So she, you know, she has to kind of serve both audiences, if you will. And she has to really put herself in these different people's shoes.
CS (00:44:20):
And I thought, you know...I wonder if that can help us at all. So that's kind of how I developed this. So when you say, do we need to be a better writer? I think we can use a lot of the same tools, which is, you know, is this believable? Is this writeable, can the reader follow? I'm sure when you were writing your book, Elecia, you must have thought, okay, can, can the kind of reader who just picks it up and plunges into chapter seven, can they pick up the thread of what I'm talking about without being completely lost? Am I right?
EW (00:44:47):
Yeah. And O'Reilly especially encouraged that, that I think about my users. And then they also had this nice description of, your readers are not dumb people. So when you feel like you're talking down to them, or you're overexplaining, just delete that. The people around you are smart, they just don't know what you know, and that's the part you're giving them. You're not trying to make them feel dumb. You're trying to not make them feel dumb, or they're going to throw your book away. You want them to feel smart, but also feel like they're learning something. And I think that makes sense with code as well.
CS (00:45:29):
I think it does. I love that point, actually that almost sounds like maybe it's an antidote to imposter syndrome. So, or rather, let me make sure I heard you right. O'Reilly told you to assume that your audience, that your readers are smart. They just don't know what you know.
EW (00:45:44):
Yeah.
CS (00:45:44):
So turn that around. So what if you thought, "Hey, my colleagues probably think that I'm smart. I just don't know what they know." And I wonder if we started to sort of treat each other like that and maybe even tell each other that. I wonder if that would help sort of raise the, get rid of some of that imposter syndrome.
EW (00:46:07):
Well, the other thing, and I do, I talk about imposter syndrome. Usually more in the women in tech areas, and I talk about it as ways to battle it. And one of the ways that has worked for me is to have the rock star deck, to go ahead and put together, and for me, it's slides because pictures are useful for me, of what I have done that other people seem to find impressive. And then when I'm about to go in for an interview, or I just feel like, "Oh my God, I'm never going to understand this code" or "This data sheet's so hard Maybe I should just, I don't know. Maybe I should just go bake cookies. I'm good at that."
EW (00:46:55):
I look at the slide deck and it makes me remember that there have been other hard things I have done. I have pushed through. I just need to be a little bit more stubborn about allowing myself time to let this sink in. And I like that. I like, and I talk to other people about, you know, it doesn't have to be a slide deck. Maybe it's a piece of paper. Maybe it's your resume, going through and remembering you did these things and people respected you for them. And so, yeah, I, there's a lot of imposter syndrome things. And I think you're right, when you look at these things you've done that you do know and realize these other people don't necessarily know them. And if you're willing to exchange, if you're willing to teach them, they might be willing to teach you without condensation.
CW (00:47:52):
If I could -
EW (00:47:53):
Condensation is not the right word.
CW (00:47:54):
Condensation, no, I don't think dripping -
EW (00:47:56):
Conde -
CW (00:47:56):
Condescension, condescension.
EW (00:47:59):
Condescension.
CW (00:47:59):
Condescension.
EW (00:48:01):
Thank God I have that new vocabulary thing I've been working on.
CW (00:48:05):
There were a few words that flew by that I want to make sure we kind of come back to, 'cause I think there's some important bits. One is the word audience.
EW (00:48:11):
Because we have are multiple audiences.
CW (00:48:14):
We have audiences, yeah.
EW (00:48:14):
I liked that. Chris had that as different audiences need different things.
CW (00:48:18):
But realizing you do have an audience as a coder. It's not, the audiences is not the instruction cache.
EW (00:48:24):
It's not necessarily the user.
EW (00:48:24):
Right, well it is one.
CS (00:48:24):
As a geek, we think the compiler's our audience.
CW (00:48:29):
Right. Right. Right. And I think you kind of said that too. So -
EW (00:48:32):
But that's not the only audience.
CW (00:48:34):
People are going to, people are going to be looking at what you do. And the other thing which is kind of related to that is there's another R word that I think needs to be included. And that's respect.
CS (00:48:47):
Mm.
EW (00:48:47):
Oh, yeah.
CW (00:48:47):
That's a difficult piece because you could be working on a team where you don't socialize with people, you don't know them very well.
EW (00:48:54):
Or you're remote or -
CW (00:48:55):
Or you're remote and you have to get to the kind of thing you're talking about where you think, well, people don't know, or people that think that I'm smart and other people have things of value that they know that I don't know, that's respect. And I think you have to know people and get to know them a little bit outside of, you know, the bug tracking system and git commits.
EW (00:49:20):
I'm not good with automatic respect.
CW (00:49:21):
No. Right. That's what I'm saying. It's tough.
EW (00:49:22):
I mean, people have a title, even when I worked with like, at ShotSpotter and there were police chiefs and you really have to respect them because they have a gun.
CW (00:49:33):
Okay. Well, that's different.
EW (00:49:34):
And it's obvious that they have a gun. And so...being a police chief is not an easy job. So, and I know that 'cause I've talked to enough of them now, and yet it's really hard to just, yes, sir. I, you know, I grew up in California, sir, is not something you say, unless you're in the military speaking to a superior.
CW (00:49:57):
So I think making respect a default -
EW (00:49:58):
Making respect a default is hard for me. I'm used to people earning respect, but that's back to the rock star mentality. It should be default. You should be able to lose respect, but you shouldn't have to earn it.
CW (00:50:11):
People should be innocent until proven guilty.
EW (00:50:13):
Yeah.
CS (00:50:13):
Interesting. I'm actually, if you don't mind, Chris, I'm going to steal that respect line.
CW (00:50:16):
Steal whatever you like.
CS (00:50:18):
Steal -
CW (00:50:19):
Remember what I said, so.
EW (00:50:22):
Now there are seven "R"s in the pirate code, yay.
CS (00:50:25):
Yes, seven "R"s.
CW (00:50:25):
Seven's a good number. It's better than six.
EW (00:50:25):
It's prime.
CS (00:50:28):
So I have a slide in my talk and I say, you know, approach, I'm reading off my talk here. So one second. "Approach readability with empathy means that your code should be understandable by a new colleague. You can assume they're smart, they're motivated and they're eager, but they don't have your memories, your assumptions, or your experience, meet them where they are, not where you are."
CS (00:50:51):
And I think you can sum all that up with respect. Like that's just sort of one word way to sort of say all that. And, and like, O'Reilly told you, Elecia, that, you know, assume your users, your readers, your audience is smart. Don't pander, don't talk down, don't be condescending, but, you know, lift them up, teach them something that you know.
EW (00:51:12):
Yeah.
CS (00:51:12):
And then I think a fantastic idea, I just had this vision through, as we were talking about this, if you guys have ever read any of Kathy Sierra's Head First series of books?
EW (00:51:21):
Yes. I like them very much.
CS (00:51:23):
Oh my God, I think Kathy Sierra is just a phenomenal writer and just a phenomenal, her ideas are just fantastic. ...The premise of these books, if people aren't familiar with them is it's a series of tech books, that I think O'Reilly publishes them don't they?
EW (00:51:41):
Yes, they do.
CS (00:51:41):
So there's the Head First series and they're tech books and they basically take some great, great pains to realize that you, as a reader have this brain and have the psychology and have this, you know, lizard brain or this hindbrain or whatever. And that reading 300 pages of dense material won't necessarily make you learn anything. And so she flips the normal tech book on its head and sort of meets you where you are.
CS (00:52:04):
And goes in with like big pictures and cartoons and changes the kind of format of the book up from anything you've seen before. And, you know, you may love her books or you may hate those books, but at the very least, like she has tried something, I'll say revolutionary, that I think really tries to sort of be empathetic to meet people where they are.
CS (00:52:23):
I mean, her whole, she's given a series of talks, I think like the business of software conference and a couple other places about basically making your users kick ass. And I think the whole O'Reilly thing that they told you about your book, Elecia, which is, you know, your users are smart, your readers are smart, teach them something they don't know. It goes right along with what Kathy Sierra's thing is, which is you want to teach and empower your users, your readers, your audience, to do something they couldn't do before.
EW (00:52:53):
And those Head First books have a lot of psychology, cognitive psychology behind them, looking at how brains learn and how many times you have to say something in order for this to stick and how many different ways you have to say it and how you have to engage the people to be more than just passively reading in order for it to stick. They're big. I mean, you know, maybe you get a book about Java and it's 150 pages, but the Head First book is 350 pages. At the end of each of those, in three months, when you haven't done more than read these books, the Head First one is likely to be the one you remember. And it's, they're faster to read. Well, they're pretty faster. They are faster for me to read, because I don't have to keep rereading things. I tend to remember them, but yeah, they don't work for everybody.
CS (00:53:46):
She tends to repeat things in there at different intervals, which I think is scientifically proven to help us remember stuff. So yeah, she meets the audience where they are and, yeah, using cognitive psychology. One of the things I want to do is I want to learn...there's gotta be people, there's gotta be sociologists and psychologists that have looked at how empathy sort of works in the workplace. And there's gotta be people who study this, as opposed to me, who's just, you know, I'm a software engineer who stumbled upon this thing that could be a good idea.
CS (00:54:16):
There's gotta be some research out there and some people who understand this better, better than the three of us do. Right. So I want to look into that more.
CW (00:54:26):
So you're saying you have imposter syndrome about imposter syndrome.
CS (00:54:30):
That's exactly right. And I think this one's realistic though. 'Cause I know that I don't know very much about it, but, yeah, I think this is a deep topic, which, I mean, shoot in just an hour, talking with you two, like we, you know, you just generate a lot more thoughts, thoughts in my head and yeah, this is great.
EW (00:54:51):
Regarding what you were saying, Thinking, Fast and Slow by Daniel Kahneman.
CS (00:54:59):
Yes, yes.
EW (00:54:59):
It is an incredibly dense and amazingly actionable book in cognitive psychology where he talks about how your brain works and why it is so easy to fool. And I've thought, if you ever want to be a con artist, this is the book you should start with. But even if you don't want to be a con artist and you want to know what are the fallacies people fall into and why and how to prevent them, it was really good. And it's on my list of books that I want to read multiple times, which most nonfiction books don't make it into the multiple time book.
CS (00:55:39):
Right.
EW (00:55:39):
Of course, it's ginormous and took me about three months to read, but you know, it was really good. So I want to switch gears from Empathy-Driven Development.
CS (00:55:52):
Actually, sorry, I want to make one more comment.
EW (00:55:55):
Oh, sure.
CS (00:55:55):
So that book is a phenomenal book. And as soon as you said that, I thought about another book, which I just had to look up here while we were doing this, sorry. It's called Make It Stick: The Science of Successful Learning. It's by Peter Brown and it is along the same lines, but he actually looks at the science of teaching and recall, and sort of flips a lot of conventional things that we've been taught on its ear. So anyway, another excellent book is this Make It Stick: The Science of Successful Learning. Sorry. Didn't mean to interrupt.
EW (00:56:25):
No, that's great. I will add it to my list and to the show notes. So switching gears, are you, do you have any other questions?
CW (00:56:36):
So many, probably time for another show worth of questions. So it's a good, I think it's very interesting you stumbled upon this. I think it's the right time to have a discussion, to start a discussion, a dialogue about this kind of, putting this kind of thought back into engineering. And I just want to encourage you to keep spreading it around outside of iRobot.
EW (00:57:06):
Yeah. I sent you a couple of conferences, suggesting maybe doing some proposals because I agree. I would like to have it spread around more. We seem to have gotten into a bit of a habit of only talking about people who are kind of mean and stuff. And it'd be nice to talk more about the good parts of engineering and how to make, how to shine a light more on those.
CW (00:57:29):
And this applies outside of engineering.
EW (00:57:31):
Absolutely.
CS (00:57:32):
Right, right.
CW (00:57:32):
But I think that's a good place to start.
EW (00:57:34):
Yeah.
CS (00:57:34):
Yeah. But I mean, your show is a good example. You bring a bunch of people on here, and your show is actually a very positive uplift. I mean, you bring a bunch of people on the show who like what they're doing, who seem to like the companies they work for who, I mean, yeah, whatever. We all have little annoying grousing things that we complain about, you know, some company foolish policy or whatever, but for the most part, you've got people on your show who obviously love what they do and seem to work with pretty cool people. And you are obviously friends with some of these people. And so you guys have a lot of empathy for each other. You have a good time. So I think it's a good example of, of, yeah, it's a good time in the industry and it's a good time to sort of get better at what we're doing through empathy. It's cool.
EW (00:58:15):
Empathy is a good way to get better at this. I need more of it. So it'll make me think at least.
CS (00:58:22):
Cool.
EW (00:58:22):
But as I went through my email to prep for the show, I realized you've emailed a couple of times. I think one of the first was after the imposter show. But I was talking to an executive at a largeish company who found it difficult to believe that people listen to a show a whole hour long about embedded software and hardware. And I did my usual sort of clam up because I was in public. And if you meet me at a conference, I'm either hyper because I'm trying not to be shy or I'm quiet because I have given into my terminal shyness and I said "bluh, er, uh, um, they do according to our, you know, statistics. What should I have said to him about people who listen and why they listen?
CS (00:59:18):
I don't know. I listen, I enjoy your podcast. Why do I do that? Because I like the field and you have interesting interviews with interesting people. I mean, did you, can you share your listener numbers? Does iTunes give you like how many people download in podcasts of yours?
CW (00:59:35):
A few thousand an episode.
CS (00:59:37):
That's pretty huge. I mean, and that's the beauty of the internet and podcasts is that, you know, this is kind of a niche podcast, but think of how many companies have people doing what we do. And plenty of us enjoy this more than just define thing. And so it shouldn't be too surprising that people would want to listen to it, you know, on their commute or on a run or, you know, on the side, so.
EW (01:00:01):
Ah, there's soldering, I think that's the other one.
CW (01:00:03):
As someone who listens to a ton of technical podcasts, the question when I, when she told me that somebody had asked her that I just, my brain kind of locked up, I was like, ah, I don't know. Why wouldn't you?
CS (01:00:15):
What do you do on your commute?
CW (01:00:17):
Yeah.
CS (01:00:18):
You listen to NPR probably.
CW (01:00:20):
Which is no different in its own way. I mean, it's, people talking.
CS (01:00:24):
Right, that's my point, that's my point. It's exactly the same thing. This is just more focused on something than the general news that you get on NPR or whatever, whatever you listen to.
EW (01:00:33):
Yeah. You know, if I'd brought up NPR, that would have totally stuck for him. Well, good. Now I have words to say for next time.
CS (01:00:43):
You share your subscriber count.
EW (01:00:45):
I don't always like to. The subscriber count is cool and sort of strange. I'm pleased, but I do often pretend there are less than a hundred listeners because then I can say what I want without worrying. But if I start thinking about how large, it does get a bit intimidating and it's been somewhat bad for putting together conference proposals. And this is also The Amp Hour Dave's, Dave had a rant on The Amp Hour about how he didn't make proposals for conferences. I don't know whether it was ever very often, but he seldom did because his audience base is so much larger than a conference room would be.
EW (01:01:30):
And he has, I mean, they have more listeners on The Amp Hour and he has his video blog that has just way, way more listeners.
CW (01:01:38):
Super popular.
EW (01:01:40):
Super popular. So he's got a huge audience, but even our couple thousand, I'm not gonna, I mean, I kind of packed a room at the embedded systems conference and it was still only a couple hundred. And with all of my technical difficulties, I did a crappy job of talking 'cause I didn't get to break and restart and say, can we do that part again, which now we can do on the show. So it's a little, it has the larger listener base has made me less likely to speak at conferences, especially when I have to do a whole clean new presentation and have to commute.
CW (01:02:17):
That's interesting.
EW (01:02:20):
I'm lazy. It's easy to get on the microphones. And so many people do have things they want to talk about that they're enthusiastic about, their jobs or ideas, or next week we're talking to somebody about electrifying trucks. I'm so excited about electrifying trucks.
CS (01:02:36):
Electric. That sounds dangerous.
CW (01:02:37):
It does.
EW (01:02:37):
I know. I don't think it's going to be that dangerous. We'll see.
CS (01:02:43):
It does sound cool. I will tune in. After I rate you on iTunes.
CW (01:02:48):
Geez.
EW (01:02:48):
Thank you. Well, I think we're about out of time and I think it's probably getting late where you are and dinnertime where we are.
CW (01:02:59):
Yes.
EW (01:02:59):
Do you have anything left to ask Christopher?
CW (01:03:01):
No, I threw in my last comments before the last topic there, so.
EW (01:03:08):
I hear iRobot is hiring and that you like working there.
CS (01:03:12):
Where'd you hear that?
EW (01:03:13):
From you.
CS (01:03:17):
That's right. That's right. Yes. Yes, we are hiring. We are growing quite a bit. We have a lot of software engineers and actually electrical engineers and mechanical engineers that we are hiring. And so Elecia has allowed me to say this on the air. And if you'd like, please check out our careers website. I'm always happy to email with people, even if you've never done anything with robotics before. When I started at iRobot, I could not spell the word robot. I had never done anything with robots before.
CS (01:03:47):
We realized that there were only so many people who actually like, have a degree in robotics or have a background in robotics. So we're just looking for software people. We're just looking for smart software people, you know, C, C++, Java, the usual sort of...I don't want to say lowerish level system level kind of stuff. We're looking for, you know, smart developers who are easy to work with. And I've got to say that we're a very good company to work for. So, I think, yeah, if you, feel free to email me, at my own email address, and I'm happy to talk to anybody who's interested in any of our jobs on our website. It's irobot.com and you can navigate to the careers part.
EW (01:04:29):
Most of the careers are posted for being in the Boston area. Is that right?
CS (01:04:33):
Correct. Our headquarters is just outside of Boston. We have a smaller office in Pasadena, California that does more researchy kind of stuff, but check it out. Both Boston and Pasadena are nice places to live, so, yeah.
EW (01:04:47):
And your email address, which I'm not going to put in the show notes. I'm just going to say it out loud here, although it's not too hard to say. I am putting his blog in the show notes and they're linked. So it's S-V-E-C at said S-V-E-C dotcom. So that's ... .
CS (01:05:06):
Right. Thanks.
EW (01:05:08):
Do you have any other last thoughts you'd like to share us, leave with it, leave with the bleh bebleh bebleh. You're going to take that out, right?
CW (01:05:15):
Nope.
EW (01:05:17):
Do you have any last thoughts you might want to leave us with?
CS (01:05:19):
No, no. This is a heck of a lot of fun. I'm so glad I got to talk with you. I got a ton out of this, so like, I hope that you and/or your listeners do, but I really enjoyed this. Thanks for having me on.
EW (01:05:30):
Thank you for chatting with us. It has been fun. And I hope you do more with this, 'cause I want to hear about it more than just on our show.
CS (01:05:38):
I look forward to it. Thanks for your encouragement.
CW (01:05:40):
Thanks, Chris, it was awesome.
CS (01:05:41):
Yeah. Thanks.
EW (01:05:42):
My guest has been Chris Svec, Senior Principal Software Engineer at iRobot, science fiction writer, or software writer and advocate for a more humane software development.
EW (01:05:57):
Thank you to Christopher White for producing and co-hosting. And thank you for listening. If you'd like to say hello, our usual place show@embedded.fm or hit that contact link on embedded.fm.
EW (01:06:08):
The final thought for this week was actually stolen from that slide deck we've been talking about, I'm not sure it's going to be in the show notes, but I bet if you email Chris he'll probably find something for you. And he has a quote from Richard Hamming. That's Hamming of Hamming codes and Hamming distance. He's a founder of the ACM, which is, you know, such a great group. And he was a Turing award winner, which I believe means he's not a computer?
CW (01:06:41):
Or he is a computer.
EW (01:06:42):
I don't know, but he worked with computers longer than most of us have been alive. And he says, "The more I study programming, the more I understand I'm looking at human beings. Remember write psychological rather than logical. Write so it can be followed, so that you, five years later, will know what you were doing." I think that's better than my alternate ending, which was "Happy cows give better milk and better milk makes better cheese."
CW (01:07:15):
But now your alternate ending is the ending.