Crafting Code Podcast

[00:00:22] Allan Stewart: Allan Stewart, Software Architect, and Lately, I've been thinking about how your perception

[00:00:28] Dave Adsit: of events is altered by sickness or mood. I'm Dave Adsit, a VP of Engineering, and I have lately been thinking a lot about preparation for major life events and preventing and minimizing

[00:00:40] Allan Stewart: the impact of illness. Our topic for this episode is skill and experience biases. Developing skills and gaining experience is very important. It is what lets us grow as software developers. It's something that we're often seeking. We want to grow in skill. But it can also lead us towards some biases that we should be aware of.

[00:01:02] Dave Adsit: Yeah. So the very first bias, first thing that comes to mind is the Dunning-Kruger effect, which is a cognitive bias in which people with limited competence in a particular domain overestimate their skills. And related either the same or as a corollary is that people with a lot of experience, very high performers in an area, Minimize their skills, right? So what tends to happen is that if you ask people to self-evaluate, people who have low skill will overestimate and say, ah, seven or eight out of 10. And people with very high skill will underestimate and say, I'm probably a seven or eight out of 10, thus leading to self-evaluation being not particularly valuable. And there's a lot of But one of them is that you only know what you know, and you assume there's a little bit more to learn, but no matter what you assume there's more to learn, but not a ton more to learn because you've already started to develop skill in this area, which is why people with low skill tend to overestimate people with high skill tend to underestimate. And it leads to kind of that, that old saying, you don't know what you don't know.

[00:02:22] Allan Stewart: Yeah. Yeah. I think this is kind of, maybe it's not the starting point, but it's near your starting point in a lot of cases. And obviously this is going to affect somebody who is new to the industry, right? Somebody who's brand new software developer, they're just getting started. They see all the cool things that they can do. Like, oh, well, I made this cool project, you know, my AI helped me build it. And so here we are. But I think it also applies to us recurringly, right? Like every time in the industry, like something new will come up and we'll say, oh, well, I know. I know about that. But, you know, there's too many, there's too many things you can't know about, you know, all the details of mobile and embedded systems and blockchains and, and, and the latest framework, right? Like there's always something that you're getting introduced to. And so there's always that opportunity for you to, to just wade in the water a little bit and be like, oh, well, this is like other water that I've been in. So I must know about that. Must be good at swimming in it already.

[00:03:29] Dave Adsit: Right. I think that one of the things that I have felt is that software engineering or software craftsmanship, that is a skill. Great. What's my skill level at it? Well, let's break it down. How many skills are there that are part of that skill of software craftsmanship? I've got front-end web development, back-end web development, system development, database management. There's an almost unlimited, unlimited number of sub skills and sub sub skills that we develop over the course of our career. And we get better at some as we use them more, and then we can let them atrophy as we forget, or as we don't use them. I used to spend a lot of time doing database migrations for an insurance company. I haven't done a database migration in a very long time. And if I were to do it now, I would do it as more of an iterative type of a job. Most recent database migration I did, we did iterative type of a migration where the ones I did for the insurance company were batch. You know, we would stop processing at the end of the day and then run our batch conversion process and then start processing in the next day on the new system. Most of the systems I work on now, you can't stop them at the end of a day because they run 24 seven. So we have to have different skills and different techniques for doing that. And so the skills that I developed over years of as much in a world of 24 seven, high availability, low downtime systems.

[00:05:04] Allan Stewart: Well, it's interesting to I think about how often you fall back to things that sound easier, even even after you've convinced yourself. So so like with a migration like that, sometimes it sounds easier. It's like, well, but if we just took the database offline, and then did a big update, and then brought everything back like that, that would be easier, right? Like, because we don't have to put up all this, scaffolding, and other stuff that we have to do to do it in a more iterative or, you know, kind of dual writing, dual reading scenario. But it's safer, right? And it's the same problem that we get with the big bang rewrite. Yeah, you look at a big problem, and you're like, Oh, wow, this is going to take a really long time to fix. And it's just so tempting to say, well, we could just rewrite it faster. If we weren't fettered by all the constraints of the existing But it almost always turns out that it takes a lot longer, because the existing system was doing a lot for you. And if you throw that away, now what is doing that for you?

[00:06:09] Dave Adsit: Well, and you don't know what those things are, in many cases. The reason why it seems simple is because you are not taking into account all of the actual requirements that were put into the system over who knows how many years, right? Yeah. So that's interesting, because that is kind of the opposite of one of the points I wanted to make. That is, I have low knowledge, therefore, I have high confidence. One of the things I wanted to point out is that in general, when we have low knowledge, or low skill in an area, we're going to have a lot less confidence in that area. And we're going to want to move more slowly, more deliberately. One of the things I've observed is people will over plan when they have low confidence about a

[00:06:54] Allan Stewart: thing. Yeah, I feel like it's kind of how you graduate out of Dunning-Kruger is you've now realized that there is a lot that you don't know, your confidence level is down. And so you assume that it's going to be really hard. You assume that there's going to be a bunch of, you know, pitfalls and things. And you know, there usually are. But there's a tendency to maybe over, overanalyze or exaggerate the, the difficulty of something just because you're not familiar with it.

[00:07:26] Dave Adsit: Well, and this is one of the things, when we talk about the, the waterfall method, which was very, very rarely ever used. Most people just didn't have a software development life cycle or method that, that the idea that formal waterfall is used a lot is kind of a myth in our industry. But it does start with a very deep analysis phase, we're going to analyze everything. There was a book I had from Microsoft Press that was analyzing requirements and defining solution architectures. And it was like 900 pages. It was a tome, if ever I have read a tome. And it was about how do you, all the things you need to consider at the beginning so that you can make sure you've considered everything and plan for everything, because you're only going to get one shot at writing this software system. And it has to be perfect, which is different than what we do now. Now we've said, Hey, you know what? We're not going to just do it in one shot. We're going to iterate a lot. And so we're going to get good at a different set of skills, but you can see why that was a way. Speaker 1 Speaker 2 Speaker 1 Speaker 2 Speaker 1 Speaker 1 Speaker 1 Speaker 1 Speaker 1 Speaker 1 Speaker 1 Speaker 1 Speaker 1 Speaker 1 Speaker 1 Speaker 1 Speaker 1 Speaker 1 is always the easiest step, right? And so you can see how when you have a lack of confidence in your ability to do something, planning a ton is a natural tendency. It's a way of addressing the stress or the anxiety of the unknown is by over-planning. I mean, I will tell you when I was a little kid and playing Dungeons and Dragons for the first time, I wanted my character to have every single item on the equipment list in case we ran into a scenario where it came up. But having gone hiking a few times, I don't want to carry a bunch of unnecessary equipment.

[00:09:33] Allan Stewart: So I'm going to bring more skill, right? Like that's on the equipment list, right?

[00:09:39] Dave Adsit: It is. No, it wasn't at the local general store. But I want to bring more skill so that I can bring less equipment because equipment is heavy. And skill is hard won, but doesn't weigh anything.

[00:09:53] Allan Stewart: I like that. So then I think... I think one of the next biases that we run into is once we start gaining skill, and it's related to not having confidence as well because as you gain skill in one area, you want to lean on those skills that you're really good at. Right? This goes to the old adage, if all you have is a hammer, then everything looks like a nail. So I already know how to do web development. I already know this framework. I already know this backend language. I already know this database. I already know this. I already know this frontend thing. And so I just want to use those. And it kind of feeds into the low confidence bias because picking something else is an unknown quantity. And so even though there might be good reasons to try something new or maybe there's a different technology that is a better fit for the problem domain that you're in, it's really easy to just say, well, this is a nail sort of problem because... I have the hammer that I have carefully curated over these many years.

[00:11:01] Dave Adsit: Yeah. One of my early jobs, we used an Oracle relational database and we knew the Oracle relational database really well. We knew how to write packages and procedures and Oracle released an update that allowed you to serve HTTP directly from the database. And we're like, yes, do that. Because we know how to do that. And so we wrote packages and procedures that returned HTML. And we're accessible via HTTP. I would not do that now, but I have a lot more tools in my toolbox now than I did at that point in my career. And so it seemed like an okay idea at the time.

[00:11:37] Allan Stewart: Yeah. For me, another kind of related example is that I was doing a lot of Flash-based development around 2010, 2011. Rich internet applications were all the thing. And there was a lot of people working in Flash. And it was a really good language. There were some really cool things that you could do and then you could put it out on the web. But for good or for ill, Flash was not destined to remain with us. Even though there was a pretty wide gap between what HTML could do at the time and what Flash could do. I think by now, HTML has more or less caught up. Like the whole HTML5, the HTML5 advent on the scene. But it definitely colored my perspective of some jobs at some point because, well, I already know this or this is what we use. This is the way that it is done. And so that was my bias was towards, well, not only do I know this really well, but this is how it has been done. This is how we have been doing it. And so it can be difficult to see when the time is right that you need to change your trend. And I think one of the important counters to this kind of a bias is to get some breadth. We've talked about T-shaped people in the past, but you don't want to be so, know a tiny bit about everything because then you're too shallow to really make an impact or do anything particularly useful with all of these various skills that you're very, very shallow in. But if you go too deep in one, one skill, then that's your hammer and you're going to see nails everywhere you go. There's a kind of happy medium where you hit that T-shape or V-shape or paint drip and you say, okay, there are many things, you know, especially adjacencies that I am good at. I'm really good at this database, but I know enough to be dangerous in these other two or three databases so that if it's the right fit, I'm not stuck to this one tool because it was just the only thing. That I knew how to do.

[00:13:56] Dave Adsit: Yeah, I think about that a lot because, you know, obviously I've worked in a bunch of different tools and a bunch of different developed skills in a lot of different areas. And that can also lead to its own form of analysis paralysis, like trying to find the perfect tool when, you know, often good enough is good enough. So one of the things I think a lot about, we've talked a little bit about how having high confidence means that you don't have to plan as much. I'm reminded of one of the conference speakers that I really enjoy. He told a story about the first time he organized a conference. He hired a professional conference organizer and then he presented her with all of his lists. And he had all the lists of things that had to happen for the conference to be successful. And all of the lists referenced other lists, which may have referenced third or fourth layers of lists, like all of the things because he had no experience running a conference and he wrote down, everything he thought of that needed to be done so that he didn't forget anything and didn't mess anything up. Meanwhile, he hired a professional event planner who came in and said, okay, this list and all of its children is this bullet. And we're going to do this bullet properly, but don't worry, I have arranged a facility or ordered chairs or ordered tables or whatever it was. Like I know that for the 500 people who are going to show up, we're going to need this many chairs and this many tables. Right? And. And a lot of things as you gain experience, you don't have to write as much down or plan as much in as much detail. You can really start to think and act and talk and plan at a higher level of abstraction. And that becomes very valuable to us as we develop skill in an area. We've talked about it in the past as pattern languages with very experienced developers who know their software patterns and whatnot. We can say things like, Hey, I want to set up a new web application. It's going to be, it's going to serve HTTP as the API with Jason and payloads. And we're going to use a workflow pattern on the server side, and we're going to do a repository pattern and we're going to use a relational database. And we all know where to start with that. And if you're very new, you might have a lot of questions based on that very, very brief description. Like what is a pattern? . . . ! What does the bullet mean? And so when you're doing something like this,

[00:17:11] Allan Stewart: something like this and something like this and something like this and something like this and something like this and something like this and something like this and something like this and something like this and something like this and something like this and something like this and something like this and something like this and something like this and more skill, right? Like, or it gives you more power to be able to handle a lot of things that are going on, right? So as you build up your skill, you build up your experience. As a developer, you're more able to handle things. But then interestingly, I feel like it's kind of mirrored into your code as well. As you get better at writing code, and you write better and better code, you are employing abstractions in a better way. I think it's really important that you are consistent at the level of abstraction, right? A lot of messy code that I've looked at, part of the reason that it's messy is that the abstractions are all over the place, right? You've got a single function, and in one place, they're reading from disk or, you know, talking to a database, and in another place, they're calling out to an external service, and in another In another place, they're building, you know, part of that HTTP request. And in another place, they're printing to the console, or they're writing and writing a div for the DOM. And it's like, okay, whoa, some of these things are different, right? Not just different in like different responsibilities, but they're different, different levels of abstraction. And when they're mixed up like that, it becomes very difficult to navigate. But if you organize those abstractions really well, and you just say, Oh, yeah, load. Okay, yeah, I know, that's going to go and load from the database or the disk or, you know, print. Okay, I know that that is going to go off and do, you know, whatever console writing needs to happen, then you're, you're at a place where you're not, not quite so lost.

[00:19:01] Dave Adsit: Well, an abstraction is one of the ways to talk about the two fundamental tensions in computer science between coupling and cohesion, right? If we go back to software is all about balancing coupling and cohesion, we want highly cohesive concepts and loosely coupled concepts. And if we can find a highly cohesive concept and create an abstraction over it, now we can use it much more easily and readily than if we leave all those pieces scattered. And so I really like that. I really like talking about the, how abstraction is one of the more powerful things that we get in software. And I agree that being operating at different levels of abstraction, it can lead to very messy code. Very challenging to work in. Yeah. Or even to reason about.

[00:19:47] Allan Stewart: Yeah, I think it makes me think about that, that interesting dynamic there. And it's related to the socio-technical systems that we often talk about, where it's not just about code, it's also about people. And as people, we also have to deal with abstraction in various ways.

[00:20:05] Dave Adsit: So I'd like to tell a story about, or a kind of experiences that I've had with a concept at different levels of skill and experience. And that concept is live coding during a conference talk. When I was a very new conference speaker, early on, the very first couple of times I went and spoke at a conference, it was just a little local conference here in Salt Lake. And one of the, they offered a training for new speakers, because that was what they were trying to do, is help develop this skill in the community so that Right. And so they had somebody who was experienced give us a presentation on how to, how to prep a conference talk. And one of the first things he said is, do not live code during your presentation. He's like, if you do, you're going to get flustered. You're going to have a bad time. That seemed like really solid advice to me at the time. And so, you know, low level of skill, don't live code, create your code ahead of time, take screenshots, put them on your slides, show the code if you want, that's great. But don't try to live code because you're going to get to a point where your code just doesn't work. Speaker 2 Speaker 1 Speaker 1 Speaker 1 Speaker 1 Speaker 1 Speaker 1 Speaker 1 Speaker 1 Speaker 1 Speaker 1 Speaker 1 Speaker 1 Speaker 1 Speaker 1 Speaker 1 while. I saw a couple of people who did a version of that where they would pre-record a video of them self-coding. And then while they were at the live coding portion of their talk, they would just play the video. And that gave some advantages. Like you could play the video faster than you can actually type. You know that you're not going to make any mistakes because it's a video. You're just playing it. I wasn't ever, I wasn't ever very good at the lip syncing along to myself coding previously part of it. So I didn't do that one ever. After a while, I was giving a couple of talks that I felt like really benefited from just doing the code. They were on refactoring, specific refactoring techniques. And so I just like, you know what? I'm confident. I have skill. I've done this a hundred times at work. I can sit down and I can refactor this code live with the audience. And I did that for a while. And that was really fun. And every once in a while, like not every conference, not every time I gave the talk, but every once in a while, something would go wrong and I would have to live debug my refactor. And sometimes I'd be like, okay, well, you guys are all my pair. We're all pairing on this together. What did I do wrong? And just engage the audience and make them be part of it. Because at that point I was confident and had developed a skill, right? So in this particular case, there were actually two skills at play. One is the skill of presenting to an audience and engaging with an audience. And being there and aware and entertaining, I guess, with an audience. And the other one is the skill at coding. Like I was doing specific things. And so I needed to have the skill to write the code and refactor the code and all of that. But I also needed to have the skill to engage the audience when things were either going well or not so well. And so that was a way that I approached having different levels of skill over time with a specific thing. That I was trying to do. Back around that time, I don't even know, maybe a decade ago, it was kind of popular or fashionable to have people present Kata's at software conferences. And a Kata is basically a practiced solution to a problem. And some of the people would do, they would do their Kata to music. So they would take the problem and solve the problem over and over and over and over and over with music playing. And try to time their coding to the music. So they'd be simple things that you could finish in three to five minutes, right? And that was really popular and really entertaining. And it was the kind of thing where people would practice several times so that they could be good at it before they went and performed in front of an audience. But there's also lightning talks that are similar to that. And if you've seen Gary Bernhardt's talk Watt, that was recorded live in front of an audience. I actually happened to be there when And that one was recorded. It was actually pretty fun to see what was happening with the code as he engaged with it. But it was all 100% live. Like there was no pre-recorded video. But one of the things that he did is he prepped his talk ahead of time and he practiced and practiced and practiced. And that was actually a business model that he had where he was doing these short trainings on how to do specific things in Ruby and JavaScript and whatever at the time. And he would record these videos and he would get to the point where he was just really good at going through and doing the whole training in one take and recording it and then putting it out to his audience. So that to me, that's some examples of ways that different levels of skill and experience lead to different behaviors and implementing different practices and how that can actually be a really powerful way to work. As an individual.

[00:25:42] Allan Stewart: It also reminds me how as soon as you start combining things together, all bets are off almost, right? Like, hey, I know how to present to an audience. I know how to code. So therefore, I should be able to live code in front of audience. And that's not necessarily true. Like the combination of skills can sometimes require experience of its own, right? Like you combine. You combine two things and now you need an emergent skill that encompasses the two. And I think that happens with a lot of software development, right? It's not just for presentations, but now you need to combine multiple skills together. Like if you just know databases really well, you might act a different way than if you know databases and web, whatever that you're using for your API language. Right? Like, and now as you get more and more comfortable with the API, then you say, oh, well, maybe some of the things that I had been doing in the database, I don't want to do it there anymore. And I'm going to do it over here or vice versa. You might push some stuff into the database as you get more comfortable with, well, you know, the database is really better for this, or we should be optimizing in a different way. Or maybe we're going to do something really complex and like CQRS, right? CQRS. CQRS isn't something that like each of the individual pieces isn't that hard to understand, but you start putting it together and then all of a sudden you get people like Martin Fowler saying, this is a great idea. Don't do it. Or at least don't start there. Think about it real hard before you apply this, just because it is a combination of other skills.

[00:27:36] Dave Adsit: Right. Well, and anytime you try to get into a distributed system like a microservice or a cloud service, like architecture or SOA architecture, you're going to run into a lot of those things where it's like, well, I'm really good at writing APIs that return JSON blocks. And I'm really good at connecting to a queue. I'm not really good at putting all of these things together into a working system that does not fall over as soon as production load hits it. So when we talk about skills, so far we've been talking about like individual skills, like internalizing the concept of skill and experience and how we behave differently based on skill and experience that we have.

[00:28:35] Allan Stewart: ready for the thing that you're doing. There was a talk by Dan North some years ago. I think it was at GoTo or someplace like that. And he talked about, he called it Dreyfus squared, looking at the Dreyfus model of skill acquisition and how that plays out when you have two different people. And so if you have an expert working with a novice, what kind of situation do you have there? If you have two novices working together, they might be really happy, but don't, like, they're learning a lot. They're figuring out so much stuff, but don't ship that stuff to production. Please don't. Yeah. So, yeah, I think being patient with people and realizing it's like, oh, well, just because you're strong in an area, that doesn't mean that they're ready to just jump in and do that because they might not have the requisite confidence. And they need a, you know, 17 nested level. Bullet point plan so that they make sure that they understand everything that's going on.

[00:29:38] Dave Adsit: Yeah. I think that that's, that's actually really important. I think that specifically in the Dreyfus squared thing, when you have someone who's expert in a thing and talking at a really high level and going really fast and someone who is a novice level and they're really, they can get overwhelmed very, very quickly. And so now you have to make a decision. How, how are we going to, how are we going to address this on our team? What is the dynamic Do we want to slow the expert down to teach? Do we want to find two experts and just say, go get it done. And everybody else will be over here trying to figure out what you did. I think that one of the things that we have to do is we, we really have to, if you have more skill than the person you're working with in a certain area, you really need to give them the grace to learn. Someone did that for you at some point, maybe you did it all on your own and good for you if you did, but most of us have worked on teams for most of our career and we have learned from others and that's been a way to learn faster and go further. Right. You know, they say we, if we see further than those before us, it's because we have stood on the shoulders of giants, right? That concept is real. Like if you are lucky enough to get onto a good team early in your career, you can accelerate very quickly. But we need to give people grace to learn and grace to, be uncomfortable and feel the need for more detailed instruction planning, et cetera. Right. If, if we're going to kick off a project and I'm like, Hey, Allan, let's just go figure this out. You and me, we're going to go write some code and we're going to solve this product problem for customers. We are pretty sure we understand what is, what the problem is they want solved or what, what they're trying to do. And so we're going to build something for them that does it. You and I might feel very confident to go off and do that. But if we are working with If we are working with somebody who is less experienced in the domain or the, the customer base or the product, or, you know, any of those areas, they might want a lot more detailed and a detailed plan to execute against. I want you to break this down into tasks and I'll do a task. I don't, I don't want you to tell me to go tackle a whole user story or an Epic. I need, I need a task and I will report on my progress on my task tomorrow at standup. Um, and that has to be okay because,

[00:32:05] Allan Stewart: Yeah. And I think it becomes more and more important that you do so as you're making more impact in an organization, right? When you are just, just another one of the coders on a team, then it might not be that important for you, especially depending on how the team works. If you're doing a lot of collaborative coding, well, you're going to kind of work together and even each other out. If you're working solo, well, and you don't worry about, well, you're going to do something and you're going to do something and you're going to do something and you're going to do something and you're going to do something and you're going to do something and you're going to do something and you're going to do something and you're going to do something and you're going to you only got there because you did develop a bunch of skills. And now you need to be able to work with people who aren't almost by definition, don't have some of those skills because they haven't

[00:33:13] Dave Adsit: worked up to get them yet. Well, and I would say it goes even beyond that. One of the things that I have to remind myself of regularly is I have some number of years of experience building software systems. It's a large two digit number. And other people I work with, even other VPs in other roles and other disciplines don't have that experience. And so when they come to me and say, Hey, we want X, Y, and Z, and they want a very detailed plan, like plan me out the Microsoft project plan or a Gantt chart or whatever. And I'm like, I'm not doing any of that. You asked me to do a software thing. I'm going to go do a software thing. I'm going to do a software thing. I'm going to do a software thing. They're not necessarily comfortable with that because they don't know what that means. You, and even worse, they've been told the same thing before by other VPs who lied to them, whether intentionally or not. Right? So if I say, don't worry, I've got it. My team is going to go build you that feature. I'll let you know when we have something for you to look at that might not be comfortable for the other VP who has been told such things. In the past over and over and over by engineering leaders, whose team didn't know how to build it and couldn't deliver it, et cetera. And that, that can be a very uncomfortable place. And so recently I kind of had that epiphany where I was thinking, why is this person want so many check-ins and reports and whatever? And like, Oh, cause they don't, they, they are very low level of skill in delivering a software product. And that's okay because that person's expertise is not building software. That person's expertise is something I don't understand. Like, I don't know the details of accounting or, or web marketing or whatever, but, um, I am also not trying to understand it. And, and my job isn't dependent upon it. Whereas your marketing team's job might be very much dependent on whether or not you as a software engineering team can deliver anything that works

[00:35:16] Allan Stewart: at all ever. So another bias that I think about a lot is, um, I, I think it's a form of survivorship bias. Speaker 1 Speaker 1 Speaker 2 Speaker 1 Speaker 1 Speaker 1 Speaker 1 Speaker 1 Speaker 1 Speaker 1 Speaker 1 Speaker 1 Speaker 1 Speaker 1 Speaker 1 Speaker 1 Speaker 1 Speaker 1 Speaker 1 Speaker 1 Speaker 1 Speaker 1 Speaker 1 Speaker 1 But we have to be careful with that because it also can be a bias. And it's not an unreasonable bias because in a lot of cases, I mean, that's one of the reasons we build up experience in the first place is so that we can have these understandings and say, okay, we can take some mental shortcuts and we can work very well with what we know. But I think it's very important for us to leave space in our minds to say, hey, okay, hold on. I'm not the same as I was before. The world has changed since then. I'm in a different situation, a different context. Maybe this time it makes sense. And of course, that's not always going to be true. But I think leaving at least a little bit of space to say, okay, somebody else has had a different experience. And that is. Leading them to want to do this thing. And that might be because like in your example, they don't have a lot of experience. And so they're, they're worried. They don't have high confidence, but it could also be that they have a different experience from you. Like, oh no, I have done this and it worked successfully and we all thought it was great. And so we want to replicate that now. And I I'm definitely somebody who wants to replicate the, the successes of my past. So. I got to leave a little bit of room open to say, okay, tell me more about what made this successful. And can, is there a way that we can apply that here in, in our, in our current situation?

[00:37:29] Dave Adsit: Exactly right. I personally have a lot of experience being burned by giving estimates, being held to estimates as though they were contracts and being like raked over the coals when things took longer than where they were estimated to be. Despite the fact that scope changed or complexity was discovered or whatever. Other people have a lot of experience being burned when they don't follow a very rigid project plan. I am reminded often of one of the key differences between a marketing mindset and an engineering mindset is in product development. We build a product and we ship it and we iterate on it over and over and over and over. And every feature we ever build has to be maintained. It has to be it. It becomes over. part of the baggage that we carry forward with us forever. And we never know how long anything's going to take to do. That's kind of my product development experience, my experience, probably similar to most product development engineers. Marketing, on the other hand, does things in a very different way. They will run the same type of marketing campaign over and over and over and over with new copy, new images, new creative, whatever. You're going to typically run it on similar channels, maybe a slightly different channel this time, but you know how long it takes you to do the creative and the copy and put it together and approve it and ship it. And when it's done, it's done. And so it's a very fundamentally different mindset. You don't ever have to use any of that marketing copy or creative again in a future campaign. It doesn't become baggage that weighs you down over time. Like you're sure you're building a brand and your brand hopefully but your brand and your campaigns are different where, so this is one of the reasons why I see a lot of tension between marketing departments and engineering departments is that people are not understanding each other's context very well. When marketing is like, what do you mean the feature we built two years ago is why I can't have the thing I want today. That feature was two years ago. Who cares? Right? And engineers are like, what do you mean? You know, it's going to take you six weeks to launch a campaign. You haven't done this campaign. How could you possibly predict it's going to take six weeks? You're like, well, I've done campaigns very much like it a hundred times in my career and they all take six weeks. It's going to take me two weeks to do copy and a week to do creative. And like, you know, it's very fundamentally different contexts. And, and so it, we have developed different skills, which lead us to different conclusions and can create tension

[00:40:05] Allan Stewart: across the team. Yeah. Yeah. I think it's very important for us to put trust in the people, especially when they have different, skills than you because you're, you know, your skill level is low. And so your confidence level is low and you just kind of have to, to trust that people are going to do what they can do because it's very difficult to just grab all of that and try to do it all yourself.

[00:40:31] Dave Adsit: You don't, you don't get very far. Yeah. Yeah. And I mean, this is an example of a skill that I have failed to develop despite years and years and years of practice how to do something so well and knowing how to do something so well and knowing how to do something so so well and knowing how to do something so well and knowing how to do something so well and knowing how to do something so well and knowing how to do something so well and knowing how to do something how to do something so well and knowing how to do something so well and knowing how to do something on where the other person is coming from so that we can create better relationships and build better teams that deliver better software and systems, right? If I have a high level of skill and experience, I'm going to approach a problem differently than if I have a low level of skill and experience. But I also need to recognize where the people on my team are and how they're

[00:41:33] Allan Stewart: coming at that same problem. Absolutely. And so with all these biases, I think it's important to recognize them. Thinking about where do we sit with our own level of skill? What have we internalized? How are we interacting with other people? And by being aware of the biases, it doesn't make them go away. You're still going to have them. You're still going to be influenced by them. But if you can recognize them and recognize the effect that they have on you, then it gives you a better chance to deal with them in a more positive, proactive way.