Embedded - 78: Happy Cows

Episode Date: November 25, 2014

Chris Svec (@christophersvec) has an idea about adding empathy to software development. It is a good idea. His blog is Said Svec. He works for iRobot and they are hiring. (Chris' email is given toward the end of the show but if you hit the contact link here, we'll pass along info to him.)  Obligatory cat video Embedded has an episode devoted to impostor syndrome.  O'Reilly's Head First book series is pretty awesome. Elecia is still talking about Thinking, Fast and Slow as a great way to understand brains. Chris Svec also recommends Make It Stick. The Richard Hamming quote came from his address to the Naval Postgraduate School. The whole lecture is available on YouTube.

Welcome to Embedded, the show for people who love gadgets. I'm Alicia White, back with my co-host Christopher White. Our guest this week is Chris Svek, and we're going to talk about empathy-driven development. Before we explain that, could I ask you for a tiny, tiny favor, 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. And I promise we'll stop asking soon. Or at least put it back at the end of the show.

So now back to the fun. Having two Chris's on the show shouldn't be confusing at all. Hi, Chris 2. This is Chris 1. There's no meaning behind the ordering there. Sorry. Thanks for being on the show. Thanks, Chris. Wait, is that T-O-O or T-W-O? I don't know. I think we should just leave that behind. All right. Excellent. Excellent. This is what you and I have grown up with, so we're used to it. Could you tell us a bit about yourself? Sure. I've been 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 for Intel and AMD, and I sort of moved up the hardware stack to actually 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 um yeah that's kind of me ee to software not not an unusual path yeah i work with a bunch of people who you know followed similar chip company to software company i've always wanted

to know about irobot and my big question is do you actually test with cats? We test at home. We send robots home with our employees of course for internal stuff. Cats, kids, dogs, whatever you got. Although I do have to say we enjoy the YouTube cat videos at work quite a bit. I like the ones where the cat is bopping the dog whenever the vacuum cleaner goes by. Those are my favorite. Yeah, I feel bad for the dog, but those are really funny. 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? That's maybe the next few years, yeah, shortly before they take over. That's what we're doing. No, no, no. What could you design me to do? How could you do this to me?

That shall not kill humans. I suck dirt off the floor for a living. There's a great, what is it? It's called, oh, shoot, I'll I'll put it in the show notes maybe. Somebody has a, I think it's a self-aware Roomba is the name of the Twitter account. And it's basically a very depressed Roomba who goes around all day, apparently is self-aware. I'm sure our company doesn't sanction it, but it's still pretty funny. Anyway. Empathy-driven development. uh anyway empathy driven development what are the reasons that i'm here yes so empathy driven development is uh is just something i've been i've been kind of um it's been cooking around in my head for a while it's just kind of crystallized in the last six months um it's it's a way of trying to bring empathy into engineering specifically software engineering

um there's plenty of talk in in our, in 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. And then within a software development team, 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 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. It's also the notion that you should have empathy for your future self, where 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 a SVN blame or whatever version control tool you like. I'm going to do a blame, and I'm going to realize that fool was me. And you're going to feel bad for yourself. Why didn't I give 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. I mean, that makes sense. 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. It's not just coworkers. It's coworkers you may never meet or people who follow you. I don't think that's how engineering is done. It's not just co-workers. It's co-workers you may never meet. Or people who follow you. I think it's a fascinating idea. And when I read the description before the show, it sort of struck me. Oh, yeah.

Of course you should be doing it? 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 the reverse, well, the guy before me wrote this code. Well, I don't know who that was. It must not be very good, so I'll just throw it out. And I think we're all guilty of that. So it's fascinating to me that

somebody has actually come to the realization that that's a bad thing because yeah, it should be a bad thing. Yeah, you definitely, I mean, I, you know, it's, it's empathy driven development. I sort of named it that I just needed a, you know, a hat hook to hold something. I'll hold the concept on, but you know, it's, it's almost something that shouldn't be capitalized. It's pretty general. I mean, like you both said and like I've said, the user experience community certainly is all about empathy. You should definitely have empathy for 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 also expect the 22-year-old who just graduated college to not know how your software is designed. And you should expect, you know, I'm someone, I've been an iRobot for about a year now, and I'm a pretty experienced person. I worked for, you know, 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 Gansel said, I think, when he was on the show, which was basically being professionals.

And I think that was his concept, right? Yes, definitely. Being a grown-up. Being a grown-up, yeah. And so being a grown-up means a grown-up yeah and so being a grown-up means treating those around you like grown-ups and 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 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 new person. Chris and I just avoid it because we're scared of this. So it makes a lot of sense. You know, you should be nice to them, 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 why aren't we doing this i think i think it's not it's i

think it's more than just being nice. I think a lot of it is, well, first of all, in the tech community, we sort of have very unfortunately sort of praised the lone hero, like the firefighter who can single-handedly rewrite the code over a weekend and no one else can understand it. But man, that stuff works. And whoever it is, that hacker she's awesome 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 that's kind of our um i don't know 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 with team programmers because maybe maybe a software project was didn't have to be as big or complicated but i think something that you know the longer and 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 our writing our code and dealing with each other so you have two ideas there and i totally agree about the empathy but i admit that i got into engineering because i was a bit of a loner 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 have left because all this communication and having to worry about people's feelings, it was difficult to learn. Well, I wonder if it's a product of our education. Because when we're going through school and 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. 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.

I only want green M&Ms. Yeah, no brown M&Ms, yeah. That's interesting I had not considered sort of the you know coming out of out of college

coming out of university and yeah that definitely is that you know you're on your own yeah you work on a team but your grade is your own your education is your project

that's an interesting that's an interesting history or genealogy that's interesting 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 because see part where I said loner. One or two group projects, but they were... Yeah, I guess even clinic was still very... You didn't have a lot of experience and you were thrown together with people who were random. Different skill sets. You still were working on your own thing.

And even within those groups, your grade was your grade, right? That's true. To a certain extent. people who are random i just different skill sets you still were working on your own thing and even within those groups your grade was your grade right that's true 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'd you'd try to step up and okay we need to get this done it would be you're going to ruin my grade. 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.

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 you were starting to talk about university and college and oh no no i was just saying that that's interesting i hadn't i hadn't gone there i hadn't considered kind of it is a change i wonder if another change is also in college um 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. You know, maybe if you're a freshman and you could 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 if you go into the working world and you're working with people who have started this system before you were born, maybe, depending on what you're doing, or at the very least have been working on this software for five, 10 years,

and you are thrust into the middle of it. 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 get in and you're part of some bigger project

your whole four years, your whole time there, and you're working with juniors, seniors, freshmen, sophomores. So there is kind of more of this life cycle to it i wonder if that's 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 certainly understanding and getting a sense of a history of a project even how to use version control in order to figure out what's going on. We had 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. In six months, you can remember what you were doing for the whole six months. 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 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 that exists no no and in fact when i started doing this this talk when i started kind of pulling together what ended up being a talk when i was at irobotica you know about the sympathy driven development i started realizing that this is not you know i'm again i'm not trying to create some methodology'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?

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 people just raised their hands right off the bat, like before I said anything. And I said, all right, well, who here knows what it is and admits to having it? And a bunch of people raised their hands. Then I said, okay, 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, 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. 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, the defensiveness, it's both wanting to be that rock star and being afraid that you're not.

And that you never will be, that you never were. 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. Yeah, but I think just admitting that, hey, you know what, I'm not perfect. And I remember one of the women who raised her hands, she is probably one of the best software developers I've ever worked with. And she has worked on the systems, the robots, for a long time.

She knows everything. She's super easy to work with. When I saw her saying, oh, she feels like that, I'm kind of like, how you how can you think that like you're awesome she's like i don't think so 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 some things we assume that everyone else knows more than us like we assume that i have a slide in the talk and i've seen it 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 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 because 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 and so you have you know you you have the youth that me and my 37 year old self don't you know don't have quite finger on the pulse of the 23 year old anymore so we all come to the table with different skills and experiences and like uh we just need to need to not undervalue um what we bring to the table with different skills and experiences and like uh we just need to need to not undervalue um what we bring to the table and realize that everyone brings something of value

now 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 um more maintainable make it you know 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 make it easy to jump in a new code, you're going to enjoy your job more. And I spend too many hours at my job every day

away from my family and my home and, you know, we're doing whatever else that I want to enjoy my job. I don't want to, you know, go into work and be like, I 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. 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, that I wrote about

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, just you know this touchy-feely feel goodery kind of stuff it's like i said communications basic communications so okay basic communications but what do you want us to do with empathy driven development what would tactically, how is it going to change my day tomorrow? Yes, that is maybe my next talk. I don't know. 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 your 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. So when you finish up a function, before you check in your code tomorrow,

or before you think about starting a design, stop and think, all right, 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 fix the four lines that are required or whatever, 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 for what was actually the cause of the bug and how you could fix it or how you did fix it. Or maybe even what future problems you think it might cause, but you didn't have time to fix today because we needed to get this in for shipping the next rev of the product or whatever it is. So that's just off the top of my head,

an example of something you can do. 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. I mean, I know 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 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 um the thing i also wanted to kind of touch on was that i could see imposter syndrome and this

sort of mixing together and and maybe this is a personal problem but turning into sort of feared fear driven development where i'm kind of paralyzed by oh god i don't want to touch this code because i might i might make it bad for the next person or i might make a mistake that uh 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.

Are you a perfectionist by any chance? You'd have to ask the other hosts. Sometimes. Definitely sometimes. And, you know, it depends on what we're working on. You 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 coat break. 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 your actions because that seems wrong but but have this awareness of there are multiple masters in software you you're working towards shipping on time shipping a product you're proud of, shipping a product consumers want, shipping a product that has good code that future people can live with, my colleagues. And 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.

You could break it down to common terms like maintainability, testability. Reusability. Reusability. These are all things that we use as terms in software design that are sort of vague. But I think 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.

And if you could do that with empathy in mind, 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 because of empathy. Right, and make it reusable specifically with the new hire, new grad from college. Make it, you know, make it so that someone who does not know that the system architecture looks like this, because, of course, everyone knows that the system architecture looks was, you know, how would a empathy driven development? Is that like another, you know, capital M methodology? Is this like agile or

test driven development or something like that? And I don't, it's definitely not anything like that. 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 all right 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 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 will sort of be more for the end user in that case than from your fellow software engineer. 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 it can scale and be really, really helpful for us to sort of admit that it's a first-class sort of design problem and design resource. 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 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 we're contractors, so time equals money. 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 you 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 that's 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 mentioned 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 mentioned 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 alicia and don't email me about it. We have other people. We can have them email. Wait, we can't send it to the amp hour again.

I wasn't going to send it to that. Don't send it to the amp hour. Is that what you said? No. A couple of times we've mentioned it. That wasn't where I was headed. Okay. They have a good podcast, too. Let's see.

What was I saying? I forget. Geeks don't like empathy because they love Spock. I don't think you said that part, but I added it. No, it was implied. 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.

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 a million bucks a week and you say empathy. That's not the right way to go. That's a quick way out the door. Yeah. But, okay, so it's a turnaround.

So you're empathetic. So you think, okay, 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're out of here if you don't give me a million bucks a week in revenue. So 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 deadline. For some reason, you may completely disagree with that reason but if you can put yourself in his

shoes and understand that reason you're 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 he's dumb and you know sales is 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 your work relationships. This is so embarrassing i remember i remember why talk yeah chatting with 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.

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. And so it's hard for them to put themselves in other roles' shoes because, well, engineering is the important thing. We make things.

The rest of you people in marketing and sales or whatever, you collect your huge bonuses and sit in your desk and play solitaire or whatever we imagine they do but really businesses are designed along these roles for a reason and they're not less important not really yeah in fact they may be more as an engineer go try to sell your your product to you know a million people and see how well that goes and so it's 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. 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 but that goes both ways 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 I will be friends with for the rest of my life. It definitely goes both ways. 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 22 or 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 awesome stuff because, 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 much arrogant.

We have proof. We have proof that engineering is harder now. Are you sure? There are lots of studies that say that. Wait, what? Yes. We wrote the studies. That's the problem. That's the problem.

But yeah, so we come out, and 95% of what drives a business success and drives my paycheck 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 different companies and as i started especially working at smaller companies you realize that that is just not true 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 And I would say the other 70%, obviously I'm just making numbers up here, but the other 70% is absolutely not technical. 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 software heart or 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 maybe some revenue and have a business around. I feel like the bar has lowered for creating especially web apps and for creating usable pieces of software. And so merely having a software that does what it says in 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 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 yep, well and you know us engineers we think we don't make mistakes and you know, whatever we did, it's foolish, right? It's absolutely foolish to think that. Bug tracking systems for a reason.

Every time I think that I look at my Twitter feed and how many typos I have. It's so embarrassing. 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? That doesn't even make sense. Like that,

that doesn't even grammatically parse. What are you talking about? The key is not to listen back. Yeah, we've gotten over that. Do you just not listen back? I guess, Chris, you do. Sometimes I do. I have to edit them, so. Yeah, I get to hear it a lot.

That's probably why you resisted to being a co-host for so long. So do you have a manifesto for empathy-driven i i don't i don't have any any good tagline um hippocratic oath for engineers actually in your slides you had you had readable oh right right yeah that that 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 at iRobot, we came up with a set of 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. And then we have people writing Java on robots, and we have Linux running on robots, and we actually have Lisp code running in a bunch of our robots. And I really hope that I think 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. There's no way that you can write down a list of rules. And so I was going to present

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. And 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? 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 out of 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 but you had more words in your slide deck that you'd come up with as part of this i did i did um yeah readable reasoned, reusable, reused, repeatable, and reliable. So these were just the six names. Alliteratives.

Yeah, the six alliterative names. Six R's. I made pirate jokes in the emails. You did make pirate jokes. Yeah, I never thought, I never realized that before, and I will not be able to. And now you're totally going to use it in your slide deck, aren't you? Oh, absolutely. I'll put your picture up there. With a little patch drawn over. No, but these are just kind of the six things that we sort of could classify our 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. Has it made a difference? How long ago did you give the talk for the first time and have you seen any changes so i gave the talk the first time let's say in july of this year i think so short sample time yeah not very long i'm gonna talk a couple times i'm giving it a couple weeks um i have seen it

resonate with people people have come up to me and first of all said thank you for talking about um thank you for talking about uh imposter syndrome like i thought i was the only one that's always one of the symptoms yeah absolutely absolutely but um 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 of okay we're doing a new system um 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 uh yeah i need to go and sort of because of

empathy i need to go and and make it more explainable or more understandable to somebody let me put that on the wiki or let me put that in the one note or whatever so i've seen little bits and pieces of it um too early to say you know whether it's actually a net positive or a net negative who knows but uh i've seen what i've seen gives me hope and uh and i i think it has some legs and I think it has some use. So I'm, I'm hopeful. Good. Do you think we all need to be writers in order to make readable code? I see this cause I wrote a book and you know, I get to say things like that.

Do you think your code is more readable though? No. Okay. Do you think your code is more readable now? No. Okay. But, you know. I think the way that I actually stumbled upon empathy was I was thinking about what it is that we do. We have these six, like the readable reason, these six R's, the end of pirate software best practices. Pirate code. Exactly, pirate code.

I can't stand it is she making pirate cases achieve across the mic thing no um and uh and i mean there's gotta be something that's gonna be what 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 thought, we really write fiction. Like, all the 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, 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. What's he going to do? What's he going to be motivated by?

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. The 12-year-old kid who's going to be reading her books, the 30-year-old guy 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 has to kind of serve both audiences, if you will. And she has to really put herself in these different people's shoes. And I thought, you know, I wonder if that can help us at all. And 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 writable? Can the reader follow? I'm sure when you were writing your book, Alicia, you must have thought, okay, can a 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 yeah uh 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 over explaining, 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 i think

it does i love that point actually that almost that almost sounds like maybe it's an antidote to imposter syndrome so or rather let me make sure i heard you right i really told you to assume that your audience that your readers are smart they just don't know what you know yeah 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. Well, the other thing, and I do talk about imposter syndrome, usually more in the women and 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, have the rockstar deck to go ahead and put together. And for me, it slides because pictures are, are useful for me of, 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. It's so hard. Maybe I should just, I don't know, maybe I should just go bake cookies. I'm good at that. 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. 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, 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 that's condensation is not the right word condensation no no i don't think condescension condescension condescension condescension thank god i have that

new vocabulary thing i've been working on there were a few words that flew by that i want to make sure we kind of come back to because i think there's some important bits one is the word audience because we are multiple audiences we have i like that chris had that yeah as different audiences need different things but realizing you do have an audience as a coder it It's not, the audience is not the instruction cache. Well, it is one. As a geek, we think the compiler is our audience. Right, right, right. And I think you kind of said that too. But that's not the only audience.

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. Oh, yeah. That's a difficult piece because is there's another R word that I think needs to be included, and that's respect. Oh, yeah. And 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. Or you're remote. 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 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. I'm not good with automatic respect. No, right. I mean, people have a title. Even when I worked with like at ShotSpatz Butter and there were police chiefs. And you really have to respect them because they have a gun. Okay, well, that's different. And it's obvious that they have a gun.

And being a police chief is not an easy job. And I know that because I've talked to enough of them now. And yet, it's really hard to just, yes, sir. I grew up in California. Sir is not something you say unless you're in the military speaking to a superior. So I think making respect a default. 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. People should be innocent until proven guilty. Yeah. Interesting. I'm actually, if you don't mind, Chris,

I'm going to steal that respect line. Steal whatever you like. Remember what I said. The seven R's. Now there are seven R's in the pirate code. Yay. Seven R's. That's a good R's in the pirate code. Yay! That's a good number.

It's better than six. So I have a slide in my talk, and I say, you know, I'm reading off my talk here, so one second. So 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. 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 like O'Reilly told you, Alicia, that, you know, assume your users, your readers, your audience is smart. Don't pander. Don don't talk down don't be condescending but you know lift them up teach them something that you know yeah and i think i think a fantastic i just uh that this vision through what we're talking about this if you guys have ever read any of kathy sierra's um headfirst series of books yes so if i like them very much oh my god i think kathy sierra is just a phenomenal writer and just a phenomenal just her ideas are just fantastic um her um the premise of these books if people aren't familiar with them is it's a series of tech books um that i think orally publishes them don't they do all right so there's a headfirst 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 this psychology and have this, you know, lizard brain or this hind brain 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 and goes in with like big pictures and cartoons and changes the the kind of format of the book up from anything you've seen before and you know you may you may love her books or you may hate those books but at the very least like she has tried something um i'll say revolutionary that i think really tries to sort of be empathetic to meet people where they are. 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, Alicia, which is, you know, your users are smart, your readers are smart, teach them something they don't know, 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. Those headfirst books have a lot of 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 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 headfirst book is 350 pages at the the end of each of those, in three months, when you haven't done more than read these books, the headfirst one is likely to be the one you remember. And 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. She tends to I tend to remember them. But yeah, it works for everybody. She tends to repeat things 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 that there's got to be people, there's got to be sociologists and psychologists that have looked at how empathy sort of works in the workplace. And there's, there's got to 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. There's got to be some, some research out there and some, some people who understand this better than the three of us do. Right. So I want to look into that more. So you're saying you have imposter syndrome about imposter syndrome. That's exactly right. And I think this one's realistic though, because I know that I know that I don't know very much about it, but yeah, I think, I think this is, I think this is a, a deep topic, which, which I mean, shoot in just an hour talking with you two an hour talking with you two, you just generate a lot more thoughts

in my head. Yeah, this is great. Regarding what you were saying, Thinking Fast and Slow by Daniel Kahneman. It's 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 it was really good and it's it's on my list of books that i want to read multiple times which most non-fiction books don't make it into the multiple time book right of course it's ginormous and took took me about three months to read but you know it was really good so i want to switch gears from uh empathy driven development i'm actually sorry i want to make one more oh sure 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. No, that's great. I will add it to my list and to the show notes. So, so switching gears, are you, do you have any other questions?

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 my robot yeah i sent you a couple of conferences uh 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 and the supplies outside of engineering absolutely but i think that's a good place to start yeah yeah but i mean your your show is a good example you bring a bunch of people on here and your show is actually a very um 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 know, you guys have a lot of empathy for each other. You have a good time. So I think it's a good example 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, I think. So that's cool. Empathy is a good way to get better at this.

I need more of it. So it'll make me think at least. 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 large-ish 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 in to my terminal sinus. And I said, they do, according to our statistics. What should I have said to him about people who listen and why they listen? 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, can you share your listener numbers? Does iTunes give you like how many people download in podcasts of yours? A few thousand an episode.

Oh, yeah, that's pretty huge. I mean, 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 the eight to five thing and so it shouldn't be too surprising that people would want to listen to it you know on their commuter or on a run or you know on on the side so other soldering as someone who listens to a ton of technical podcasts, the question, when she told me that somebody had asked her that, my brain kind of locked up.

I was like, I don't know. Why wouldn't you? What do you do on your commute? You listen to NPR, probably. Which is no different in its own way. I mean, it's people talking. 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 you listen to. 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. Just share your subscriber count.

I don't always like to um the subscriber count is is cool and sort of strange i i'm pleased but i do often pretend there are less than 100 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 had a rant on the Amp Hour about how he didn't make proposals for conferences. I don't know whether it was ever or very often, but he seldom did because his audience base is so much larger than a conference room would be. 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. He's super popular, yeah. Super popular. Mm-hmm, mm-hmm. So he's got a huge audience. But even our couple thousand, I'm not going to, I mean, I kind of packed a room at the Embedded Systems Conference, and there's still only a couple hundred. And with all of my technical difficulties,

I did a crappy job of talking because 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 the larger listener basis made me less likely to speak at conferences especially when i have to do a whole clean new presentation and i have to commute and blah blah i'm lazy it's it's easy to get on the microphones and so many people do have in things they want to talk about that they're enthusiastic about, their jobs or ideas. Next week we're talking to somebody about electrifying trucks. I'm so excited about electrifying trucks. That sounds dangerous.

I know. I don't think it's going to be that dangerous. It does sound cool. I will tune in. After I rate you on iTunes. Thank you. Well, I think we're about out of time

and I think it's probably getting late where you are and dinner time where we are. Yes. Do you have anything left to ask, Christopher? No, I threw in my last comments before the last topic there. I hear iRobot is hiring and that you like working there. Where'd you hear that?

From you. 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 Alicia 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. We realized that there are only so many people who actually have a degree in robotics or have a background in robotics. So we're just looking for

for software people. We're just looking for smart software people, you know, C, C++, Java, the usual sort of the usual, I'll say lower-ish level, system level kind of stuff. But 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. Most of the careers are posted for being in the Boston area. Is that right? 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. And your email address, which I'm not going to put in the show notes, I'm just going to say it aloud here, although it's not too hard because I am putting his blog in the show notes and they're linked. It's svec at sedsvec.com So that's svec at sedsVEC.com So that's SVEC at SEDSVEC.com

Right. Thanks. Do you have any other last thoughts you'd like to share with us? You're going to take that out, right? No. Do you have any last thoughts you'd like to leave us with? No. No, this was 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 I hope that you and all your listeners do. But I really enjoyed this. Thanks for having me on. Thank you for chatting with us. It has been fun. And I hope you do more with this

because I want to hear about it more than just on our show. I look forward to it. Thanks for your encouragement. Thanks, Chris. It was awesome. Yeah, thanks. My guest has been Chris Speck,

Senior Principal Software Engineer at iRobot, science fiction writer or software writer, and advocate for a more humane software development. 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 at embedded.fm, or hit that contact link on embedded.fm. 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 the founder of the ACM, which is just, you know, such a great group. And he was a Turing Award winner, which I believe means he's not a computer. Or he is a computer. 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

right so it can be followed so that you five 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. But now your alternate ending is the ending.