The Secret of TDD Success
00:00:02
Speaker
We had one of our consultants was was working for a client and they they use TDD test driven development. Right. The client was like, no, no, like we don't do that here. Just we we don't want you doing that. Like, stop doing that. mean We don't want to pay you to write code and then also you to write tests. That's we're paying you write code kind of thing. Right. Well, this person, you know, if so he was like, um i I just I didn't know any other way. So I just kept developing the way I know how, which is TDD. Well, a few months go by and they at one point they were like, OK, hold on a second.
00:00:33
Speaker
what's going on here? All of his stories, you know, they go to production and there's there's never quality issues coming back. And they were like, you we need to dig into this affair. What's going on here? What is this guy doing? And he had to kind of like fess up to, you know, at the end, like, well, i've been you know, that TDD thing you told me not to do. I've i've been doing that.
00:00:49
Speaker
Oh, but they had like that light bulb moment and then come to find out they they had them like, Hey, why don't teach everybody else how to do this?
Are Dedicated QA Resources Obsolete?
00:01:02
Speaker
Welcome to the forward slash podcast where we lean into the future of IT by inviting fellow thought leaders, innovators and problem solvers to slash through its complexity. I'm your host, James Carmen. And today we're diving into a topic that may spur some debate.
Meet Matt Choi: The Journey to Test Automation
00:01:18
Speaker
resources. Are they critical or antiquated? Joining me is Matt Choi, one of our amazing test automation engineers at Caliberty. Matt, will you maybe introduce yourself to the audience?
00:01:32
Speaker
Yeah. So hi I'm Matt. Um, I'm from California originally, uh, grew up there born and raised, but I do love the Midwest. So I'm out in West Lafayette, Indiana.
00:01:43
Speaker
Um, whereas I, where I volunteer as a mentor for college students at my church, moved out here to start that. So go, go Boilermakers. Um, yeah, I've been working as a test automation engineer for six years.
00:01:55
Speaker
Um, you know, with varying titles, I took a gap year after college, to do some volunteer work. Um, And actually one of the interesting things, I guess, i didn't know what like anything about quality assurance or test automation or this whole side of development until I graduated and started working.
00:02:13
Speaker
um But I knew I would probably be pretty good at it because in college and everything, I was very good at breaking people's code. I would have a project that it would never work well the first, second or 10th time. It took a lot.
00:02:28
Speaker
And so it was a perfect marriage of things that I learned at school and my natural talent, I guess, at breaking things. So, yeah, that's me. Very cool. And you you studied cognitive science at Berkeley. that's That's pretty cool. so what was your What was your favorite part of studying kind cognitive science?
00:02:48
Speaker
Oh, yeah. So, yeah. So I graduated from Berkeley and it was just the, I think I chose cognitive science because it allowed me to study multiple things. So in cognitive science, you study philosophy, psychology, um as well as you have to take, you know, the AI classes. And it's ah it's about the study of the mind. And so trying to understand what the mind is from different angles, I think is really, it was really interesting.
00:03:16
Speaker
And I thought like, Well, it helped me to know that I was not going to do anything biology related because I took a neuroscience class. i was like, no, that's not for me. But it was really interesting to see that and to see how, you know, it is like the idea of a neural network is not exactly one-to-one, but seeing the way that our brain works and then the way that we're trying to set up, um, you know,
Evolving QA: Integrated Quality Approaches
00:03:40
Speaker
the future for the future of AI, machine learning, all of that, how it's kind of similar and how we're modeling it based off of something very natural.
00:03:47
Speaker
So I thought that was pretty cool. And so I took computer, did a computer science minor, um but that was mostly for the practical side, just so that I could get a job after to college. That makes sense. That makes sense.
00:04:00
Speaker
um Not a lot, not a lot of call for philosophers these days. And I'm not hanging out the, the, the job offers for, for philosophers these days. but Yeah. And I feel like they only really make it big once they're dead.
00:04:14
Speaker
So. but Right. Yeah. Yeah. And then they then the money starts pouring in when you can't enjoy. it And it's usually hundreds of years later. Right. Yeah. All right. So yeah since you studied cognitive science, we could probably say you can talk about AI, cool stuff and, you know, fun theoretical things for hours.
00:04:32
Speaker
First off, let's talk about how do most places like approach QA when it comes to quality assurance? How do most shops do it? well i mean There's kind of a couple of models, I think. but no you know kind of Tell us how that works, typically.
00:04:47
Speaker
yeah I think typically, and I haven't seen this a lot um because I've been like really lucky to work at companies that have been a little bit more forward-thinking, but what I have seen in my time is that Yeah, usually it'll be like, here's, there's the dev work and there's the QA work.
00:05:05
Speaker
Right. And then we'll usually just develop first and that'll all happen. And it's sort of like the quality people don't really see what's going on there until, okay, here's a product.
00:05:16
Speaker
Here's some sort of, you know, best case scenarios, here's some business requirements. Here's the scenarios we need to hit. And then, so you guys handle that sign off on that, say it's good.
00:05:28
Speaker
And then that's how it gets up to whoever is next in the bureaucratic chain, I guess. So that's what I've seen. Yeah. Yeah. And that's when, so that's like a, that's where you have the the QA is kind of a completely separate team, right?
00:05:41
Speaker
Different managers, different ah priorities, right? You can imagine how that causes troubles. So there's, so that's kind of, that's like how we, we did it, you know, forever and ever. That was, that was the way we always did it. And then they, they started to kind of do,
00:05:58
Speaker
you know, lean in the right direction where they would start to like matrix folks in. So they would, would still have maybe a central organization and then they would assign a, you know, QA person to, to a team. So you at least have somebody dedicated at least to the team, but dedicate, that was dedicated, meaning they were the people doing it. Have you experienced those sort of setups?
00:06:19
Speaker
Yeah. Yeah, totally. I think that's pretty common actually. Um, and it's the, um, I think that experience is, I think what I sort of, that's what I hear about a lot. That's a lot of what I've experienced is the, like, here's the dev team. You're the QA guy. You meet with the QA people, um, outside of the team meetings and you sort of, uh, once you're in that, when you're in the team, then it's sort of still, still the nature is is that it's still a little bit split though. It's that the devs do their thing and then QA, you don't look like
00:06:55
Speaker
I wouldn't look at it until the dev say, oh, it's done. Um, and I think there's it while that's better for sure, better than like the other setup, um, there's still some like, um, issues with that for sure.
00:07:08
Speaker
Um, yeah. And I think like one thing, like just to sort of keep talking about that sort of setup is that it creates kind of this kind of like, um, like it just really takes like one,
00:07:20
Speaker
person to have one bad day, you know, where it's like, they say something snappy. And then it's sort of this dynamic dynamic of like, dev, dev thinks it's good enough. QA doesn't like find an issue. And it's not necessarily their fault that they're doing their job and finding issue. But because of the nature of there's a QA side and the dev side, it creates that dynamic of like, it's the devs versus the QAs.
00:07:46
Speaker
And then sort of like create the odd tension in the team, I think is what I've seen before. It's a tale as old as time. yeah Yeah, I agree. I think that it just, it what we've experienced is it very much, um it hurts the team culture, right? You get it. And like you're saying, it's kind of that us versus them. It's ah they're they're at odds with one another where, you know, you kind of want your team to be you know, if it's a team, they should all be going for the same objective, for the same goals, right? They should all be rowing in the same direction, so to speak.
00:08:16
Speaker
So yeah, I've absolutely seen that. um and Another thing is, the now, especially with the the the older model where you you kind of, and the the team just finishes developing their stuff, then they go throw it over the wall. Someone will eventually test it. I have no idea who, we'll just get reports back if it's wrong.
00:08:36
Speaker
That feedback delay is one of the things we've seen has been ah pretty bad. I think that still goes on to lesser extent when you have like just the dedicated QA person on the team that, you know, what we usually you like if let's say you have two weeks sprints,
00:08:52
Speaker
um a developer and also i'll fully admit to this what developers will do is okay we got two weeks to do our stories well we'll wait you know we'll take the eight days or nine days to do my story okay i'm done now i'm ready for qa to do their thing so you get and you know all the the the qa folks are just like under the gun at the very last minute on every sprint and then so things keep carrying over and it it never hardly works out where Oh, we get one story done Monday, we can help test it. And Tuesday, we another. It doesn't work. It's always like slam at the very last minute at the end of the sprint or whatever. Right.
00:09:25
Speaker
I think that's that's always. And again, that's that delayed feedback. and Like, OK, I worked for almost two weeks and I don't hear anything about feedback from what I was doing until the end of the thing. And then I have no time to fix it.
00:09:37
Speaker
Yeah, I have a pretty funny story about that, actually. Like I got it was some tiny feature, like when I was first starting and this The company I was working at, they were like going through a transition where they brought in like trainers for like the agile mindset. So it was actually like by the end of my time there, it was like we were working like clockwork. It was like really smooth.
00:09:57
Speaker
But in the beginning, it was a feature that was I think it was like can't exactly remember what it was, but it was like something about like a spacing of some like the rows like of records or something like that, like in the UI.
00:10:09
Speaker
And it just kept like if there was a bug, like every time is like a small thing. And, you know, it was my job to tell them, Hey, this isn't working, but because it's so low priority, it doesn't get done till the end of the sprint.
00:10:22
Speaker
And so for about a whole quarter, I'm ping ponging this feature back and forth with this developer. And both of us by the end of the quarter were like, dude, this is so not worth our time. Like what is going on? and But it, but because it was sort of the whole process of, yeah, he has other things, other priorities that are like, actually like feature critical.
00:10:43
Speaker
He doesn't work on it till the end of the sprint and I'm thinking yeah I have to test those other things that are future critical but I'm not working on it till I have to and then that ping pong kept happening like back and forth and i it was interesting because once we switched over to sort of a more like quality integrated mindset where from the beginning of the feature like we're like we're involved in the process of hey like this feature does
Quality Integration: The Caliberty Way
00:11:12
Speaker
it the way that this is being designed, does that make sense?
00:11:15
Speaker
Like as a user, am I going to be able to understand like how this works? We came across something very similar where it was like the spacing of the spacing of like folders, um, in like a task bar or something.
00:11:31
Speaker
And we had very similar issues, very similar bugs, but because it was sort of like, we were integrated in the beginning, it actually didn't even make it to the stage of like being a bug. It was just like, oh, Hey,
00:11:42
Speaker
Remember that one time we were ping-ponging the feature for a quarter? Hey, let's let's try to avoid that. let's Let's figure out right now what the issue is. And so for like maybe three days, we just worked on it together.
00:11:52
Speaker
And because of that, it actually just made it out fine. And we didn't even think about it after. So just that we didn't know like how good it could be because the process of ping-ponging the feature, we have to follow the process.
00:12:08
Speaker
And so because of that, it created this like quarter long, like inside joke between me and this dev. And then the higher ups didn't care about it. But like, I also saw the flip side at the same company, like just because of mindset, like a switch in mindset where quality is integrated from the beginning, we didn't even encounter an issue with it.
00:12:29
Speaker
Right. And so I just thought that that was like really funny um because like, it's not like anything like the personnel didn't change. Like the feature itself wasn't like more complex necessarily.
00:12:40
Speaker
It just took like maybe like seeing quality, not as like the final checkoff for a feature to get out. It's more like, Hey, from the beginning, let's think about this and spend the time. Yeah. It may take a little longer in the beginning, but the time we'll save like in the long run is massive.
00:12:58
Speaker
Right. Because we just sort of, I didn't really even think about that until like the quarter review. And I was like, huh. That was pretty cool. I can't believe we did like that just like happened and it was like a three day thing versus like a quarter long like struggle.
00:13:11
Speaker
You know, I didn't have to argue back and forth for three years straight about the little thing. That's crazy. um the The other thing that I think that, you know, it it develops it. We kind of get this almost like a a false sense of security, you know, when you're like, well, the QA people signed off on it, so it's got to be perfect.
00:13:31
Speaker
yeah QA people are fallible too, right? I mean, we all make mistakes and it's like, the it just, the the setup is just kind of inherently wrong because you're just kind of putting too much you know stock in the fact that, oh, QA people are infallible and and bugs will never get through if wish we have dedicated QA people because obviously we know that doesn't work. Not not to ah you know say that QA people can't do their job. it's just it's It's just so hard to do that.
00:13:57
Speaker
Yeah, no, and it definitely like relieves the pressure because as QA people, like when they're like, oh, QA people are infallible. We're like, no, we're not like this. And so like when something does get through, we feel like horrible.
00:14:11
Speaker
Like I've been there. Like, it's just like, oh, my God, I can't believe that just happened. But yeah, when it's like this, it's not only relieves like that, um like the sort of false sense of security, but it also like helps your QA people not feel so much like,
00:14:28
Speaker
this is all riding on if I say yes or not, because that'll make you, That also, again, going back to team dynamics makes the QA people very stressed from experience. We're very stressed when it's like that.
00:14:40
Speaker
I'm sure. Well, and it kind of just takes all ownership off developers. They can just develop whatever crap code and well, if a bug makes it through, that's not my fault. That's QA's fault. They're going to, they're the ones that get in trouble for that.
00:14:52
Speaker
yeah So yeah, I can see that too. That would, that would be very stressful. I guess i hadn't thought of it from that perspective before that's cool. Yeah. yeah Luckily, I haven't worked with developers that had that attitude. Um, but yeah, like totally, if I'm having like a bad week, let's say like, and I was a developer like, well, I'm sure he'll understand, yeah but it's, what if, what if he's having a bad week at the same time? you know, it's just sort of one of those things.
00:15:19
Speaker
Yeah. So you, you kind of mentioned how, you know, kind of baking quality in from the beginning. So that, that kind of dovetails into how we Caliberty, when we put together a team, how we typically like to structure things. So the the way I kind of explain it is, and and we can kind of talk through it a little more, but like we, we have someone such as yourself, a test automation engineer, and we, we,
00:15:39
Speaker
we created that title to be different on purpose, right? So ah no, they're not S debts. No, they're not QA. No, you know, we, we came up with a new title because we want to make sure that people understand that the, the role on the team is different instead of, Hey developers test, you know, write all your things and then go throw this stuff at Matt and he'll, he'll fix it and he'll make sure it's all good. Right. Instead of that,
00:16:02
Speaker
the the role would be for the test automation engineer is more of kind of that player coach mentality. So as you mentioned, ah you know, as we're we're starting to design a ah feature from the beginning, the test automation engineer is there with the team. that We're all working together to design, and the you know, the how we want to approach this problem.
00:16:23
Speaker
look at the test automation. Can we even test this? If we take this route and we solve this problem this way, is this is even something we can test? And then we get we get that insight from the beginning rather than, oh yeah, it's now Friday at the end of the sprint. And there's no way to test this thing.
00:16:37
Speaker
You know, like that's, it kind of saves some time. So now that doesn't mean that they are not doing some of the testing. Absolutely they are, but more so they should be, you know, if it's a new testing framework or, or maybe some build automation to help a particular testing tool, they can help, you know, spin that up and and set all those things up.
00:16:58
Speaker
But they're also coaching the team on how to be better testers, how to think about quality differently. That's, that's the approach we take. So tell us about your experience with within those environments. And you already did a little bit, but are there other other experiences you had there that you can tell us about?
00:17:16
Speaker
Yeah, I guess like, with that as with everything, like nothing's perfect, right? So like, that's the ideal scenario. And I think Um, like at the client, like, um, they're definitely going through like transitions and like different changes.
00:17:30
Speaker
Um, so part of it is like, I guess, I think part of being player coach is understanding like the short, like the shortcomings and not being like overwhelmed by that or defeated by that.
00:17:42
Speaker
Uh, because like, to be honest, yeah, my role right now, a lot is the traditional sense of QA. Um, I think like helping, uh, the client sort of feel.
00:17:53
Speaker
Like, hey, I'm on your team. Like, I'm invested in this product. Like, I'm trying to make sure that, you know, we're pushing out something quality. um But at the same time, yeah, I think there is like, like there is so being part of like, for example, like planning meetings, you know, refinement of stories, like this is all like the points at which like, okay, i have to step in and ask, okay, what?
00:18:18
Speaker
There's multiple times where I'm asked. what I have to ask, hey, can we test this and to push back? And now, like, again, being, like, having to, like, balance the client relationship is something a little bit, like, that adds a little bit more, like, nuance in the discussion for sure. So I luckily have, like,
00:18:37
Speaker
um someone who does automation and testing leads QA at the client um that I can sort of talk to back sort of the decisions that I make, ask him about. But think a lot of it is like, hey, like, is this testable?
00:18:51
Speaker
What is the purpose of this test? um And like talking through like, okay, this feature, how can we like make sure that like everything that we're about to do, like on the QA side,
00:19:05
Speaker
like quality from like even writing the story, like how can we make it clear? Like, this is what we're testing and why? I think that's sort of like where I've been recently, uh, for sure. And, uh, I think that's sort of making the switch from like, Hey, like QA, like I still do the whole like sign off at the end, you know, when the feature is done.
00:19:27
Speaker
Um, because again, it's about where the client's at and helping transition into a more hey, like from the beginning, let's have confidence in the future as it's being developed, as opposed to we don't have confidence until QA signs off on it.
00:19:42
Speaker
And so I'm doing a little bit of both right now, actually. But definitely like in the past, it's definitely been like really empowering as a QA, like as a quality person to be able to say like, hey, I don't,
00:19:55
Speaker
even to say things like, hey, I don't understand this. I don't understand how this feature works. um Can you help me understand? And actually, because of those kinds of conversations, um sort of helping the devs realize, oh, this wouldn't make sense if we' we're trying to onboard somebody.
00:20:13
Speaker
This is actually a good conversation to have. And so, Yeah, I think that's sort of how I've experienced it. And so that's why like at Caliberty, like I thought it was really cool when initially i was interviewing, like that this, this is the approach that is different because think if we, if more companies did this, or if this was more like a common practice, you don't know if we'd feel so many like pain points of like, Hey, devs versus QA mentality kind of thing, because from the beginning, we're all thinking about it all together.
00:20:43
Speaker
And so it also creates, it relieves a lot of that tension that we were talking about earlier of like, oh, I'm like, as a dev, like, oh, I finished, I'm finally done. And then you get a ping from a QA at 4 p.m. on Friday, like, hey, this is not working. Like, yeah, and we've all been there, right? man Yeah, call your friends at the bar and tell them you won't be there for a little bit. Exactly, exactly. Like, and so I think that's what I think this can...
00:21:10
Speaker
The mindset shift does help like alleviate and sort of have, again, like you'll have an idea, maybe it won't go well, right? The future still won't go well, but at least, you know, that Friday, your friends at the bar,
00:21:22
Speaker
you'll know on Tuesday or one day as opposed to Friday. off board Yeah. Right. So, right. Yeah. I think it's, and, and we get, you know, when we, when we speak to, you know, clients or, or people that we're we're trying to become have, have become our clients, uh, we, we definitely get pushed back on our kind of our approach and they're, they're like,
00:21:42
Speaker
it it almost seems to them like, well, like we don't care about quality, but I think, you know, nothing, obviously, you know, you've you've been here for a while. Nothing could be further from the truth. It's not that we don't care about quality, but we do the, we do it the way we do it because we care too much to let it become someone else's job.
00:21:58
Speaker
Right. That's kind of the way we think about it. That quality isn't just a person. It's the team. Everybody is involved. Everybody owns quality. And to, to let people off the hook just because, Oh, I'm just, because I'm a developer that's, we don't like to do that.
00:22:11
Speaker
So. Yeah, no, I totally see that too. Like, and like, cause my team is a lot of Caliberty folks, um, and seeing like, they'll like just casually throw out, oh yeah, I'm writing some tests.
00:22:23
Speaker
And like, I haven't really experienced that, I guess. Like, it's always usually like, oh, like, Hey Matt, can you write some tests for this? You know, let's talk about it. But actually like the devs, like owning a lot of the quality, um, has been a really cool, like nice change, I guess, for me in my career, um, seeing that and like, yeah, quality.
00:22:41
Speaker
for like other people or like, you know, some future person. I think one thing that I was thinking about, it's also like for your future self, that's another person that you think about. Like you're going to be debugging this later. you want to make sure that, Hey, I at least put in the due diligence to think through this app.
00:22:59
Speaker
And at the time did the best I could to make sure that I'm communicating with my future self. Let's say it breaks down like, Hey, this is where it broke.
00:23:11
Speaker
you know, we had these tests to cover it and, you know, maybe you miss something inevitably. We're all human. We all miss stuff. Right. But writing things in a way and building products and features in a way that like from the beginning, like, because we have the confidence that we wrote it with quality in mind, then that gives us like just peace of mind later for later, you know, like, I think, you know, if i was to look back at work that I didn't feel confident that I, you know,
00:23:39
Speaker
pushed out with quality, but just sort of got through like the bureaucratic, like sort of jumping through the hoops. Right. I think there's a very different like sense of ownership mindset of like, oh, like, yeah, I don't really know what I did there. i don't know why I did that.
00:23:52
Speaker
You know, we've all had that experience too. Like, I don't know why I wrote that that way. Someone told me to do that. Right. As opposed to, hey, we talked through this. um We believe in this like product. We believe in how we did, how we approached it.
00:24:06
Speaker
And so it gives us confidence in the future too. That's what it's all about, man. And what i came up with, i think we talked about it in our onboarding program. and i don't know I think I coined this, but I called it like the golden ratio of testing. it's It's like confidence over drag, right? So anything that slows down your feedback loop, that's the drag. But the confidence, you know whenever you're testing something, it should be giving you more confidence that this thing's actually going to behave the way you want it to behave.
00:24:31
Speaker
And then that's what you want to maximize that numerator and minimize that denominator, so to speak. Right. Yeah. Yeah. And I think the hard part is definitely like drawing that line. Right. Like, and I think that is a big part of my job is to like, make that call. Like, Hey, we have like beyond reasonable, like certainty or confidence that like, Hey, this product is quality, right.
00:24:52
Speaker
That it's not going to break. it and as someone who is good at breaking things know i think like yeah just having a sense for that but also like part of it is like communicating like hey this is what we're going for this is why we're doing this and i think that's what it comes down to a lot like for me like my job hey this is like communicating why like here's i where i draw the line and why because like you said the drag might not be worth the comfort the small amount of confidence you gain in something right right absolutely yeah so risk versus reward.
00:25:24
Speaker
um Now, one of the things we we hear, ah you know, one of the objections, so to speak, is is um developers can't write tests. You know, they i guess the notion, the idea, which seems intuitive, is like it's it's kind of like grading your own homework, right? That's the idea. I guess that's intuitively that the that's how people think of it.
00:25:44
Speaker
But Tell me about your experience there with that, you know, developers can't write tests or they don't know how to do that. They don't think that way. That's they're not built that way. Tell me about your experience with that. oh and So my experience with that is like, well, that's completely untrue.
00:26:02
Speaker
like guess It's just kind of like, I've i i've heard that for sure. um And the way that, like I would talk with the developers, I'm like, I totally think you could do what I'm doing right now. I don't,
00:26:14
Speaker
I mean, I can do it. Like, I'll do it. you know, it was always like, I'll do it. But like, I'm pretty sure you could have done this like in your sleep. no But I think it the worry yeah is like writing own homework, like that kind of thing. Like you will have blind spots.
00:26:27
Speaker
And I think, again, that's why like doing things not like in isolation and like I'm the dev on this piece, like my piece, I do this and then I hand it off. But doing that like with people, other people like on your team, because they can see your blind spots, right? A lot better.
00:26:44
Speaker
And then again, that's part of my job is like with quality, I guess, like going back to that player coach mindset, like as someone who is sort of more focused on the quality aspect or the sort of, yeah, in integrating it into the development process, I think I do see certain things. So like,
00:27:04
Speaker
Again, it's sort of doing it together as a team with quality from the beginning is actually how like, like the actual execution of like, Hey, I'm going to write code to test this product is not actually, um, that, uh, like important, I guess, or like, it's not difficult.
00:27:22
Speaker
Like it's not difficult for like someone to do. So I think like the more important part is like the mindset part and like thinking it through talking about it with other people.
00:27:34
Speaker
And that's that's the whole thing about like the agile, like, you know, agile methodology, which is kind of an interesting oxymoron in itself. But yeah.
00:27:46
Speaker
So, man, we've we've had episodes about that for sure. Yeah, I love that, that it's it's it's about that mindset. And, in you know, i mean, we can we can. When we only talk about quality at the end, you know, you just, you don't get as much of a chance to reinforce that that mindset. But when you you do it throughout the entire process and everybody's getting that, that reinforcement of quality, that quality mindset constantly, you know, and iteratively throughout the entire process. Yeah, absolutely. It gets people to develop better habits around quality.
00:28:16
Speaker
And I think just just having the you know having the the developers and the the test automation engineers working closely together, it helps a ah little bit of kind of you know a little bit of that empathy right to understand the other person's the world.
00:28:30
Speaker
you know As you're coaching folks, you're saying, okay, this is what I'm looking for. And they might be like, oh i never I had never thought of that when I'm writing my code. I just write it this way. I don't think of you know things from that perspective. So it helps them to become better developers. And you know you may learn more of some about the development process that you hadn't learned known about or something like that. you're like, oh, I actually can you know test that easier now or whatever, you know however you ah you whatever lessons you learn. But we learn lessons from one another, right? we we We become more exposed to each other's world and just the the quality just goes up from there.
00:29:03
Speaker
Sure. Yeah. And I think like going back to like, it's like, I think processes are comfortable and that's why people like why they're so prevalent, right? Like it's something that I can show up and do.
00:29:16
Speaker
But I think like when we sort of apply like that, it's a mindset and like working together, like my current team, like, man, the kind of like ways that like we're able to, like, I bring up an issue that I see, we work on it together. We work through the book together. I'm not just like throwing a story back.
00:29:33
Speaker
to them like saying, Hey, broken, fix it. But it's sort of, Hey, let's hop on a call. This is what I'm seeing, you know, and they dig into the code and yeah, but you're right. Like I learned a lot and I've actually like applied a lot of what I've seen, for example, like, you know, when there's like enums for, so for example, and I just didn't know that, right. Like set values that I can draw from, ah I can pull that from my testing. Right. As opposed to like having to hard code everything and like,
00:29:59
Speaker
You know, so I thought like that was pretty cool. Like that, that interaction um really love like my team. um And I think like we have that right mindset of wanting to integrate quality from the beginning.
00:30:13
Speaker
And because like it's from the beginning and that, and so yeah, when the client feels like they want the process more than the mindset, it makes it that causes a different kind of clash.
00:30:28
Speaker
um And I think that's one thing that like we're we're working we're working on. And I think we have like the opportunity to sort of help sort of see, like help them to see like the benefit of the mindset versus the process.
00:30:42
Speaker
But, you know, again, it's not necessarily the client's fault. Like I was just thinking about that just now, like, hey, it's they have their own like regulations and regulatory bodies that like are like looking at them, making sure they're following the processes. So.
00:30:56
Speaker
It's a, it's a lot of things to juggle, but I think at the end of the day, like it will help like the client to become, to have more quality outcomes.
00:31:07
Speaker
If we're thinking about it from the beginning and taking a little more time to have that empathy that you were talking about, where the quality and the engineering, like the development folks can be like basically just one, you know, and like doing it together. so yeah A true team.
00:31:26
Speaker
I was wondering if you had, I'll explain an aha moment for one of our clients. It was, it was kind of interesting. We had it one of our consultants was, was working for a client and they, uh, I guess this person was just how they develop. They use TDD test development. Right.
00:31:41
Speaker
And, uh, the client was like, no, no, we don't do that here. Just, we we don't want you doing that. Like stop doing that. We, you know, we don't worry about, I don't know if they didn't worry about tests at all or if they didn't do TD. I don't remember, but I think it was, we don't do tests at all.
00:31:57
Speaker
Just, we don't want to pay you to write code and then also pay you to write tests. That's, we we're paying you write code kind of thing, right? um Well, this person, you know, if that's the way you develop day in and day out and that's just the way you work, it's hard to just stop. So he was like,
00:32:12
Speaker
um i i just I didn't know any other way. So I just kept developing the way I know how, which is TDD. And that's what he did. Well, a few months go by and and he he kept doing his thing. and And they, at one point, they were like, okay, hold on a second.
00:32:25
Speaker
What's going on here? This one fellow's code... All of his stories, you know, they go to production and there's there's never quality issues coming back. And they were like, jim we need to dig into this figure what's going on here. What is this guy doing? And he had to kind of like fess up to, you know, at the end, like, well, i've been you know, that TDD thing you told me not to do. I've i've been doing that.
00:32:44
Speaker
Oh, when they had like that light bulb moment and then come to find out they, they had them like, Hey, why don't you teach everybody else how to do that? So it was, it was actually a good outcome at the end, but it was, he kind of had to do it, you know, on the down low, so to speak, the client, no, he was doing that.
00:32:59
Speaker
Any aha moments like where, you know, when the clients finally get it and, and you know, and being like that. I think a lot of times it is like being like reflective. So having the time to think back on it. So yeah,
00:33:13
Speaker
it's always been like iterative change that I've experienced where it's like, Hey, like how did that, like that feature went really well, what did what happened? And a lot of times it was like, Hey, like we, we were re we really dug in like in the beginning, talk through it. I was there able to like put in, give some input.
00:33:32
Speaker
And a lot of times when it didn't go well, the, the common denominator seemed to be like, we were just trying to get it out, you know, and where we,
00:33:43
Speaker
There are some higher ups that were like hounding us about this, something like that. And so I think that's one thing I haven't really seen that kind of like aha from from a client or from anyone I've worked with. But I think the first company I worked with, I talked about that switch that happened and then really going all in on like agile mindset.
00:34:05
Speaker
I think one thing was like, they sensed a need for change. And I think that's hard for people to feel because we get caught up in like the day to day stuff. But they sensed and like kudos to them, like big time, like they sensed the change in the market.
00:34:21
Speaker
They sensed like the changes that were happening, like in technology. And so they realized, hey, we need to do some like catching up, you know, like didve we got to dig and see like what's going on. And is this sustainable? And So because they felt that need, I think they moved, like, made some pretty drastic moves um that not everybody was happy with.
00:34:44
Speaker
But for sure, like, you got to, like, there has to be a little bit of, like, oh, like, things aren't going well. i think a lot of times we settle for things not going well but are passable.
00:34:58
Speaker
And so think the idea that this is as good as it can get, like, we need to let that go. and look for like, how can this be better? And that's when I've seen like, okay, change happen.
00:35:10
Speaker
And that's been my experience. But again, it hasn't been like anything as cool as like, I secretly just did TDD on my own. yeah Like, that's pretty awesome. That was a, that was a, that's a fun story. We talk about that in our onboarding as well. That sounds like it could be like a verge article, you know?
00:35:27
Speaker
if Yeah. It's a, it's a pretty cool story. It was, and it was a good relationship
Segment Transition: Ship It or Skip It
00:35:32
Speaker
with that client too. i mean, they were like, Oh, we need more of this. I'm like, sure. Yeah, we get it. Um, so,
00:35:41
Speaker
I think we're we've we've kind of covered the topic and and kind of all the angles. and So now we have to go into our – we don't have to. We're going to go into our new – our other segment we call Ship It or Skip It.
Ship It or Skip It: Balancing Quality and Pragmatism
00:35:56
Speaker
Ship or skip. Ship or skip. Everybody, we got to tell us if you ship or skip.
00:36:02
Speaker
All right, so this the idea here is, um this is where we come up with a ah topic and you and I will both weigh in, I'll let you go first so that I can you know say you're full of it or whatever. I'm kidding. But I'll let you go first and you know we'll just bring up a topic and that can be seen as controversial and you say, yeah do that or don't do that. That's the ship it or skip it part.
00:36:22
Speaker
all right. Number one, ah I, this is what I call it like, uh, Yoloing to prod Yolo meaning, you know you only live once. Right. And people are like, that's you, that's just, okay, just release this stuff. Right. And that's when you release things that have known like low priority issues.
00:36:38
Speaker
Obviously you're not going to release crazy stuff in a prod, but you know low priority issues. What do you think about that? Is that, is that pragmatic delivery or is that a slippery slope to laziness? Um,
00:36:50
Speaker
Wow. I feel like as a quality guy, I gotta say, skip, like, you know, like, that'd be kind of weird, but like my gut says, like, we should, if it's low quality stuff, right. Or I mean, low priority stuff, yeah like ship it, you and not now again, like I would have to qualify that, like,
00:37:08
Speaker
how YOLO are we talking about? You know, like nobody looked at it yet. Right. But I'm assuming like these people aren't crazy. I'm assuming that. right So I'm assuming that we've done what we can and it's just like a stubborn bug or something like that.
00:37:23
Speaker
um And it's sort of very low priority. I'm going to say ship it because the idea that like you can't ship anything i unless it's perfect seems like that's going to create that drag, you know, that we talked about.
00:37:37
Speaker
So. Yeah, I think I'm in agreement with you on that one. I'm okay with being a little, you know, move fast and break things kind of a mentality. I'm okay with that. And i've I've tried to stress to my clients in the past, like what you want to make sure you can do is bring down that mean time to remediation, like make it very easy to go fix when something makes its way into production. That's, you know, suboptimal or however you want to say it, a bug.
00:38:03
Speaker
because they're gonna make it anyway. So, but making your processes, your build, your, all of the things, quick, easy, simple, rock solid deployment, you know, deployment back into production, make that perfect, make that and just, just shine so that when those things do make their way to production, you can fix them quickly.
00:38:23
Speaker
The other part of it that we um software engineers struggle with is, um, especially ones who are, you know, obsessed with quality or, you know, we, we emphasize quality so much is like the the idea of like the kind of the startup mindset, right? i don't know if you've worked for a startup, but like in a startup world, you have to, you kind of have to get your product out in front of people and and start to, you know, the the priority is to start bringing revenue and get some money going, you know? So,
00:38:52
Speaker
Sometimes it is okay to, you know, you, maybe you're going to rewrite it when you get your next round of funding. There's a big rewrite that's going to happen and you're proving out a concept that people will buy this product. Who cares if the, if the code is perfect? Like, so that that's been hard for me in an environment where it's like that to be like, just, okay, yeah, well, let's let it go to product. Okay. I'm fine. Like, I want to like polish the code and make it beautiful. Right. But In that environment, that's that's not the best business thing to do. So that's ah that's a tough situation. And in in those situations, absolutely.
00:39:24
Speaker
YOLOing with those low-quality issues or sorry, low-priority issues is fine. Okay. Next. How about bug bounties? Is that, and this is new. We didn't do this before with a chip it or skip it, but i'm going to characterize it and you can come up with your own characterization, but I like the ones that I came up with. So I'm going to say, um, uh, our bug bounties crowdsourced brilliance or outsourced due diligence.
Bug Bounties: Crowdsourcing vs. Outsourcing
00:39:50
Speaker
That is tough. And
00:39:55
Speaker
I feel like that's outsourced brilliance, crowdsourced brilliance, because the the reality is like, you don't know what you don't know. And I think like having like outside perspective is what you sometimes what you need.
00:40:14
Speaker
um And hey, like, who knows, like, if there's like something that like someone comes up with and you just like it blows your mind, you know, like, Hey, like maybe that's someone need to pick up.
00:40:28
Speaker
yeah like it's my creating tool Exactly. And I think that's something that could be good. Now, of course you can't go crazy with that again. Like anything taken ah to an extreme is like obviously bad, but yeah, I feel like that's outsourced brilliant. So maybe that's my Gen Z showing. i don't know.
00:40:47
Speaker
That's okay. No, my, my Gen X would, would agree with you. Yeah. I think, I think bug bounties, the interesting thing is it's almost like a psychology thing for me, right? It's, you know, if you release things out in front of your users and they do find bugs, they're going to be upset, right? Usually they're going to be upset, but if they can be involved and you know, with you have those bug bounties,
00:41:10
Speaker
It's almost like they're part of the team, right? So they feel a level of ownership with the product. I think it's kind of cool to bring bring your users in together as almost like part of the product team themselves and and that helps them you know develop a sense of ownership over the product. and So I kind of like it, right?
00:41:24
Speaker
Now, again, like you said, um I'm not saying like, okay, let's just go. Nobody write tests, no test automation engineers, just YOLO everything straight to prod every time. i use build test yeah They'll figure it out and we'll give them a couple bucks here and there when they do. No, I'm not saying that.
00:41:40
Speaker
ah But but i I do think it's an interesting dynamic that you're almost like bringing them into the fold and and they can be part of the team with you know by helping you find bugs. Instead of finding it and just being mad, they're finding it mad, but then less mad when they get, you know, a few bucks for it.
00:41:59
Speaker
Okay. This is the one where maybe we will not ah agree. And I don't, I don't know if it's a Gen Z, Gen X thing, or if it's just me, um, and I'm the problem. I I'm okay with that. If I'm the problem, 100% test coverage.
Is 100% Test Coverage Realistic?
00:42:14
Speaker
This one always gets, it's an interesting topic.
00:42:17
Speaker
Is that the gold standard or is that a false idol? Um, yeah, when I hear that, I think immediately false idol, like, because to be a hundred percent, anything like creates that kind of sense of false security we talked about earlier. But I think also the man, like feel cause it, yeah, feel like have to qualify. Right.
00:42:44
Speaker
It's the hundred percent, 10% test coverage. is something we should strive for. so like in that way, it's a standard, like a gold standard, but it's not something that like necessarily is like, that shouldn't be our like main focus, I guess it's going back to sort of the Yolo and the prod thing that we were talking about, like the whole, like, Hey, this is going to go out.
00:43:05
Speaker
It doesn't like, we need to focus on getting test coverage. Sometimes what is required is, Hey, we don't have a hundred percent test coverage. We need to get this thing done. Let's not focus on the coverage right now.
00:43:17
Speaker
in this like stage of life of the product we need to focus not so much on that so yeah i just feel like it depends so for me i lean more towards false idol i guess all right i'm gonna go gold standard but not for the reason that that most people think is that it's not just the 100 isn't the for me the outcome i'm looking for it's a means to an end for me so in my experience when I'm working on a code base that's capable of getting to 100% test coverage, it's usually designed well.
00:43:51
Speaker
And when you're designed to be testable, it's modular, it's you know you're using dependency injection, like the the the code is easier. If it's easy to test, it's it's typically just a well-written code base. That's what been my experience. So when I push for 100% test coverage, it's usually more of a challenge to say,
00:44:11
Speaker
Instead of just you know and saying, oh, we're close enough. We're at 95% or we're at 80%. Like we're close enough. i Challenge yourself. You know, can you find a piece of code that's like, I'm really having a hard time testing that. Use it like a puzzle. How can I get this thing to be testable?
00:44:26
Speaker
And then usually when you do refactor, it becomes a little, you know, a little more modular, a little more well-written. ah So that that's the reason I like it. Now, I will... Again, qualify that when it comes to, you know, things that don't need to be, you know, tested, ah like in Java, in the Java world, we have the always ah the the example is like getters and setters.
00:44:48
Speaker
course not. Just ignore that stuff. For me, I use, you know, code generation tools. So those things aren't even really code until compile time anyway. So you don't see it, you don't have to test it kind of thing.
00:44:59
Speaker
yeah, ignore the things, the the trivial bits of code and the things that really do, like if there's two sides to an if branch, maybe you should test both of them, right? That kind of stuff is kind of important, right? like I just, you know, call me a stickler, but, but I, but I do think, yes, it's important in and of itself, but I also think it's, it's a means to an end for higher quality code.
00:45:19
Speaker
Yeah. And I think like what we said is we're hitting the same thing from different sides. It's again, like going back to the, how do you think about your code? And like, is it something that you want to like be quality and, but at the same time, like practicing balancing that with pragmatism.
00:45:38
Speaker
And so, yeah. Yes, indeed. All right. um We have our last segment, the lightning round.
00:45:51
Speaker
It's time for the lightning round. Rapid fire, don't slow down.
00:46:03
Speaker
Hands up quick and make it count. In this game, there's no way out. It's time for the lightning round. This is the most important segment of the show.
00:46:13
Speaker
This is the the most, you to talk about stress. This is high stress, high stakes. ah There are absolutely right answers to these questions. And I'm going to be just firing them at you. I'm going to let you think. You just need to answer.
00:46:27
Speaker
Right. So this is, this is an extremely stressful thing. Okay.
00:46:34
Speaker
What your favorite childhood TV show? You know, I didn't watch TV growing up actually. and So I read books. I like that answer. knew I liked this guy. I'm a book guy myself, but I did watch TV because I grew up in the eighties and like you have absentee parents in the eighties. We were just, fair we were feral in the eighties. So yeah, TV was a way to, to babysit us back then. So anyway, I like that answer.
00:47:03
Speaker
ah Why can't we tickle ourselves? Ooh, coming from someone who studied cognitive science. Why can't we tickle ourselves? Um, okay. So i actually thought about this a lot as a kid because I didn't watch TV.
00:47:15
Speaker
but So my, my theory about this is that because you have, in order, like tickling is about like, do I trust this person or not? A lot of it is like, Hey, you're in my personal space.
00:47:28
Speaker
Hey, what are you doing? Stop that. Right. And so we can't tickle ourselves because we inherently just trust ourselves and we know where our body parts are and So we like our brain is already thinking about, oh, I'm moving my hand up to my neck.
00:47:41
Speaker
Nothing's going to happen because it's my hand. That's my theory. So that's what all you kids were thinking about, the book readers, while I was watching He-Man and Transformer. Yeah, and ruining our brain I picked up the most random thing because of boredom. You know, boredom is a great development of like random useless talents.
00:48:03
Speaker
Ah, I like that. Okay. um What is the fastest speed you've ever driven in a car?
00:48:12
Speaker
I've actually never gone triple digits. Never. Never. Not very close. And I'll leave it there. I'm sure that's slower than a lot of people. Whatever you say cannot be used against you in a court of law.
00:48:28
Speaker
I don't know that that's true. i don't don't take I'm not a lawyer, so yeah don't take that to I don't even know because the speedometer was like, you know, it's the dial one. So I don't know the exact number, but might have started with a nine.
00:48:39
Speaker
Yeah, it's you never know. Those things can be off, too. Who calibrated this thing? have no idea. Didn't like 100. It felt like 47, um yeah Okay.
00:48:53
Speaker
Name something, name a word that starts with the letter Q.
00:48:59
Speaker
Quilt. Quilt. Okay.
00:49:04
Speaker
What type of milk do you put in your cereal? You're a 2% guy, whole milk, skim? What you doing? Whole milk. Whole milk guy. Okay. I like that. That's a good answer. why why do Why do it halfway, right? Exactly.
00:49:19
Speaker
Would you go to ah movie alone? ah No, I wouldn't. My friends have, though, and we made fun of them for a long time over that.
00:49:32
Speaker
I have gone to a movie alone. Not only was I alone with like none of my friends at the movie, I was alone with no one in the movie. It was pretty cool. I was like taking selfies in the middle i feel like that's different, though. like If you're alone and it's completely empty, that's a selfie moment. you know yeah Look at this, right? It was fun. But if you're alone and there's like couples, families, and then you're the one guy there, i feel like this I just can't do that. okay I did it when I traveled for work.
00:50:00
Speaker
Okay. But no, like it's not like on a weekend I'm not going out, you know, by myself.
00:50:08
Speaker
Okay. Black beans or refried beans in your burrito? just say black beans because I don't really know. the difference, I guess.
00:50:19
Speaker
I didn't really grow up eating a lot of beans, except in my burrito, like Chipotle burritos. So, yeah. I think it's like less calories or something. I forgot why. But then ever since I decided to eat black beans, I just always say black beans at Chipotle.
00:50:36
Speaker
It doesn't feel like this is one of those things you were sitting thinking about no when you weren't watching TV. No, yeah, definitely not. Yeah, definitely not. I was too busy figuring out how to get this spit bubble to fly off my tongue.
00:50:50
Speaker
but That is a talent. i yeah could Yeah. Very rare talent. actually Or the, what's the thing they call it when you like the, the saliva gland gleaking. Yeah. Yeah. You had to learn that too. That's important.
00:51:07
Speaker
LA or New York. Oh God. hate both of them personally. um l LA, I guess, because my family lives there, like my extended family. Okay. ah we're in Where would where what your favorite place to be? a I really love Chicago, actually.
00:51:27
Speaker
Really? Yeah, I've lived in California, like SF, been to LA like every year for Christmas, then went to New York for a graduation trip. ah Chicago, lived there for three years, love it. I think it's the best city in the States. Yeah.
00:51:44
Speaker
I was just there yesterday. I really like Chicago. I wish I could have spent more time. I was only there for a night, but it was, I do like, I do like Chicago. It's great city. Um, how would you rate yourself, uh, and your karaoke skills on a scale of one to Mariah Carey?
00:51:59
Speaker
Gosh, I don't know. I can sing. Like I know I can sing. Um, okay. So maybe like, uh, who would,
00:52:12
Speaker
From one to Mariah Carey, maybe like early 2000s YouTuber trying to make it big kind of thing. Like i'm right around maybe a little worse than them.
00:52:24
Speaker
Okay. Like that sounds like a Justin Bieber situation. No, no, not Justin Bieber. I'm talking about like the ones that didn't make it. Okay. Yeah. They didn't get picked up. Okay. Yeah. Yeah. All right. That's great.
00:52:37
Speaker
Uh, what temperature do you like your thermostat set at? 68. 68. I'm a 68 kind of guy. Is that for heat or is that for cool or both?
00:52:51
Speaker
Both. Just, I wanted it 68. Period. Yep. All right. Um, but funny thing about that. So I grew up in Davis, California, which is, uh,
00:53:03
Speaker
It'll be like consistently like 115, 110 in the summers, like for like weeks at a time. Okay. And then you have like a cool day for soccer practice in the fall is like 90, 92, something like that.
00:53:18
Speaker
But I would set the thermostat to as low as it could go. And my dad get so mad at me. And I was like a like a conscientious kid, so I didn't like it when my parents were mad at me. But ah if it was just I couldn't stand it. like I just had to turn it all the way down. And then every day he would come on me like, and then like, who turned the thermostat up? Yeah.
00:53:41
Speaker
yeah So now that you're grown and out of your parents' house, you're like, nope, I'm setting it at 68. Yeah, now that I'm paying for it, you know. and Well, and that's ah so I was going to say. Like my my my hope as a parent, because, you know, i have kids in the house and like they do, that I get mad when people, you know, I'm very particular about that thermostat. That's money, right?
00:54:02
Speaker
But my hope is, and and you think like, oh yeah, you'll learn one day when you move out of my house and you have to pay your own bills, you're not going to be doing 68. But actually that's not true. You do say, hey, I'm paying it. I'm going to go with 68. Okay. I have no idea what number we're on, but we're going to keep going because we're covering some really important topics. I like this one.
00:54:23
Speaker
If Tupac, you know who Tupac is, Shakur. If he appeared before you right now, what's the first thing you would ask him? Who was it?
00:54:37
Speaker
I like that. it's probably the best' That's the obvious question, I guess. yeah But I guess if I had a second question, you're like, you want to go to lunch? What you want to eat? Let's go eat.
00:54:49
Speaker
Why don't we take my car? Yeah, yeah, yeah. Please. They might know yours. yeah let's it All right. what ah What is the lamest dessert that people try to pass off as a dessert?
00:55:01
Speaker
Oh, man. famous is Dessert. I love dessert. So this is tough. I pretty much love all food.
00:55:12
Speaker
So this is very tough. I think flan. I've had flan. I have i like flan a lot, but it's like a milky, it's like custard, like a jello, like a firm custard is sort of the experience, I guess.
00:55:28
Speaker
Um, Yeah, it's just, it's very underwhelming, I guess, when people are like, oh, this is really good. And it was just all right. I guess related to that would be Jell-O.
00:55:41
Speaker
Jell-O is kind of lame. Yeah. There's room for it, but it's lame. Yeah, exactly, exactly. At the buffets, it's always, for some reason, I always scoop some, so. I had a ah good friend growing up, George, his mother was from Cuba and she was, she made a flan that like I've, I, ah since then I've never had a flan again in my life that was like, I enjoyed as much as that. It was fantastic.
00:56:08
Speaker
Like she should open a flan business cause it was, it was fantastic. But yeah, you're right. If it's not the right texture. Yeah. Right. Yeah. um like But on the other side, very underrated desserts, many of them.
00:56:21
Speaker
But very underrated to me cheesecake. I know people love cheesecake, but man, I love cheesecake. I could eat cheesecake every day.
00:56:32
Speaker
like an unhealthy... like like like Yeah, New York-style cheesecake. Yeah, it was one of those things I learned to bake in college as I was procrastinating for finals.
00:56:44
Speaker
Well, I could go do organic chem or make a cheesecake. All right. um This is going to be our final final question. I've got to find a good one here.
00:56:58
Speaker
that one's probably. Do you like the smell of gasoline? I do, actually. um Kind of weird, though. It's kind of like not a like as a kid, I loved Like, mom, please roll down the windows.
00:57:13
Speaker
want to smell that. no But yeah, something about it It's like the same like vein as Sharpie. You know, that kind of thing. So something about it. It doesn't smell good.
00:57:26
Speaker
i just enjoy it. I don't know. like It's hard to explain why. I'm the same way. But it was it was definitely worse when I was a kid. Really?
Teamwork and Quality: A Collaborative Effort
00:57:36
Speaker
Yeah. Like I definitely liked it more as a kid than I do as an adult, but I don't dislike it as an I'm the same way. Yeah. Cool.
00:57:43
Speaker
All right. Any, any, any closing thoughts or, or, you know, that you would share with the audience, anything like that and words of wisdom, anything like that? Like related to this or any, or like not smelling gasoline probably, but yeah.
00:58:00
Speaker
Yeah. oh I guess like related to like quality, like, You know, the whole like idea of like being anti-fragile. It's like, you know, when bad stuff come or stressors or shocks so whatever that stuff comes, like that's when an anti-fragile system becomes stronger.
00:58:21
Speaker
It's not just like they grit their teeth and make it through. It's actually the stressors make the system or whatever it is stronger. i think striving to be that means that like,
00:58:33
Speaker
you have to be like, not just resilient to change, but like learning to embrace change or embrace things that may be difficult and figuring out how, Hey, how is this good for me? And I think that's one thing that like, it's not necessarily like something you can do alone.
00:58:49
Speaker
I think a lot of people try to do a lot of things alone and this is not just for like work. It's just life, I guess, like my experience and I'm young. So like, this kind of sounds quaint coming from like a younger guy, but I think like one thing that I've definitely learned over the years is that life is just, life is not meant to be done alone, I think.
00:59:08
Speaker
In my experience of life, I guess very little experience of life, but life is just better. It's more fun, more doable, less anxious when we have a lot of people around us.
00:59:20
Speaker
And not just like any people, because of course there's ah there's toxic people and like whatever, but I think doing it, doing life with other people, Mike help like having that be like towards ah like the same goal or doing something meaningful together. think that's something that I've really experienced to be true.
00:59:42
Speaker
Um, and I think that's something that applies to like this whole conversation of quality. Like when we're trying to make like something like a quality product, we're trying to, we're on the same team.
00:59:56
Speaker
Um, and we act like it, you know, like we're on the same team, we're doing this all together. You know, things that happen that are like kind of like less than ideal or bad, like it's just a new challenge and it'll make the team stronger and work better together and it'll make it'll show up in the product as well.
01:00:15
Speaker
So that's sort of how I see it and how I'm trying to live
Closing Thoughts: Curiosity and Collaboration
01:00:21
Speaker
my life. But of course, i have a lot of life left to live. It's kind of quaint again, but that's sort of, i guess, my closing thought.
01:00:29
Speaker
Well, my takeaway is I need to read more books and stop watching TV. because that was That was deep. I liked it. It was not my choice. would talk to my parents about that. Hey, that's good parents right there. I wish I had done that with my kids.
01:00:44
Speaker
All right. Well, this has been fantastic. Thank you. Thank you, Matt, for joining us. um and That's it for this episode of the Forward Slash Podcast, where bold ideas shape what's next in IT.
01:00:55
Speaker
Subscribe, share, and stay curious. We'll catch you next time.