Embedded - 297: Mice to Do My Bidding

Episode Date: August 2, 2019

Chris Svec (@christophersvec) spoke to us about how hope can improve our software and work environments.  Chris is the author of Embedded Software Engineering 101 blog and has been on the show several times since his first appearance in 78: Happy Cows. He mentioned Seth Godin’s Three Wishes post. We talked attentional focus and passing basketballs. Details for the Embedded Cats and Hacks party are in the show. If you can’t attend, well, maybe you can still get a mug (zazzle). If you can attend, iRobot has graciously given us a couple Root robots that we’ll be giving away.

Welcome to Embedded. I am Alessia White. I am here with Christopher White. And today we will once again be talking about the happiness of cows with Chris Zweck. Hello, Chris Zweck. Hey, you too. How are you doing? Good. How is your cow? My cow is happy, as is the cheese or the milk or I forget I forget where that came from happy cows make happy cheese happy cheese comes happy milk I don't you're right I don't could you tell us about yourself I'd love to I'm a embedded software engineer and I

currently work at iRobot I used to be a designer, so I've done a lot of the hardware up to the software stack. And I apparently was on the show a while ago, and we talked about happiness of cows and empathy and a few other things. And I'm here today to hopefully kind of continue that conversation in a slightly new direction. Cool. That's my plan, too. First, we have lightning round. What do you have? What are your questions? What are my questions are my questions what are his questions yeah oh what are your questions you have questions wait am i supposed

to have questions for you you've been on the show enough i would just break the show i just okay cat or hack hack not a cat person what is the date of the What is the date of the party? Oh, the date of the party? What is the date of the party? Yes. September 7th? That's correct. Will you be attending? Wait, I'm supposed to trade off with you.

See, you broke the show. Will you be attending? No, unfortunately, I will not be attending. Should people such as yourself who are not attending throw their own local parties? I have actually considered doing that over here on the East Coast. That's kind of weird. Favorite coding robot?

Favorite coding robot? Does one that I code for work count? Anything. You can interpret the question however you want. I'm going with Roomba. Favorite roading cobot sounds like so much of a robot that helps you christopher put that one in i i'm not taking ownership robot co-pilot your favorite robot

co-pilot oh oh favorite robot co-pilot oh uh who was the one in the Navigator? Flight of the Navigator. Who was that little... That was Pee Wee Herman. Flight of the Navigator? Well, he played it, so we're going to go with that. All right. Okay. I guess it's appropriate to ask this.

What is the favorite movie you haven't seen? The favorite movie I haven't seen? The favorite movie I haven't seen? We'd ask about the movies you have seen, but since we have talked about that before, this time it seemed better to just say what was your favorite movie that you haven't seen? Wow.

That's tough. There's so many ways to interpret that question. I'm going to go with the unreleased Star Wars, episode nine. Okay. All right. All right. That's cheap, but that's fine. Cheap.

What is it that you say about your father when he's using an axe inappropriately? A chainsaw. Inappropriately. A chainsaw. A chainsaw. We swapped questions, didn't we? Yes. You got to be careful with the chainsaw question. Okay,ropriate. Chainsaw. Chainsaw. We swapped questions, didn't we? Yes. You got to be careful with the chainsaw question.

Okay, go ahead. What is it? It is a Czech phrase that is... Which translates loosely to, my dad cut himself like a cow. A lot of cows going on. Yeah, that's actually true. That's true. Not a flattering angle, perhaps, but yes.

Okay. I have a couple of announcements. We're having a party here in Aptos in California near Santa Cruz. And if you want an invite, you need to go to embedded300.eventbrite.com. And then you sign up there, you say you're coming, maybe volunteer to help out. And then the week before, you get an invite, which you will need to get into the party. Cool. Also, people wanted mugs.

So I made mugs. They're on Zazzle. They're kind of expensive. We don't really get much money from them. But you wanted mugs so i made mugs they're on zazzle they're kind of expensive we don't really get much money from them uh but you wanted mugs so i i did it so buy them they look good i've seen them i have a question why is it embedded 300 why is that the url what's the significance of 300th episode celebration whoa Whoa. Yeah. Yeah, it's all about us. We've done this 300 times. Well, we haven't yet. We will have done this 300 times.

Soon. Soon we will have done this 300 times. Which is 259 too many. All right. One more announcement related to the party. Right. And related to Svek. iRobot, where Svek works, has generously donated some prizes that are the Root Coding Robot, which is teaching kids how to code.

And they are surprisingly adorable. So, yeah. Bring a cat. Bring a hack. No, wait. Don't bring a cat. You can actually, but don't. Bring a cat, bring a hack. No, wait, don't bring a cat. You can actually, but don't. Bring something cat-related. Don't bring your cat unless you want it to get lost in the forest.

Wear a cat-themed something. I have no idea how we're giving out prizes. I admit it now. I'll go up with something. Okay, now on to the show. You have, so you introduced yourself as a senior embedded software engineer or just an embedded software engineer, but you've been doing this for a while. And you have a new role as part of your job. Chief Bibbidi-Bobbidi-Boo?

Oh, I only wish that I could have a carriage and some mice to do my bidding. But no, I have a slightly new role. It's kind of a, I guess, technical lead is the title. But basically, I'm getting to kind of turn my attention more towards sort of higher level architecture. How do we sort of redesign or not redesign necessarily, but how do we design and how do we evolve our code and our code base to making it more maintainable, more extensible, fewer bugs,

kind of the motherhood and apple pie stuff. But it's kind of a step back from the day-to-day coding, you know, for a story for a particular sprint or for a particular robot, but instead overall, how can we make the organization move faster, more efficiently with fewer bugs? And so yeah, chief bippity, yeah, chief, I like it. I'm going to go with that. Okay. So how do you make your organization move faster with fewer bugs? It's pretty easy.

You stop counting bugs. You stop counting bugs. And then there's zero. And so, like, that's done. And the moving faster part is you just, you stop, you stop thinking and you just code. You just sit down and you code all the time and you stop, you know, no thinking, no design, no documentation. You just go. How long have you been in this job?

Actually, I'm running for a new job. No, no, no. I mean, it's, it's in fact the complete opposite of that. So, you know, there's all kinds of big principles out there with, you know, how to structure software, how to do architecture. There's clean code. There's clean architecture. There's, you know, tons of books out there. When I was talking about this with my management and kind of talking about this role and sort of a need to step back and sort of design our code, not just for the next year, but for the next three years

and five years and beyond. Um, I kind of sat down and I typically try to start with a clean sheet of paper. When I do these kinds of things, I try to start, okay, you know, if, if I had, if I had sort of a magic wand, if I am in fact the chief bippity boppity boo. And I could wave a magic wand. What would I want? And the goals that I came up with are basically fewer bugs and easier and faster new feature development. Isn't that everybody's goal? It is everybody's goal, but I don't know that people are allowed to sort of have that goal and work towards that goal on a regular basis. Certainly it's rare that somebody's in charge of that. Yeah. I think a lot of times it's you're in charge of

shipping this product next month and your job, like if you make any decision and there's any trade-offs, the decision you need to make needs to be in favor of shipping it, you know, August 1st or whatever it happens to be instead of, oh, by the way, we plan to be in business for the next 50 years and we want our software to let us continue making changes that we have even thought of over those 50 years. And maybe the code base, I mean, obviously it's going to change a heck of a lot in five years, forget about 50 years, but how can we be more intentional about writing fewer bugs,

creating fewer bugs, and making it easier and faster to create new features and have that be a top-line goal instead of shipping product A and product B on whatever deadlines they have. When we were at the Computer History Museum recently, I saw a bunch of things from IBM early days, and all of it was centered around think with an exclamation point. And it was what they were exhorting their employees to do. Sort of rude. Well, I thought it was kind of nice, actually,

because sometimes we're just told to code. Yeah, but if you got that as a code review comment, what were you thinking? Are you returning to those days where you're telling people that they should be thinking more and thereby getting more? Think harder, work less. What is it? Work harder, not smarter.

Nope. Nope. Nope. Other way around. That is, in fact, what it turns into when schedule crunch comes down, isn't it, though? Don't think about it. Just do it. And so, yeah, I'm hoping to do the opposite.

Hopefully, now you've got it turned around in my head. I'm not even sure what the right way is. I always say it the sarcastic way, so that's why I can't say it the right way. Work smarter, not harder. I see. I see. Yes, that's what you want to do. Yeah. yes that's that's what you want to do um yeah so many many moons ago many episodes ago

a billion and a half years ago uh you came on the show and talked to us about empathy driven development you remember what you said can you summarize it it? Sure, sure. I can. I can. Go back to that episode. What episode was it? In the 70s or something? It was called Happy Cows. And what I said was what I still believe is that to make better products and to make a better working environment and just really better everything, we should have empathy. We as the software engineers should have empathy for the customer, which is sort of a no-brainer and that's common enough advice that you hear in industry. But the slightly nuanced piece that I sort of was talking about is that we should also have empathy for each other as software engineers, our fellow colleagues, whether they're junior or senior.

And we should also have empathy for our future selves. And what I mean by empathy here is think about who's going to have to be consuming your code. The compiler has to consume your code. We know it has to compile, probably without warnings, hopefully, and it has to run and do pretty much the right thing. But the compiler is kind of a necessary but not sufficient consumer of the code for what i think is a better long-term experience for the developers and for the customers eventually and for the kind of the software to to live on and have everyone enjoy working with it um so when you write code you should comment it and document it and write it in a non-clever way to to quote dennis jackson from the show and think about who is going to have to pick it up after

you have either moved on or after you've forgotten about it. If you yourself pick up your code in a year, you probably don't remember why you did some funny things in the code. And so you should have left yourself either some comments or some breadcrumbs or redesign it. So it's not clever. So it's not sort of opaque. And so that you can see what's going on with it. So that's, that's what I mean by empathy driven development. We should consider empathy as a first rate, a first rate, you know, design goal of the code. Does that sound about right?

That sounds about right. Yeah. It's sort of be excellent to each other and not just the customer, but to your fellow developers. And yourself. And to also make sure that you don't be mean to them when they make mistakes. That's part of empathy is acknowledging fallibility. Yeah, yeah, absolutely. Because, I mean, if you are someone who is perfect, you should still be able to imagine that, well, if I made a mistake, how would I want to be treated? I think the other way, kind of a positive side of that, too, is that you should be free with praise. And if you see someone doing something well or if someone helped you or someone explained something or if you see code that, wow, that's a really succinct and clear way to put something that, you know, I don't think I could have explained that clearly.

Thank someone for it. You know, thank them for their effort. Thank you for their time. Thank them for their insight. And that's another way to sort of build positive. I mean, I don't mean to get like super touchy feely, but the fact is we're, you know, we're emotional creatures and getting some positive feedback on your team or at work makes everyone a little bit happier. It makes us enjoy our job more. By the way, if you get an email from me at 3 o'clock on a Tuesday, it's not saying thank you. It's not because I have a reminder that says thank somebody who would do that.

That's so weird. So going beyond... Who are you talking to? Anybody who gets an email from me thanking them at 3 p.m. on a Tuesday should know that that really, of course it wasn't planned ahead on a scheduled repeating. Yeah. Okay, so, sorry to distract. So the empathy-driven development makes sense.

But that was a few years ago. And you've been thinking more about hope. I get empathy, but hope? Yeah, hope kind of fell out of fell out of me trying to figure out what to do with this sort of more architectural, technical, technical lead role. And as I was thinking, okay, you know, motherhood and apple pie, fewer bugs and easier and faster new feature development, like that, that ain't rocket science. Like there's no, there's no new, new real thinking there. But so I thought, okay, how do you, how do you get there?

Now there's a billion books out there about it, but again, I just start with a clean piece of paper and I'm thinking, all right, if I'm going to sort of live in this future, let's imagine that I live in a future where we have fewer bugs created and easier and faster new feature development, then what do I hope for? What I hope it looks like is that if I get a new feature to develop or, you know, a new story or a new task or whatever, whatever your workplace calls it, then I will have a pretty easy time figuring out what file to open, what part of the architecture this new feature goes into, what other parts of the architecture or the code the new feature interacts with.

I'll have a set of tests to run it with. I'll have an easy way in infrastructure to write new tests. And if they break, then I will be able to see why they broke and then fix them. And then when I do a commit and a pull request or whatever code review system you might have at your workplace, that my colleagues who don't know exactly what I just implemented will be able to look at my pull request, look at my commit and say, oh, okay, I see that, you know, Chris edited this file to add his new feature. And it's pretty clear to me how he did it in 10 lines or 20 lines or a hundred lines of code. And, oh, I see that this unit test over here broke because the new feature interacts with some older feature in a weird way. And I see that, you know, it got fixed by changing a couple,

like one more file. And it's, it sort of makes sense. There's not 50 files to go hunting through. You don't have sort of accidental complexity of where, you know, you want to, you want to change a message that goes from one process or do another,, you want to, you want to change a message that goes from one process or do another, you have to edit 17 different header files, because the data is all kept in slightly different formats for different chips, you know, none of that kind of stuff. And that it would be reasonably straightforward, you know, then your code gets merged, and the feature works as expected, there's no regression, there's no bugs, there's no new bugs, there's no regressions that kind of come out of that. And your feature is bug free. Furthermore, that the experience

during this process was was pretty positive, you were, you know, sure, you were frustrated when you couldn't figure out something, something you were doing wrong, or something that was a little confusing. But overall, you came to work every day during this thinking, okay, I'm looking forward to sort of working on this and getting it working a little more and understanding a little more. And then finally, you're, you know, you're glad to have it done, because you're not because I'm glad that's behind me, but because okay, I feel good about that. And I know it will help the product in some way. So that's, that future is kind of, again, it's kind of, it's kind of touchy feely, there's not a lot, there's no technology involved in that necessarily, but I have a hope that, you know, by working,

working through our code in a way, in an intentional way and designing things and doing something, I don't quite know what yet we can get to the future that looks kind of like that, where, where there are fewer bugs and things are easier, uh, easier to develop for new features. And I come out of that and, you know, and you know i'm a sucker for one word or simple explanations and so i come out of that and i think hey that's my hope and so that's that's how empathy kind of goes into hope how is that different than just this is my goal hope has a faith aspect to it i guess that i have faith this is going to work out. Goals have a plan aspect. Yeah, so I do not

claim this is a rational train of thought here at all, but the train of thought for me went from... What's that? I'm just exploring. Yes, exactly. It's okay. Look, the simple goals are fewer bugs, easier and faster new feature development.

So what would that look like if that were true? And then I came up with this whole scenario I just told you about. And then at this point, I have no steps. I have no process for how to get there. But all I can tell other developers, other people in my company is, this is what I hope for. This is what it looks like. What do you think about that?

Does that look like a future you would like to have know to have how does that compare to how we do things currently so that's that's kind of how i start with a goal and then i come up with sort of fleshing out what it would look like if we meet that goal and that's that's the hope the scary thing about utopias is that there's always a dark underbelly i mean i read aldous huxley is that supposed to be utopia brave new world oh yeah it was totally utopia except for the whole killing everybody over 30 i thought it was logan's run all right was that carnival maybe it was brave new world too i can't remember anyway well that's that was the brave new world was like alphas and betas and gammas that was Maybe it was Brave New World too. I can't remember. Anyway.

Brave New Worlds was like alphas and betas and gammas. Was that it? It was a drug. Anyway, we're getting off topic and we all don't remember this book. I'm a little dismayed that we went from hope to utopia to dystopia. So let's... That's how it goes. What are you thinking there, Alicia? Well, that's...

Yeah, that is kind of my question is, okay, so you have this, this hope, this utopia. And how do you, how do we, how do you really get there? I mean, how do I get to the hope, the hope for reality? Yeah, I mean, okay, so the path there is very unclear. How does it affect what you do now? Yeah, that's a great question. And let me take you with the train of thought as I was kind of going from this goal of fewer bugs, easier and faster new feature development. And then I have this hope where I, you know, kind of sketch out this, what it might look like to actually work in that, in that sort of an environment, if we actually achieve our goals, the, the, the thing that I realized is this,

as I was kind of thinking through this or thing that I was reminded of is that what, um, what we hope for or what we kind of pay attention to actually changes our brains. And so if we hope for something, that something is more likely to come true than if we aren't looking for it. You know, we tend to find what we're looking for, unlike what Bono says. We do tend to find what we're looking for. Having a goal and a hope that we can achieve that goal actually primes our minds to see things differently. It helps us focus on things that align with that goal. And there's a bunch of research about this, but there's a video on the web that was done by, it's a video of an experimental psychological experiment. And what they did is they have, I think about seven or eight people that are dribbling, who are dribbling a basketball.

And you, as the person viewing the video, are asked to count the number of times, I think, some of the people, some of the players are dressed in black uniforms and some in white uniforms. And I think they say, count the number of times the ball is dribbled or the ball is passed by the people in the white uniforms, whatever it is. And we'll have a link in the show notes, hopefully, to the actual video, and you can watch it. And the video is like less than two minutes long. And so you sit there and you watch and you count, okay, you know, person in white uniform passed a person in white uniform.

And again, and again, you get to like seven or eight, whatever it is, you count it up. And like I said, it's less than two minutes. And you know, the people in the black uniforms are passing to each other, the people in the white uniforms passing to each other, you've honed in, you've been primed, you've been told, look for person in white uniform passing to person in white uniform, and you count. And they say at the end, okay, it was eight, and you counted eight. Great, you paid attention. And then they ask you, did you notice the person in the gorilla suit who walked through the video? And you think, well, no, that's crazy. And then you watch the video again, you go back and look at it again. And in fact, in the middle of the video, somebody walked right through the scene wearing like a human being, wearing an ape or a gorilla costume.

Allegedly a human being. We don't know. Allegedly a human being. It could be a real gorilla. I have no idea. Stops, waves at the camera in the middle of the frame, in the middle of the scene, and then walks out. And they're probably on screen for like 15 seconds out of maybe a minute or a minute and a half video. So not, it's not like, you know, one or two frames of video, they blur through, it's in there. But because your brain is primed,

your brain is told, look for white uniform, pass into white uniform, basketball. That's it. Your brain ignores everything else. And I think the study I saw said that 50% of people who saw that video did not notice the gorilla walking through the frame or walking through the video. And I, the first time I saw it, I also didn't notice it at all. And I actually was wondering what kind of, what kind of YouTube trickery was this that, uh, that, you know, the monkey, they, they must've put in the gorilla afterwards, but no, your brain is really good at seeing what you've been told to see. And so if you watch the video, there's actually a couple other things that happened in the video.

I won't spoil the whole thing. In the newer video, yeah. Yeah, in the newer video, they've added a couple other things that you probably won't notice, and you'll be maybe surprised that you did, but maybe surprised you didn't. And so in thinking through that and realizing that, you know, attention definitely primes our brain or rather having a goal or having hope or whatever, being told to focus on something that primes our brain to pay attention to certain things. And so I started thinking through that a little bit more. And if we assume that our pile, that our code is garbage, that our code is just bad and that we have bit rot and we have entropy and it's just going to make our code worse and worse. And there's really nothing we can do to that our code is just bad, and that we have bit rot, and we have entropy, and

it's just going to make our code worse and worse, and there's really nothing we can do to help our code, we're going to be right. We're going to notice all the worst parts of the code, we're going to get more depressed and more cynical about it, we're going to talk about our code sarcastically and negatively, and we'll complain about it. You'll earn the right to say, I told you so, you know, this code is terrible, I told you we couldn't make it any better. On the other hand, if you have hope that our software will improve, that it'll become easier to understand and extend it, and there'll be fewer bugs, then you'll also be right.

You'll notice the good things in the code, and you'll think about how we can make it better and how we can take the things that aren't good or aren't great right now and make them a little bit better step by step. And you'll earn the right to say, I helped make it better. Now, this sounds totally sort of like a little bit loopy, but I'm not being delusional here. What I'm suggesting is, what I'm not suggesting is that we lie to ourselves. And we say that our code's awesome. It's only going to get better. We're

never going to have bugs. I'm not suggesting any dishonesty or trickery or anything, even remotely approaching that. What I am suggesting is that we intentionally pick a worthy goal that this hope that I'm, that I'm espousing and that we have hope that we can achieve that goal through hard work. So I just said a lot. Does that make sense? Does that sound at all believable or does that sound like I'm trying to sell you something? Well, for me, I'm, I mean, I've read a bunch of psych books. And so, attentional focus is one of those things that they tell you is very important in humans. There are lots of ways to fool people by taking away their attention. That's how magic and mentalism works. You tell somebody

the number three when they walk up, and then five minutes later when you ask them for a number, there's a good chance they're going to say the number three, even though they forgot that they had that attention. And so if you pay more attention to the positive things, not ignoring the negative, just more attention. Saying thank you to your coworkers. Noticing when people did something nice. Noticing when the check-in comments were actually relevant. These things, they do help you find other things that are good, other areas of positivity, and they are likely to help you mentally weather the storms of bit rot. Okay, so we have that. You also had a thing about people hoping for themselves, like imagining a better code base.

Yes, yes. That sounded a little depressing to me. I mean, when I imagine a better code base, it's like, well, I can't get there. I don't have the power to make it happen. Yes, it absolutely could be. You know, that's another psychological thing where if we feel like we don't have any control and we don't have any power and things are bad, that's a lousy place to be. So I'm guessing your next question is going to be like, what can I do if I'm not in a position of leadership? I'm not in a position of, you know, no one does what I tell them to do.

If I make suggestions, I don't get heard. If you're kind of the low person on the totem pole and you feel like you don't have a lot of authority or autonomy, what do you do about it? Oh, you don't have to be the low person on the totem pole for that. Oh, you're sorry? Perhaps the higher you go in the totem pole, the less change you can actually make happen. Sometimes it feels that way. I'm sure. I'm sure.

I don't have a great liking. There is no silver bullet. In fact, um, what I can suggest is I actually came across a blog post recently from Seth Godin, who is this marketing marketing, marketing guru. And he's a lot of pithy statements, but a lot of them ring true. And, uh, he's got his post recently called, uh, three wishes. And it's, uh, it's, it's. Basically, he says, when you're feeling stuck with a project, when you are feeling like things are bad, you can't figure out what to do next,

he says, grab three index cards. And on each card, write down an element of the project that if you invest the time and money would change for the better. And if those three things happened, if those three things that you wrote on your index card actually changed, what would happen to your project? Or what would happen to your little part of the project or your file or your bug or whatever it is you're working on? Then he ends it in a very Seth Godin sort of style where he says, Okay, now that you've got all these three ideas on the cards, what are you going to do about it? And it's kind of a dare, it's kind of audacious. It's kind of saying, okay, so you have the mental capacity to think, like IBM used to say, to think about what can be improved. And you've just written

them down on a card. And that means you have it staring at you in black and white. And so what are you going to do about it? Okay, so first of all, I have to back up. So what we're talking about here with hope and with improving your code base is like way up on Maslow's hierarchy of needs, right? So if you have a truly toxic workplace, if you, you know, are truly, you know, it's just a bad place to work. I don't know that any of this stuff can work, but if you're at a reasonable place to work, which, which I hope that you are, then you should have some time in your day where you can do some work that isn't necessarily on your, you must do this next because the project is shipping in 15 minutes work. Now, okay, if the project is shipping in 15 minutes, you should

probably just do that work. No, you should be out of your hands. Yeah, that's true. I guess if you're a web developer, 15 minutes, you push an update. And with OTA, with over-the-air updates, you can push it to robots all over the world. Why not? But you should be able to carve an hour out of your week. I would hope that you could carve an hour out of your week to do one of those things on your index cards. And if the index card ideas you have are all like rewrite software in different, better language or some other similar things, maybe you should get smaller index cards and maybe just start with like little, those little tiny sticky notes, at least for that size of idea. But if you can think about moving things forward,

1%, improving things 1% a quarter or 3% a quarter, then after a year, you'll have things at least, you know, 12% better, whatever the math doesn't work out like that but my thought here is that if you can just move the ball down the field a little bit every month a little bit every week a little bit every day then eventually that adds up and you may not feel that you have you know you probably don't feel empowered at your job to make across the board changes to say we're going to change everything and we're going to do it this way now um and even if you could, you'd probably be wrong if you just start making decrees from the top and you don't know everything, your coworkers don't know everything. So you probably want things to be smaller changes or iterative changes that come in over time instead of a giant hammer that

changes everything all at once anyway. So making these small changes, 1%, 2%, 3% of time, a quarter, a week, a month, a year, whatever, as those build up, hopefully, again, there's that word hope, will lead to some of these better goals. If everyone's goal, if everyone's hope is that, yeah, fewer bugs, easier, faster development, you'll start to see things, see opportunities to do 1%, 2%, 3% improvements over time. You put them on a list, you prioritize them, and then as a team or as an individual you you knock them down you and hopefully over time things get better so i still think this requires in a lot of places some buy-in from people who control your work life because most places are doing some form of scrum slash agile these days and so all work

shows up on the big board with points associated with it so it's it's very hard to do kind of stealth tech debt improvement and have it fly under the radar somebody's going to see it somebody's going to say there's a potential for somebody to say why are you doing that now instead of this over here um i didn't allow you to bring that ticket into this sprint so and that's not necessarily toxic that i mean it's sort of toxic but is it you know this over here. I didn't allow you to bring that ticket into the sprint. So, and that's not necessarily toxic that, I mean, it was sort of toxic, but is it, you know, most people would characterize that as this organization is broken. So do you have any thoughts about how to get around that sort of thing or is

it just get buy-in? Well, yeah, I mean, so yeah, I did, I did totally focus on like the smaller stuff. So everything I kind of talked about in a very long winded way was the smaller stuff, the stuff that you could add into a sprint, so yeah, I did totally focus on like the smaller stuff. So everything I kind of talked about in a very long-winded way was the smaller stuff, the stuff that you could add into a sprint, you know, into a current story, maybe document it better, maybe, you know, add another unit test or do something that doesn't look like, oh, I'm doing a completely different line of work than I should be doing. So on the larger work, then I think the way you start that is you, you have to, you can try to find another

like minded individual on your team or in your group. And, you know, start talking about, hey, man, you know, I really wish that this would be better. I really wish that this unit test infrastructure would be a little bit easier to write or man, this this piece of code over here, I am scared to wander into this file, because it is a bunch of untested, or it's a bunch of code that has no tests. And every time someone touches it, it seems to break about 50 times until we, you know, smash all the bugs again. I wonder what we could do about that. I wonder if we could kind of make that better. The trick here is especially if you go talk to your boss, you know, if you have a one on one say, you know, this file over here seems to get buggier over time. I wonder what we can do about

that. And by asking people for your opinions, first of all, you're saying, hey, here's this thing. And it's broken. And it's not as good as it could be. I see that it could be better. What do you think we could do about it? So you're having your colleagues and your boss kind of shared ownership of a solution. And as more people start to think about things like this, you know, your boss says, you know, that unit test infrastructure is kind of rickety, or that that file is kind of a bug farm. If you come in with data and say, hey, look, every literally every time this file changes, we get two more bug reports, you know, from customers, maybe we should do something about that. And that is a way to kind of market I mean, and this is this is I'm using

the word marketing intentionally, or using this is the way to market your ideas and sort of sell others in your organization, your boss or your scrum master or the project owner or whoever, whoever needs to be sold on things, but say, Hey, here is a problem for the customer. Here's a problem for the product. How can we, how can we fix it? What if we tried X to fix it? What if we did this work to fix it? What if we, you know, you're suggesting solutions or you're trying to get other people's ideas on solutions and the problems you're solving are problems that the customer has, problems the product has, problems the organization has, not, I want to go rewrite this thing in a different language because I think it would be fun. That's hard. I mean, that's, that's really hard.

Yep. It totally is. It totally is hard to do this kind of thing. So I see why you're using a positive, optimistic word like hope to describe this. Because otherwise, the words I would choose would be less positive. Like what? Slog, political maneuvering, manipulatinging, um, manipulating for results. Um, tech debt,

just, you know, tech debt doesn't sound very good addressing tech debt. You know, nobody likes paying their debts. Um, you know, the terms we tend to use for this sort of stuff are fairly negative or have

negative connotations. So, I mean, I get what you're doing. Yep. Um, and, and I think it's a good idea.

The interesting thing about tech debt is that it is a very negative word. I feel like when things get thrown into tech debt, you're working on something you want to ship in a month, and we would really like to make X better, but we don't have time now because we need to ship something. So we're going to put that task as labeled as tech debt. That is the correct decision. There is nothing negative about that. because we need to ship something. So we're going to put that task as labeled as tech debt, right? The that is the correct decision. There's nothing negative about that. I mean, debt is kind of a bad word, right? But really, it's a deferred feature. It's a deferred change. And we are making the

right decision to keep, you know, keep customers happy to keep the revenue coming in so that the lights stay on that my salary keeps or my paycheck keeps clearing the bank. Like there's nothing bad about the decision at all. And the, if there's no sort of similar business argument where basically we get more revenue or we do not lose revenue by doing some tech debt, then I would argue, maybe there's no reason to actually do the tech debt. Maybe that's just a feature you don't ever do. The, the, you know, the, the stuff that I talked about, the goals that I, that I set out at the beginning of this fewer bugs and easier and better, easier and faster new feature development. Those are chosen because those are things that are good for the business that are good for the customer that keep revenue coming in that increase revenue that let us sell more products faster, that make customers

happier with our products because there's not more bugs in them. You have to choose the right features, the right bugs to fix, the right tech debt to take on and tie it to a business case and actual value to the company. Otherwise, you're just rewriting something in a new language because you feel like solving a new technical problem instead of a problem that actually generates revenue for the company does that make sense yeah i think so i think um tech debt without any justification for it is not really tech debt right it's it's something i'd like to change that's not necessarily valid. But I think with your goals of, you know, better, faster development, fewer bugs, oftentimes tech debt feeds into that where I can't work as fast as I would if this particular module was organized better or if the build system was more efficient or, you know, those kinds of things. So I think it makes sense. But you have to, but those kinds of things, like it, it would make us better as engineers are hard

to quantify. So if you are talking to management saying, look, we want to do this, it's kind of hard to go in there and say, it'll make us better, but we don't know how much, you know? Yep. Yep. And that's, you know, that's where some of the, the hard work comes in and, you know, it's tough. Jack Gansel, one of the things I've taken is his Better Firmware Faster seminar a couple times. And one of his main things is if you do nothing else, if you do nothing else, okay, we had 10 this week and nine this week and eight the week after and seven the week after. So, okay, we're getting better. Or the other way around, we had 10 this week and 20 next week and a hundred that week after that, we're getting worse. Basically, if you don't measure something, then you're going to have a hard time sort of responding to it. You're going to have a hard time understanding it. And so as you're trying to figure out what to do, any way you can quantify is going to, first of all,

make you understand it better. So if you can count the bugs you have, if you can try to relate how many changes to a file result in bugs, try to figure out where the bad parts of your code are, how long it takes to do a build, a complete unit test, clean build of your system, or how long it takes to check out your code and do a complete Jenkins build of it or whatever. Anyway, you can quantify it, then you

can see are things getting worse for things getting better. And you can, you know, if you can go to your manager and say, Look, it takes two hours from the time I had go to get back the result of, you know, it did the bill is the build clean into the test pass before I can make a commit. And during that time, I'm effectively stalled, and I can't do anything else. And I can go work on another ticket, but it sure would be great. And here's my idea for taking that time from two hours to one hour. And by the way, since most cloud builds, or most builds are done in the cloud nowadays, that actually, that actually saves money. Like if you can cut your build time down in half, that cuts your AWS build down in half, or whatever, whatever cloud

cloud system you're using. So there's some metrics that you can use that actually help the business. And that are saying, again, we're not tricking anyone. I mean, you're not trying to like game the system, but Hey, look, here's an actual benefit we can measure. And I think it'll be by reducing by half. We'll make our, make our, you know, development flow faster and we'll get new products out faster. Chris asked, uh, Christopher, my christopher my co-host my husband asked about fully identified now not quite but i'll stop there um asked about where this goes in a scrum but i have it and and that's part of my question here. Also, you mentioned rewriting in a different language as a goal, which I know you're using as kind of not a good goal, but we all know that

somebody wrote that down as their goal. And you're talking about an hour to a week, which I think, yeah, okay, that's doable. But how do we figure out if your, I think this code should be rewritten, is about this hope and optimism and having fewer bugs and writing faster versus know-it-allism. That's a realism, right? This would be better. You've done it wrong. If only you followed my path, it would be better. And here's the path. And if you don't, you're all idiots,

and you should know that the code will be slower to develop. Really, you should just go ahead and rewrite it in Rust. I didn't need to go there um but okay so backing up before the the language change um there is some of this there is there is some of this if we just well that goes back to empathy you can't do this without empathy i think that's the thing is you this falls apart if you don't have a team that's conscientious and has some, you know, cohesion. But it's really hard to have people come in and say we should change all this stuff when I have features to finish. Yeah. So what the way the way that I think this might work best.

And the reason that I suggested backing up a little bit, the reason I suggested, you know, start talking this over with a colleague, talk it up with your boss, talk it over at lunch with your, you know, your friends from your, from your, your, um, your team, or even you're not friends from your team. Start talking these things over and kind of socializing them. And you're not, again, you're not trying to like trick anyone. You're just trying to say, Hey, I think this is a problem. What do you think? And if everyone else looks at you, like they don't know what you're talking about and they love the way the build system works. So they see no problem with it. Maybe you're not going to get a lot of traction with it, you know, and maybe that's not the, that's not the, that's not a thing that will be changed. Um, what I'm not suggesting is that someone comes in, me or anyone else, no matter how senior, comes in and says, all right, we're doing it wrong. We're going to do,

we're going to scrap what we're doing. And instead, we're going to do A, B, C, D. That's all we're doing. And I don't care what you're working on. I don't care what any of you think, but sort of by decree, we're doing this. I don't think that's the right way to do anything. I just don't think that's going to work for a number of reasons. I think what's better is, you know, you start sort of socializing an idea, shopping it around, seeing if other people on your team can kind of get behind the idea of like, I wonder, I wonder what is what is kind of painful, what is kind of annoying to do. And then once you get a list of five, six, seven, 10 things that are kind of annoying to do, then and by annoying, I'm saying, this code seems buggy.

This code seems slow. The build system isn't as fast as it can be. Or this thing is not deterministic. Or, you know, whatever sorts of things you want. What I've actually done at work is someone else suggested a title. And so basically I asked my coworkers, I said, hey, all right, we're going to start doing, having more time to develop, to kind of step back and do some more architectural higher level work. What things should we focus on?

Because, you know, I've been at iRobot six years. I know a lot of the code, but I don't know more of the code than I know. Right. We have a lot of code here. And so I said, hey, what kinds of things bother people? I said this in a team meeting, which is specifically for this. And so someone said, oh, you mean like airing of grievances. And so now we have a wiki page that is called the airing of grievances, which is inspired

by Festivus from Seinfeld. And on this airing of grievances wiki page, any of us in the company can go in and put the parts of the software that we think are broken or slow or frustrating. And I've got about a dozen things on there, maybe 10 things on there that I put a few on there to kind of prime it. And then other people have slowly been adding different things as they run into, wow, this branching strategy is painful or this code over here, the way we do GPIO abstraction kind of breaks when you use header files like this. And they're across the board.

There's some things that we can never fix and some things that could actually be fixed in about five minutes. Once we have enough things in that list, you know, we can, again, shop this around to management. We can shop this around to coworkers. As people sort of see this as a problem, then we can start saying, okay, boss, what do you say we put a ticket in to fix one of these next time and then i think there's fewer bugs as a result of this or i think there'll be you know something better as a result of it there's absolutely no guarantee that management your manager is going to buy into it there's no guarantee that your product manager or your whoever's doing your your story you know scrum sprint decisions is going to buy into this but the only way to even give them a chance at agreeing

to it is to have a list and have some justification and suggest it. This sounds exhausting. You've asked me to give up my lunch to do political maneuverings. You've asked me to talk to my coworkers and invent new work when we should be shipping a product, you asked me to spend free time that I could be spending writing funny Twitter jokes, instead worrying about the companies who doesn't really care for me. Wow. That's pretty cynical. I think I'm going to shorten that. You've asked me to cast aside my well-honed cynic instincts for optimism, and that might be difficult. That is difficult. How do you turn people into optimists?

Optimists are suckers. Optimists are suckers. They are such suckers. They are, however, happier, and they live longer. So, maybe you sell them on that. Yeah, they probably wrote that study. are suckers awesome optimists are suckers they are such suckers they they are however happier and they live longer so maybe you sell them on that yeah they probably wrote that study they probably did they probably did oh man but yeah yeah i mean it's true so tech nerds we love we love cynicism you know we love snark and we love we love i don't i'm sorry i hate it you're starting to hate snark you're over sn're over snark? I am over snark.

Well, cynicism is part of showing geek cred. Yes. It is, isn't it? And while I might have actually tricked you into this, I do want to point out you were the last person to post Ngate to our Slack channel. I enjoy snarky humor and cynicism as much as the next person. However, so I started my career at AMD, um, which is a great company to work for, you know, design chips there for a long time. I started there. I was fresh out of grad school and I started in July, I think. And I think in, in July or maybe July or August, they announced, Hey, guess what? In October,

we are laying 20% of the company off. And so I'm coming out of school. I started work in 2002. So the job market, the tech job market was not in a great place. Um, my wife couldn't find a job because a lot of, a lot of things were just not great economically in 2002. And, uh, it was August and I knew that I had basically until October. And then I'm thinking, look, I'm the new guy on the team. Of course I'm getting laid off, but you just kind of sit there and wait for three months. And I think that like dialed my cynicism and my negativity about like job stuff up to 11, right? And so I did not get laid off thankfully. And I ended up being, I wrote our, being an AMD for, for a number of years after that. And then I'm leaving of my, of my own free will. Um, but it's sort of the, the, the die was cast and I was quite cynical then a believing of my of my own free will um but sort of the the

die was cast and i was quite cynical and a lot of people you know a lot of people in tech are cynical and so it's easy to find fellow cynics um i i would come home and i would you know make cynical comments around my wife or to my wife and uh and eventually she was just like wow this is really negative why why are you this negative even if if, you know, parts of your job aren't great. Like it's bleeding over into the home life. It's bleeding over into my... Why are you looking at me like that? I'm getting laser eyes from across the room.

Laser cynic eyes, laser cynic wife eyes. I think she was identifying with your story about bringing home anyway. Yes. Yes. It is very easy to bring home a negative attitude. I feel like it might be easier to bring home a negative attitude than it is to bring home a positive attitude. So, of course, I was cynical about my wife's pointing out my cynicism. And I was like, whatever.

Because you've got to double down, right? That's what you do as a good husband who has a wife who who loves you and gives you uh you know useful feedback in a loving way so you just double down on your stupid behavior but anyway that's what i did and thankfully over the last i don't know five to ten years i've sort of come around to realize that maybe being cynical all the time is actually not the best the best view and you can actually intentionally change that you can find yourself the very first step is to just notice when you're being cynical. Like it's a very Zen thing. You're not actually trying to change your behavior. Just try to notice when are you being cynical? And when you have a lunch conversation or when you have whatever, or listening to a podcast,

and if you have cynical thoughts, just recognize that to say, Oh, there, there it was. I was, I was kind of snarky. I was kind of cynical. I thought this is a stupid idea. And you might be right. Like for a, everything I'm saying right now could be completely stupid and asinine, and that's okay. But recognize when you are being cynical, especially in a work context, and then start to think, what would the opposite be? What would it be like to not see bad decisions or not to see bugs as a happy thing? Oh, I'm glad I got a bug. We're not,

we're not talking about that, but instead start seeing the things that are positive. Start seeing, Oh, Hey, my coworker helped explain something to me. Oh, look at this code. It actually is designed really well and makes a lot of sense to me. Oh, look at this little, you know, behavior that the robot did. That's, you know, someone worked hard on that and it works really well. Whatever you start thinking about, I wonder if i can find the positive things and eventually i have zero i have zero science on this i have zero data on this um but you can change your mindset by noticing when it is cynical and negative and i guess i'm i'm theorizing that you can change your mindset by noticing when you're negative and try to find positive things and eventually you can swing yourself to being a little more hopeful a little more positive and a little

bit less cynical if you think that cynicism is something that you kind of want to change and maybe maybe have a more positive outlook if you can um i mean that goes back to the attentional focus if you if you actually think about okay oh, oh, I just noticed. I was mindful that I was being sarcastic, being snarky. Now I want to cue myself to do something positive, to put my attention towards a positive direction, towards somebody doing something nice, towards being interested in the problem I'm solving,

towards the application of what I'm doing and thinking about I'm doing this in service to something good. Yeah, I mean, you should, once your attention has been trained to go somewhere else, I mean, there's lots of studies that show that. You haven't answered my question much about this is a lot more work for me. Yes, yes. I mean, I'm not asking people to start putting in four hours extra every evening to start doing this stuff. This is something that is going to start doing this stuff. Um, this, this is something that is going to require time and thought. And there's, um, there's a quote that kind of hit me a while ago that I've actually been coming back to for a lot of stuff at work,

especially when things are kind of difficult. And it's a quote it's, it's by, um, I read Michelle Obama's book, uh, becoming, and in it, she quotes Barack Obama. And she says that he says, what's better for us? Do we settle for the world as it is, or do we work for the world as it should be? And so regardless of what you think about Obama's politics, the sentence is, what's better for us? Do we settle for the world as it is, or do we work for the world as it should be? So, you know, you can sort of let things be and keep doing what you're doing, or you can try to make it better. That does not answer your question about, well, why are you asking me to do more work? Is this going to take more hours out of my day? That is sort of justifying why you'd even

want to do any more work, and that was to sort of, we have a hope for something, so we want to work towards the hope for a world as it should be. How do you find time for that? How do you make time for that? How do you take extra time for that? I don't have a good answer there. I think in a perfect world, or a good world, or at a good company, you shouldn't have to make extra time for it,

because doing this stuff should be a force multiplier as time goes on um it's an investment that should pay off so taking time away from feature development or what have you to to those kinds of things and to move toward a better more efficient organization uh should pay for itself but yep i do take elicia's point that you know i kind of made the same point as some organizations will have more pushback and you will have to uh exert more effort and that's just it depends on how committed you are to making things better i guess yeah now the you know the the sort of how committed you are and sort of how far you're willing to stick your neck out and sort of what level of effort you're willing to give at work. It kind of dances around the issue of professionalism. And so, you know, we are paid to work, hopefully.

And when you're at work, you are by definition, like when you're being paid to work, you are by definition a professional. Software engineers, whether you're, you know, a CS or a compy or physics or whatever you are, you know, you're working writing software, you're being paid to work, you are by definition a professional. Software engineers, whether you're a CS or a compy or a physics or whatever you are, you're working writing software, you're working doing electrical engineering, we're professionals. And as professionals, we're being paid to do good work. Now we can slack off or we can work a million hours a week or something in between, some optimal level of effort. But you get to choose what being a professional at work means. I believe that worthwhile professional work should result in a better future.

And I'm saying this one that I'm hoping for is the future that I'm sort of betting on, and that's the one I want to work towards. You can state your goals at work and look, I'm a professional. I want to make these changes. I want to have these force multipliers as something we do. I want to make things better in these ways. And you can make the statement as a professional. I see that professionalism and kind of what you see yourself as at work and the change you try to make at work and the work you try to do at work. I see that as part of

professionalism. I understand that. I understand using professionalism as an excuse to do the right thing. And it's something I kind of agree with. Sometimes it's good to say, no, I didn't finish my bug this week. I still have to write the documentation for it. Or no, I didn't finish my bug this week because I didn't finish all of the unit tests. You don't have to skimp. Now you have to make a good balance between dotting every I and crossing every T and then rewriting it in three different languages, or shipping things as fast as possible and not worrying about anything at all as far as tech debt goes but you do get to define your level of professionalism

i like that i like that bug like you're not done with the feature or with the story or with the ticket because you haven't finished writing all the unit tests. I want to go into that a little bit. And so let's say you spend a day on a ticket and on a bug and you figured it out and you know the fix and you've got some hacky kind of half fix, but sorry, you have a hacky fix that you want to improve, but you know what the bug is and you know how to fix it. Let's say it takes you four hours to fix the bug and it would take you four hours to write some extra unit tests for it. What you'd probably do, what I would probably do is I'd spend the four hours to sort of fix the bug right. And then if anyone asked me, I would say, yeah, I'm done, but I still have to write the unit tests. That gives someone the

opportunity to say, just check it in and move on. We don't have time to test. If however, I'm already aware of the fix and already know what the fix is, maybe I spend the first four hours writing the unit test or the first two hours, you know, fixing tests for it or writing new tests for it. And only then do I start writing the fix. And then if someone asks me after four hours, are you done with it? You can say, no, I've got a couple more hours work on it, I think. And then, you know, I've got a couple more hours work on it, I think. And then, you know, it's plus or minus two or four hours on a given story. I don't think that, you know, in a 40 hour week, two or four hours really shows up on anyone's on anyone's schedule. Now, I know, I know that, you know, okay, four hours is 10% of a 40 hour work week. But has your schedule ever been off by only 10% on any project you've

ever worked on? I don't know. Maybe this is not a good idea, but that's kind of my thinking. Does that make sense? Well, then you don't have to do it with every ticket. Your goal is to build a better world one step at a time. You don't have to go from your velocity of 20 points a week to velocity of three points a week because suddenly you have the shield of professionalism out in your. Yes. You have to balance and. Yes. Choose your battles. Yeah, I love that.

I love that. That's that's that's exactly. Yes, that's that's definitely much better than I said it there that you know the thing i said at the beginning you know you're going for one percent two percent three percent five percent a quarter if you can get that much better that will that will absolutely pile up and you never have to say hey i need a month to do this new task instead you just kind of uh wisely schedule it in when you can. But not every ticket, not every time, just like you said, Alicia. Let me ask you a slightly different question.

And I'm going to go on beyond the question for a second, so don't just start answering. But how do you maintain momentum with something like this? Let's say you get it started and things are going great for two, three sprints, and people have established the things they hope for. They've got them written down and they're, you know, they're making small changes every week towards those. I've been involved in some of these kind of working groups to improve things. And they didn't, you know, use the same language, but it's kind of the same stuff where it's like okay here's a problem and we're all going to work toward a better solution

and they fizzle out within like two months and then somebody says hey what was happening with that oh yeah we should get back to that um do you have any ideas on how to maintain some, some, uh, velocity with us. Yeah. So the, I mean, I I've seen the exact same thing happen. It's, it's any, any change initiative, anything that changes is hard to kind of keep up. Right. Um, you know, it's, it's especially something that's, you know, sounds like, sounds like a good idea, fewer bugs, more happier, happier work environment, whatever. It's all good. Right. And it's easy until it gets a little bit, a little bit old in the tooth, long in the tooth. So the, the only way that I can think of this kind of keeps up is to have someone and some, several people if possible, whose, whose job is to do this kind of work is that you have,

actually, I guess there's two things. One, I think the team and your manager and your management above, above your media boss has to buy into it as we're not just going to do, you know, today's work. We're going to start thinking about next year's work and two years now from work. And what kind of work can we do now to leverage our, to leverage our time now and have a payoff in multiples later. So you need your manager to buy off on it. And hopefully their manager as well. If you can get people whose job is, you know, I hate the word architecture, because it sounds like it's just like pie in the sky kind of thing. But if you can get someone whose job is not tomorrow's feature, but instead, next year's code base, or the you know, the next three products you want to develop, how can we make the code as modular and reusable as possible?

If you can get people whose full-time job is doing that kind of work, then they, I mean, that is their work. That is their stories. That is their sprints. You know, this is not something that a team of three that is the only engineers in the company that are shipping something next month, you know, they're not going to take one third of their one third of their team and say, you go work on work for next year. But at a certain size, an organization should hopefully have enough money in the bank and enough like recurring revenue that they can dedicate one, two, three, five, however many people to sort of more leverage. You know, the company is going to be around in a year. No one's worried about that. How can we make sure that next year when we want to introduce three products

instead of just one, that we can do that easier and faster. So that's kind of, that's the, that's the role that I have at the company right now. And that's, that's kind of my hope for how things play out. You know, it's funny. I, despite being a little argumentative, I really agree with your base notion that the way to get to a better environment, to get to a better coding system, to be able to do your job more fulfillingly, is to have hope and positivity and to imagine what would be better. But when you bring in management and upper-level management and teams and architects, I stop buying it

because I usually work in very small teams. And for them, they just need to go, go, go. And I don't feel like I have the power to slow them down. I do have the power to be professional, and I can slow them down that way, and I can try to do a little bit of what you were saying about predicting the future, and how can I make this better

and what are my three wishes. And those help me try to figure out how to make my job better. But I don't go in for the making nice with everyone and the political and the socializing my ideas. I really like the hope message though. So, um, so you'll have to come to the party so we can have a thumb war and duke it

out. Excellent. Excellent. I don't know if this works for smaller teams. I don't know if this guy, I mean, heck, I don't know if it works for us,

but this is, this is the path I'm choosing. So we'll see, we'll see happens to us. Um, you know, we're big enough that we can, I, I, I do not speak for iRobot at all, but if your company is big enough that you can afford one, two, three, four people

to do something that's not, you know, revenue dependent tomorrow, then I think this might be a good way to sort of get things better. I also want to, kind of one more point is that, you know, one of the things that we're cynical about in tech is, you know, bad decisions that are made elsewhere in the organization. You know, can you believe that this company did that or that this other company did that

or that, you know, HR changed this policy or whatever. We kind of grouse about stuff like that. The... You kind of... You end up with a sort of a feeling of powerlessness. If you just concentrate on the things that you can't control and you get upset about them. Um, not to say that, you know, everything that you can't control, it should be a pleasant, happy experience for you. But if you care about things that work that are in your control, you're going to have a much more positive sort of work environment. You know, if you get, if you get upset and are constantly holding on to things

that bother your work, but you have no control over, you're going to feel powerless and you're going to feel you're going to, you are powerless because you can't control whatever it is we're talking about. And you're going to feel kind of bad about it. If somehow you can focus more on the things that you can control than the things that you can't control and you do one percent two percent three percent better on the things that you can control i i think that's the way that that's one way to sort of make things better and you know this this three wishes thing you can do some of that a small company or a small group or you know even if you are shipping something next week maybe you can make things you know, even if you are shipping something next week, maybe you can make things, you know, 1% better a quarter instead of 4% a quarter.

But if you concentrate on things that you can control, you have less frustration about things you can't control. And you can do these onesie twosie percent improvements over time. You know, there's some political nature to what I'm talking about. You know, the whole like selling it to management, selling it to coworkers. The politics that I'm thinking of is kind of the sort of, this is how you communicate in a work environment sort of politics, not the backdoor politics where you're like lying and, you know, backstabbing kind of thing, but instead, Hey, here's what I think. If anyone agrees with me, let's talk about it some more. So I hope, I hope that's a more palatable form of it, but yeah, I, I get where you're coming from, at least. And I mean, I, you know, Chris, you said a little while ago, you guys like pushing back or whatever,

but this is great. Like, I, again, I don't know if this is going to work, but this is what I'm trying to check back with me in a year. And I'll tell you if, um, if my hopes are dashed and if I'm just sad again, I hope not. There's one more question about sort of this whole thing. And I wonder, as you programmers, engineers, of making mistakes, of being caught in mistakes, of having people celebrate the mistakes. We often try to hide or deny or yell so that nobody notices them. How do we make making mistakes less humiliating? Anonymous commits. Anonymous commits. Squash all history and have all commits be anonymous.

And change jobs every six months so no one can find you either. No, I mean, this has to be a cultural thing. This has to be something that, you know, the thought of celebrating mistakes has always kind of rubbed me the wrong way. Because, like, you don't want to encourage mistakes for the sake of mistakes but you don't want to punish a mistake um so as as a senior person um the the only thing i can do is sort of do things by example and so i will i try to publicly and as often as i make a mistake say oh that was my bad i screwed that that up. And then I screwed it up because I was thinking X, Y, Z, but in fact it was ABC or, you know, sort of owning up to your mistakes and saying publicly, like in your team meeting or in your team Slack group or whatever

it is and saying, Oh yeah, that bug, that was me. And furthermore, here's why that bug was made. And here, here's the error in my thinking. And okay, that's it. And again, I have all kinds of privilege. And so, you know, I realize I'm coming from a position of being able to say that. And I'm sure not everybody can say that. And again, I've only got my experiences to go by. But I've seen other people on my team do the same thing, you know, especially really senior people. And that, I'm hoping, makes it easier for everyone to say, oh, yeah, I made a mistake, too. No biggie. Set an example.

Setting an example. Setting an example. That's a much more succinct way than my long-winded thing. We've gotten, we've covered a lot of things. And I think some of it we can use. Some of it I could definitely go into work tomorrow and use, and some of it I couldn't, but I could see other people using it. I guess maybe we've covered it all.

Do you have any thoughts you'd like to leave us with? Yeah, I think I have one way to sum up at least some of this and hopefully this is something that anyone can kind of take away from it. And it's that I encourage people to kind of step back, blank sheet of paper and make a conscious and deliberate decision for what to focus on and what to care about. And specifically in a work context is what we're talking about here, but beyond work as well. Choose what matters to you

at work and what you can control at work and what you want to change at work and improve at work. And the act of doing that, the act of sitting down and spending active time thinking about that will be a benefit to you and your group. And even if you can't act on it all right away, just having the thoughts, I think will tilt you in a slightly more positive, we can change things for the better, hopeful mindset. And I think that will pay dividends. I think so too. I think it will pay dividends across your career. Maybe not even across this job, but across your career.

Our guest has been Chris Speck, software lead at iRobot. Thank you, Chris. Thank you very much. This is great. Thanks for all the questions and making me think hard about this stuff. It's been great. I would like to remind listeners that our party is happening on September 7th in Aptos, California. If you want an invite, you have to go to embedded300.eventbrite.com and sign up there. You shouldn't have to sign up for a bunch of stuff. Just put an RSVP yes on. If you want a mug, they are on Zazzle, where you can search for us,

or you can go into the support on embedded.fm, or it will be in the show notes. There will be a link in the show notes. And now, thank you. Thank you to Chris Feck for sharing this idea with us. Thank you to Christopher White for producing and co-hosting, and thank you for listening. You can always contact us at show at embedded.fm or hit the contact link on embedded.fm. If you cannot remember embedded300.

eventbrite.com, you can hit the contact link on embedded.fm and I will send it to you. I'm not putting that in the show notes. It's only for listeners. And now a quote to leave you with. Actually, a whole quote controversy. I wanted to have the quote to leave you with be Eleanor Roosevelt's, it's far better to light the candle than curse the darkness. But a little bit of searching told me that that was not said by Eleanor Roosevelt or was not originally said.

Instead, quote, investigator puts it by William Watkinson. And still, it is far better to light the candle than curse the darkness. Embedded is an independently produced radio show that focuses on the many aspects of engineering. It is a production of Logical Elegance, an embedded software consulting company in California. If there are advertisements in the show, we did not put them there and do not receive money from them. At this time, our sponsors are Logical Elegance and listeners like you.