Crafting Code Podcast

[00:00:16] Allan Stewart: Welcome to the Crafting Code Podcast, where we discuss the importance of doing the right thing at the right time with the right tools. I'm Allan Stewart, a software architect, and lately I've been thinking about the perils of foreign keys, especially when those foreign keys are made up of email addresses.

[00:00:34] Dave Adsit: I'm Dave Adsit, a VP of engineering, and recently I have been thinking about how slow and painful it can be to integrate a third-party application or API into your system.

[00:00:44] Allan Stewart: Our topic for this episode is expertise and collaboration. In our last episode, we talked about skill acquisition models, such as the Dreyfus model or Shu Ha Ri, as ways that we can understand. How we acquire skills and we can evaluate where someone is with a particular skill. And we can use these concepts to help us understand the dynamics that form as we start working with multiple people. And those people have different skill levels and they're trying to interact with each other.

[00:01:18] Dave Adsit: One thing I'd like to point out immediately is that collaborating with others, whether it's pairing, mobbing, whatever. We have to develop and we get better at over time. So even if we have high skill in various areas, when we come together, that doesn't mean we're going to be good at working with others. Right.

[00:01:42] Allan Stewart: And depending on how you want to work, the collaboration could be we get together in the morning and we have our standup meeting and then everybody goes to their own cubicle and works in their own silo and never shall we speak to each other again until. The next stand up meeting or the next merge conflict or whatever that is. Right. The next time you have to talk with your boss, right? There is collaboration happening there if you're not working truly solo.

[00:02:12] Dave Adsit: So what follows is a discussion that assumes at least a basic level of skill with collaborating with others. Sure. It does not assume absolute novice at working with another programmer on a programming task.

[00:02:26] Allan Stewart: Right. So the first thing that we wanted to talk about is this concept of Dreyfus squared. I was first introduced to this because of a talk given by Dan North at GoTo 2017. And at that conference, he, he called it patterns of effective teams. And he basically lays out kind of a grid. He takes the, the different levels from the Dreyfus model and, and creates a two dimensional array of it. Right. So we can say. Okay. Hey, we've got two people and there are all these possible pairings that can, that can occur. And so then he, he talks about different, different ones. He starts off with talking about what happens when you pair up a novel novice with an expert. And his quote was someone dies. Right. Either there's somebody, either the novice is killing the expert with all of their questions. Tell me what to do. Or the expert is saying, if you don't, if you ask me one more question, I will kill you. Why is that? Why is it that novices and experts have such a hard time working together?

[00:03:41] Dave Adsit: Well, anyone who's ever been around a three-year-old and their favorite question is why knows immediately. But also I would say that one of the big challenges is that you are not speaking the same language. You don't have shared mental models or concepts. doesn't get it. And so they don't have language. They don't necessarily have language for bringing the concepts to the place where the novice can understand them. I was listening to another podcast a while ago and it was talking about a guy who had been working in a mathematics department for his entire life, basically went straight from college into being a math professor. And when he worked, he couldn't work with undergrads at all because he could not understand how someone did not understand differential equations. What is your brain like that you can't do calculus just without, as though you were breathing? And so that level of expertise, you completely disconnect from the idea or from the, where the novice is coming from. And you just can't. A, you don't want to slow down that much. B, don't have the language to communicate with them

[00:05:26] Allan Stewart: effectively. And you just find it frustrating. I feel like slowing down is the hardest part for me in this particular pairing because I forget. It takes a minute and I've forgotten how much somebody else doesn't know and how many years it's taken me to figure this stuff out. So that's the one that really gets me. But we'll talk a little bit more about experts and novices in a minute. Let's consider another pairing. Dan North gives us another pairing, which is an advanced beginner with another advanced beginner. This one he calls Mayhem. And he also says that it is a super productive time. Don't put any of it into production. Yeah. Yeah. level, right? When someone's an advanced beginner, they still need a lot of rules. They still need to be told what to do, but they've left the novice position where they don't even know what to do and they need total instruction. They can start to play around a little bit themselves within a certain capability. And so put two of them together and they'll do that together and come up with all kinds of ideas of what to do.

[00:06:49] Dave Adsit: Yeah. This kind of mayhem, I've experienced it before. It's super productive in terms of quantity of code produced because, I mean, we've worked on systems where the developers didn't quite know how to solve a problem. And so they just kept adding code until their manual testing revealed that it kind of worked, right? And that is advanced beginner with advanced beginner. There's nobody guiding their hand to the right design. The right patterns, the right cuts to make and the right things to implement. So they're just throwing stuff at the wall and sees to see what sticks.

[00:07:29] Allan Stewart: Yeah. It's, it's a ton of learning. And the thing is that a lot of the learning comes from failures, right? So some of them will be like syntactical failures. Oh, that didn't work because you can't, you know, that that's not the right syntax for this language, but other kinds of errors. Yeah. And then there's also the ones that are ones that will take a little bit longer to, to reveal, like, oh, I just, I, now I have a kind of visceral sense for why you don't want to have just a sprawling, huge, massive code. Yeah. And it's not until they get to the end of the process that you can start to learn that.

[00:08:06] Dave Adsit: Right. And you've got things like, oh, what is an N plus one error? I've never heard of it. And so, you know, there's a, there's a lot of things that can just happen that anybody with more experience. Yeah. Would have guided the advanced beginner away from it because neither of them has any experience. They're just going to go forward and they're going to do some exciting things. You're going to come up with some solutions that an more experienced practitioner would never have considered for better and worse, mostly worse, but occasionally there's like a little nugget in there. That's just gold. Well, the next one, the next pairing from Dan North, I'm going to go through it. So Dan North is the novice with the competent practitioner and his description of this is that it works really well. What works well about it is that you have someone who knows what they're doing. Someone who is competent has been around enough. They've done enough that they know how to do software. And when they're working with a novice, they're doing a lot of teaching and they're guiding the novice away from a lot of pitfalls that they would potentially otherwise fall into. The competent person hasn't fully transitioned into the realm of intuition. They still know the rules. And so they can communicate those rules to your novice and they can communicate a little bit more context around those rules, et cetera, because they've been around for a while. One of the interesting things is that because they're journey. They're still speaking similar languages, right? They haven't transitioned to the point where they're, you know, neither of them is completely inept at communicating with the other. And while they may make mistakes, they will make mistakes together, which is an opportunity for learning on both sides. And the novice gets to see that it's actually okay to make mistakes and you're not going to be judged. That harshly for them, you can making mistakes as part of how we learn and grow. So it's a lot of meta learning on top of the directed specific learning.

[00:10:27] Allan Stewart: I think one of the interesting questions that comes up in this pairing is why, and the kinds of why questions that get asked, right? So at this level, a lot of the why is rules-based, right? Cause they're still thinking there's most of the discussion is in a, in a rules-based And in the rules-based language, there's going to be questions about, oh, well, why can't you do this? Why doesn't this work? Why do I want to pass by a reference or by value? Right. Cause those are all like fundamental rules of programming kinds of things that would, that come up. But why questions that you get a lot less of is why would we want to do this? Why would we want to avoid a problem? Because a lot of the times it's just, oh, well, this is just how it works. this is just how we do it. Not why do we do it this way?

[00:11:22] Dave Adsit: Yeah. Yeah. This is what we do here. This is, this is, I was told to do it. So I'm telling you to do

[00:11:28] Allan Stewart: it. The next pairing that Dan gives us is proficient plus expert, which he says is one of the most powerful pairings. And here we starting to move into that language of intuition, right? Um, the, the person who is, is proficient, right? They're, they're above a level above just competency and they're really exploring the space, right? Uh, if we took it back to like shoe Hari, this is like a ha and a re working together. You've got the person who is, is starting to branch out working with somebody who, right. Like the, the, the, the person at that, that proficient level, they're, they're wanting more masters, uh, more, uh, schools of thought that they can start learning from. And, and an expert can provide that.

[00:12:22] Dave Adsit: Yeah. And I think that when you start to get to this level, the why questions are going to transition into why would we do this? Why would we follow this pattern instead of this pattern? Why would we use this architecture instead of that architecture? And they get a lot more, I was going to say interesting, but I guess what they really do is get it. They get a lot deeper. You know, the why is interesting to the person asking it at every level. But when we are at one person has fairly well-developed intuition and the other person has intuition that's developing and they're communicating in that language. The why questions become more philosophical, more experiential experience-based, like, you know, like, let me tell you a story type of answers happen a lot more often. And I think that this is, it's a general case of the, or a specific case of the general rule. Yeah. A person at a level paired with a person at the next level tends to work really well because the person at level plus one, they were just at level. And so they remember what it feels like to be there. They, they just walked those footsteps. They can help you with that path because they have not yet forgotten it. Where, when we talked about expert and novice, the expert completely forgets what it's like to be a novice. It's hard to put yourself into that mindset of like, I don't know. Yeah. Not knowing anything. But if the person is just one level ahead of you, they can help you get to where they are a lot more easily because they still remember where you are.

[00:14:00] Allan Stewart: I think that this pairing also may be more goal oriented rather than task oriented. I feel like, you know, when we were talking about novice and competent pairing together, they're going to focus a lot on tasks. What needs to be done and how do we do it? Whereas, when you get further along that skill spectrum, you can start thinking more in terms of goals and say, because you, you know how to do it. You have a broader experience to draw from as far as, well, here are patterns that we know work and that we're experienced with, which one is going to better suit the problem at hand. And so we're really thinking about the goal that we're trying to accomplish from like a, from like a business or outcome perspective, rather than, well, this is what I was told needs to be done next.

[00:14:53] Dave Adsit: Right. And that's part of the definition of expert and proficient is that you're moving more into that outcome driven mindset versus the action driven mindset, like making sure you're doing the actions right. You're making sure that you get the outcomes you want. So the next obvious pairing would be expert with expert, which, uh, that's gotta be, be great. Right. Except that it's not always great. Um, I've seen a few easy failure modes, common failure modes for two experts. One of them is that it's unclear who is making decisions and they get, you get into either an analysis paralysis or just a stagnation of like no action is happening because neither of the experts wants to step on the other one's toes. Uh, another thing that I've seen is that these could be experts in different schools and there's nothing but conflict and either of them could lead you on a path to success. But when they are trying to take you on two divergent paths simultaneously, you're going to have a bad time. I will say that expert plus expert working together

[00:16:12] Allan Stewart: can be one of the most fun times working together. At least in my experience, because you feel like it's super productive. Things are getting done. It's not at the advanced beginner level where the two advanced beginners are enjoying themselves, but, but not able to ship anything at this, at this level of expertise, you can get some stuff done really fast. If, as you say, we're not fighting each other on the schools of thought and the, this is the way that we think that things should be done. Well, and I would like to add a

[00:16:47] Dave Adsit: little bit to that, that it's actually, you can build off of each other's knowledge to create something better than either of you could have made alone, right? It's the, it's the true two minds are better than one. It's the serendipity of the thing that came out was better than the sum of its parts. And so that can be great if you are aligned and you have a clear goal and you are okay with power dynamics. Right. I mean, I don't know how many times I've seen where I have some of my more senior engineers, they'll get together in a group and when we're doing like a, rather than working on our teams, we're working in a workshop or something. And I'll have a group of people who volunteer to go work on something together. And they just get stuck because nobody wants to be the one that says, this is what we're doing. Everybody follow me because everybody else is equally prof equal level of skill and could equally take the lead. And so I guess that is to say, they may not have a developed skill in taking a lead, taking lead in a group of equals.

[00:17:54] Allan Stewart: And as I think about it, I feel like it's interesting because expert plus expert could potentially work or it might be disastrous. Most of the other pairings where you're at the same level seem to work pretty well. Power dynamics are always going to be an issue. That's probably an issue of collaboration generally. Like regardless of anything else. But the one, but at the, at the sort of the bottom of the spectrum, novice plus novice is probably not nearly as effective as the advanced beginner plus advanced beginner, just because at that very beginning of knowledge, you don't know so much of the basics that you just kind of get stuck together. So it may, it may work out sometimes, but that, that I think is maybe another place where. That level of pairing just doesn't, it's not as effective because you're going to be reading the tutorial doc at different rates and you, you both need to kind of experiment and try with the thing rather than really being able to get together very well.

[00:19:05] Dave Adsit: Yeah. There's nothing quite like pair reading a document and asking if the other person's ready to scroll. That is a good, a good sign that you ought to maybe break up and go work solo, which will say that is one of the things, since we're talking about collaboration, one of the things that has come up a lot of times in a lot of different environments around collaboration is when you have people who are novice or even sometimes advanced beginner, and they feel like they don't know what to do. And they don't feel like they ever get the chance. If you're doing full collaboration all the time, you're always pairing, you're always mobbing. They often complain that they don't get the chance to go learn how to do the thing on their own. And they're either relying on somebody else as a crutch, or they're feeling stagnated in their own growth. And so every once in a while, people need to have some of that time to go figure something out on their own. And novice plus novice just exacerbates the whole thing because neither person really has enough knowledge to get anything done or go pick a direction and execute in it.

[00:20:07] Allan Stewart: So coming back to the concept of the extremes and you've got a novice and an expert, I came across a blog post. That I thought was really interesting. It's by a guy named Boyd Kane. And he has named this experts have it easy. And it's it's kind of a story or like a parable ask way of thinking about these extremes. In this post, he gives the example of a novice who is stuck in a maze, right, like a big hedge maze, or I don't know, they're like, you know, possibly some ancient Greeks there and the minotaur maybe. And the the struggle that the novice has while they're trying to get their expert friend to help them out. I think it's really interesting. There's a lot of insightful pieces in here. But some of the things that he calls out that I thought were really interesting. One is that experts can draw from their experience to know what ideas are likely to work or not. The novice is going to do a lot of research. And he's going to try some things. And they seem perfectly valid, from their perspective from their point of view. Hey, I'm going to try this. But an expert can immediately say no, that's not going to work. Don't even bother. And the difference is, of course, that experience that they're drawing from is like, Oh, well, you know, I've been in 100 mazes. And only once did that ever helped me. And so I can reasonably assume right. But, but it comes from that. intuition, right? And the decisions there become very second nature, right? What am I going to try? Well, I'm going to try the things that have worked for me in the past. And I know that this generally works in this situation in this dynamic. And so they're going to, they're going to be able to do that. Whereas a novice, they don't know, they don't know what things are likely to work. And they don't even know, sometimes that they're making a decision, or like they don't recognize that this was a decision point, or that there was a key detail that they that they miss.

[00:22:23] Dave Adsit: Yeah, and that I mean, that is one of the big challenges of being a novice is that so much is invisible to you. Because your knowledge is so low. And again, when the expert is guiding the novice, they there is a struggle to explain the decisions and explain the reasoning behind them, because an expert is operating from intuition. A lot of the time, and that intuition was developed by doing the work themselves, right? You've got you've done this 1000 times, you've seen the outcomes of doing this a bunch of different ways, and you know, which ones are going to work for you. And so you have intuition. And it can be hard to explain that to the novice.

[00:23:09] Allan Stewart: One of the things in the blog that I thought was kind of funny, but funny, and kind of like that sad, because it's true way, Because the novice will often spend a lot of their energy on like fixing their own mistakes, or dwelling on something that an expert would have discarded. Because they just, they don't know. They don't have, they don't realize that that is a thing. Or in the story, there's also a point where the the expert asks the novice, why didn't you turn it that last turn? And they're like, what turned? So they go back and they look, it's like, oh, well, there's like a little gap in the hedge here. But it doesn't look like a path. Like, it's not nicely laid out that here is, here is path. But the expert is like, you should go that way. You just slip through the hedge right there. Or, or the expert might say things like, oh, well, just, you know, pull out your chainsaw and cut down that part of the hedge. Right. But when you're in the novice mindset, that's you're in the rule following. know. And so you're looking for paths that are obvious. You're looking for things. You're not, you're not trying to circumvent systems. When sometimes that might have been the right,

[00:24:29] Dave Adsit: the right move to go with. Yeah. And it, it can be really difficult to get yourself into the headspace of a novice. We have talked before, I believe about the beginner's mindset, which is what you get when you bring somebody new into your system, right? When you hire someone new, and they ask you all of the questions and you have to find yourself explaining and rationalizing the system that you are working on. And like, you've just gotten used to the fact that in this one part, you have to do a series of dumb things to make the system work. And your beginner, somebody bringing the beginner's mindset is going to ask you, but why, why do you have to do all those things? Couldn't you just, and yeah, probably. We could spend some time improving this part of the system when we probably should. And then maybe it's a little bit embarrassing that we let this part of the system degrade so much because, you know, we just got used to it. And so we stopped working on improving it. Getting into that mindset can be a really powerful way to improve the progress of the group as a whole, both the, you know, working with somebody who is several levels behind you and is asking you questions can help you challenge your, you know, your own biases and assert and practices. And you know, the, the habits that you've gotten into that may not be as effective as they could be.

[00:25:54] Allan Stewart: Yeah. I feel like you know, experts as we talked about it last time, experts they're, they're really into that world of intuition and intuition is hard to explain. I want to believe that a good expert can go back to first principles and reason it out and be able to explode it again. But again, explain things that in a way that even a novice can understand. And I think that there is, there are certainly some important communication skills that can be built up this way. Certainly, I think most people have encountered the expert who is very bad at communicating and just comes off as, you know, arrogant or a jerk or way too mystical guru that cannot be understood. But if you want to have, you know, practical communication, like even just within a business, right, being able to say, hey, here are some technical reasons and some options that we want to give to leadership or product management or whatnot, they're not going to be able to speak the technical depth and you need to be able to go back. But it's hard. It's slow for one thing, right? Like, one of the reasons that you build up these abstractions in your head is so that you can skip the details. It's like, oh, I already know how to do that. I'm not going to worry about it. I'm going to focus on the bigger goal. And to break it down, break down your reasoning and explain, it's really slow. And sometimes our brains just want to make up a new story that sounds like a reason, but has a lot of logical fallacies. And that's really what your brain is doing, right? Your brain is taking this abstract concept and say, hey, this abstraction represents a lot of stuff. And the whole reason it was here was so I could skip over this step of explaining it all or deciding it or going through all the nuance and be like, well, would this work? Would this work? No, we're skipping to the part where we

[00:28:07] Dave Adsit: get something done. Well, and that's the system one, system two thing, right? That's the whole, sometimes I just jump right to this solution because I've seen so many systems. I've seen the context so many times. I just know what's going to work. I can intuit what's going to work because I've developed this muscle. I've developed this skill to the level where I can use intuition instead of following rules. But when we have to go back and explain it in a rules-based way, sometimes we just make it up. In fact, I would say, often we just make it up. If you want to go do some research into that, there's some really interesting things that have been done about patients who had to have their left and right hemisphere of their brain severed. And when they are observing things with one half of their brain and doing things with the other half of the brain, and they're asked to explain it, they make things up and it's just instantaneous. They have a story that completely justifies and rationalizes the behavior and is completely 100% disconnected from the reality of the situation. And it's fascinating how quickly and how well we can do that. And I think that to some extent, it can be helpful. It's like, hey, when the expert beginner or the advanced beginner asks the expert, why did you do this? And the expert says, oh, I did it because of X, Y, and Z. They didn't. They did it for some completely other reason based on intuition. But that story might be helpful for that advanced beginner to level themselves up to competent.

[00:29:39] Allan Stewart: Right. And I feel like, a lot of those stories come because they're coming out of experience, but oftentimes they're bad experiences. Experts will skip over things that have hurt them in the past. It's like a protective scar tissue. I don't want to feel that pain again. And so I'm going to skip over it. And so depending on how it goes, sometimes those can be very good stories. A story that can be very useful to somebody who is... at a more novice level. If you say, oh, well, that is a great idea. The only problem is that it's insecure and there's a security reason why we shouldn't do it. Let me tell you about the time. Well, that might be very instructive, but it depends on how well you can explain the story and how well the story actually fits the actual problem versus this was my knee-jerk reaction away from something that I dislike.

[00:30:41] Dave Adsit: Yeah, that is definitely true. I have a lot of scar tissue around using ORMs for a few reasons, right? When I have used an ORM with teams that were proficient and expert, it was a great experience. It was fine. When I started introducing people who were novice or advanced beginner into the mix, and we started seeing performance go just down the toilet, it became... Challenging. I developed scar tissue around that. I don't want to do that again. I know eventually we're going to hire some beginners, and I don't want the beginners to put all of the N plus one queries back into the system and make the performance go bad and make the customers angry. And so I'd rather just not use the tool because I'm blaming the tool for a thing that

[00:31:34] Allan Stewart: was actually skill-based, perhaps. Right. And then when you're asked the question of why, then the knee-jerk reaction is, well, ORMs are bad, right? Or potentially that's an answer that comes out of your mouth, right? Because it is a lot easier to explain. It's a shortcut to, well, here, let's... It depends. As everything in programming, it depends. And let's talk through all these scenarios, right? Sometimes it's just easier to say, no, I don't want to do that again.

[00:32:07] Dave Adsit: One of the things that... I think is important to recognize is that the people operating at competency, they kind of act as a bridge or a glue for the team at large. If you've got a team of a bunch of different skill levels, your people who are in the middle, they can work down the ladder with your novices and up the ladder with your experts because they're only one or two steps away from any of these people. And by being one or two steps away, like we said previously, if you've plus one, that's a really powerful combination. If you've got people who are in the middle, they are level plus one, maybe level plus two from everybody else on the team, which makes... Well, and they're also productive members of your team. Those who are operating at competence or proficiency with a skill, they really are the workhorses driving most of the value on your team. Your novices and your advanced beginners, they're really struggling to learn the concepts and they're not going to be super productive in a direction that's going to be very productive. It's useful, right? They might produce a whole bunch of things, but what you really want is to move towards these objectives. And the people who are experts, unfortunately, often get tasked with a whole bunch of things that are not the actual day-to-day work of the team. Like, come teach us, come explain this, come analyze this potential integration or whatever, you know? Like, come do all this other stuff besides deliver the work product of your team. And so you find, over time, that people who are at that competent and proficient level tend to be doing the lion's share of the work. You know, they're doing more of the work than anybody else.

[00:33:50] Allan Stewart: Yeah. And one of the things that becomes very critical for someone in that space is to have an open mind and be open to communication, right? Because if you have somebody who's at that skill level, but they're closed off, either they're unwilling to share, help bring people up, or they're unwilling to continue learning and move into proficiency and out of just competency, then there is a risk there that they just kind of become stagnant. I've definitely seen people in that space. It can be difficult to help them to progress if they're not willing or able to coordinate with the team.

[00:34:36] Dave Adsit: Yeah. So we've talked about this last time. We've talked about this many times. People have a bunch of different skills at a bunch of different levels, right? So it doesn't mean, you know, just because somebody is your senior React developer, they're your expert hotshot React developer, that doesn't mean they know how to build all aspects of the system. They're not necessarily going to do a great job designing your message broker or your message bus. You're super experienced database developer who can, you know, do all the reports and the data analysis and build the optimizations and the indexes, et cetera, et cetera. They don't necessarily know enough about JavaScript to be working in that in a competent way, right? So that's the thing. And the skills are fractal. So you might have somebody who's got a lot of experience doing C-sharp and And you put them on a project where they're doing Node and Postgres. And a lot of the concepts transfer, not everything. They may not know the syntax super well, but a lot of the concepts transfer to that environment. So we have to think that all of these skills become almost fractal, right? It's impossible to analyze someone as holistically as like, well, are you as a person proficient or not? That's not even the right question. Are you proficient at this very narrowly defined skill? I like to think that I'm competent at being a human being. Oh, I hope so. I do have a novice in my house right now. And some of the skills he's mastering are sitting up unaided. And it's great. It's great to see him mastering those novice level skills.

[00:36:31] Allan Stewart: Yeah. And I think it's, it's very easy for us to think in terms of technical skills and certain things that we need. We need this programming language and this database and this front-end framework and this mobile technology and et cetera, et cetera, et cetera. But it's also very important to consider other places where you can have different skill levels, soft skills. How do you work well Yeah. So we didn't assume we would be able to satisfying satisfying satisfying satisfying satisfying satisfying satisfying satisfying satisfying satisfying satisfying satisfying satisfying satisfying satisfying satisfying satisfying satisfying satisfying satisfying satisfying satisfying or categories or families of skills. I think that becomes very important too. I'm reminded of a story that's shared in the book, Peopleware, where there was, they were measuring like the productivity of different teams or how successful these teams were at delivering or whatever. And when they measured the individual people, they found that there was one woman who was not particularly productive in her individual work. But every team that she was on succeeded very well because there was something that they weren't measuring. There was some other dimension happening there where she was contributing significantly to a team, just not in the way that they were, that they could measure or see.

[00:38:16] Dave Adsit: Yeah. Or they, yeah, they just were choosing not to measure that aspect or there was no visible metric that you can measure, right? We talk about how measurement It can be very hard. So the obvious corollary here between proficiency and skills and our careers is the career ladder, right? We talk about junior, senior, or junior, mid, senior staff, principal, distinguished, whatever. All of these career levels, these titles. And I would like to be explicit that those are correlated, but there's not always a causal relationship between them. You can have someone who is a staff level engineer and they are expert at React and expert at GraphQL and expert at REST API design and they are novice at database design and any other combination of things. You'll find some skills tend to cluster. You tend to develop them together because you have to use them together. You know, you're not going to be super good at CSS if you don't know anything about HTML. But you don't need to know CSS and HTML to build desktop apps. So career ladder and skill level are not the same. What's typically more visible is somebody's career ladder level.

[00:39:40] Allan Stewart: Or title.

[00:39:41] Dave Adsit: So they might defer to somebody, their title will defer to somebody in the organization because they have a higher title, but that doesn't necessarily mean they have a higher skill in the thing that is relevant right now. And so just, I just wanted to make sure that we were clear about that, that those are different. And in fact, it ties to the fact that there are just so many different skills, right? You should have some certain level of skill in order to move up that career ladder, but your skill could be in a bunch of different areas or it could be very concentrated, whatever. So don't get too hung up on trying to equate your distinguished engineer at work with being the expert in all areas. That's unlikely. That's unlikely to be true. Right. Also, it's unlikely that your junior engineer is a novice in all areas. They've probably progressed to advanced beginner or even competent in a couple of areas of the software development tasks.

[00:40:39] Allan Stewart: Right. And that most likely happened before, right? Those are like preconditions in most cases to be hired in the first place. Yeah.

[00:40:47] Dave Adsit: Right.

[00:40:48] Allan Stewart: Or, you know, they went to school or maybe at least a bootcamp or something and they gained, they gained some experience before you were ready to hire them. So I think the challenge then for all of us is to take a step back and consider that. Consider that there is a complex dynamic of skills and as we're working together with other people, try to identify where are we coming from ourselves? Where are we at? What is it that we need to progress? And the people that we're working with, where are they coming from? What are their skills? And how can we work together effectively using the Dreyfus model or Shu Ha Ri or another model as a way to help us identify the places that are going to be more effective, the places where there are going to be some challenges and what we can do to overcome those.

[00:41:45] Dave Adsit: Yeah. And I would just reinforce that who we have on our team is critical to our success. And also we should consider. Who we have on our team, the skills that we have on our team, when we make decisions for the team as a whole. You and I have worked on systems in the past where we said, hey, this system would be very well solved by this certain pattern, but the people we have working on the team are not ready to work in that type of pattern yet. We're not going to implement a message broker and a bunch of distributed system concepts because the team is much more novice than that. And so we're going to designate a system that is more innovative, and we're going to design the system around the people so that the system itself is habitable by the people working in it, and we can build success as a group. And I think that that is something that is super critical to consider when we are doing software design, system design, et cetera.