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 building up games from small, tight, and fun game loops.

[00:00:31] Dave Adsit: I'm Dave Adsit, a VP of engineering, and recently I've been thinking about the Venn diagram of high fantasy, RPG fantasy, lit RPG, and progression fantasy.

[00:00:42] Allan Stewart: Our topic for this episode is skill acquisition models. In this industry, we know that learning and gaining skills is very important. It's an ever-changing industry. There's always some new technology or some new process or some new LLM that is affecting how we work, what we do. And so we're going to always be looking at acquiring new skills. Oftentimes, we're also trying to evaluate our own skills, where we stand as far as our capability. And so skill acquisition models are an attempt to help us put some language around that and understand skill acquisition a little bit better.

[00:01:24] Dave Adsit: Yeah. And one of the things I'd like to think about there is a reminder that all models are flawed and some models are useful. And you know, what follows is a discussion of some models that Allan and I have found useful. The first one is Shu Ha Ri. Shu Ha Ri is borrowed, according to the legend, it is borrowed from the martial arts. And it is a way of describing the three stages of progression in certain martial arts, right? You've got Shu. Followed by Ha. Followed by Ri. As you make progress.

[00:02:01] Allan Stewart: So the first step there is Shu. And Shu is all about following the rules. So in the, in these beginning stages, you are taught a way of working, right? So again, kind of borrowing out of the martial arts, you would follow the teachings of one master very precisely. This is how they do it. This is how they teach you to do it. This is how you're going to do it. And it's a lot about forms. And so in a, in a software context, this would be like, oh, I'm, I'm learning a new framework. You know, I started a new job. They're using this framework. I've never used it and I need to understand it. And I'm not trying to like, at this point, I just need to know the rules. I need to understand how does it work? What rules are in place for how this company is using it? It's not really about understanding the theory under underneath it. It's not about. What, how can I bend this to my will, but more of just, I am doing this in the prescribed way. So it could be, it could be a framework. It could be just the way that you work on a particular project. You, you join a project and maybe you already know all the technology, but the people have a particular way of working. Well, you might be, you might find yourself in that shoe level where you're following the rules and that's, what's expected is. Learn how to do it this way. Like your, your sensei would tell you it has to be exactly like this.

[00:03:33] Dave Adsit: Right. And so once you have mastered shoe, you begin to progress into ha, which is defined by breaking the rules. And this isn't just okay. Now I'm going to do whatever I want. Right? This is when you begin to branch out, you've learned one way to do it, and now you are going to start to test your knowledge and find out. What are the edges of where this practice works and where does it not work? And so now I might start to learn some basic theory that underlines the techniques that I've developed. And now I'm going to start to learn. From multiple masters, right? And I, my master has taught me the first way to do it. Now I'm going to go train for a while with somebody else and see how they do it. And I'm going to expand my knowledge and start to. To gain context on when various things apply. And so again, shoe is stepping away or breaking the rules.

[00:04:36] Allan Stewart: Yeah. And I like what you just said there about it's not just throw all the rules away. It very much is a, well, there are times, let me consider, right. There are specific times when we're not going to follow a rule or there is another teacher that does it a different way. And so I'm going to break my old rule. Learning. A new rule. And then that takes us to re where you transcend the rules. So at this point, you're not so much learning from other people, but from your own practice, you're creating your own approaches. You're taking the things that you have learned from these other rules. You've understood more and more of the principles and the theory behind what you were doing. And now you're adapting it to create your own, your own solution, right? Yeah. So you're taking your own school of thought of, of how you should do things, right? So maybe after working on seven different projects that all had server-side controller methods, you might've seen a bunch of different ways of doing controllers. And now you've kind of come up with your own way and say, Hey, I like to do it this way because, and here are my reasons why.

[00:05:47] Dave Adsit: Right. And now you are likely teaching your own students, right? When you have transcended the rules and you're creating your own rules based on your own. Experience. You're probably teaching those forward to other people who are starting their path. And hopefully, you know, through that process, we are advancing the industry overall. I think one of the things I like to point out is that as an industry, we're constantly growing and our knowledge is expanding and it is our responsibility as practitioners to teach those coming behind us so that they can gain from our experience, but also move forward. Right. Yeah. Yeah. Yeah. And so one of the things that I like to think about in relation to this issue, Hari specifically is in the book apprenticeship patterns. There is a pattern called when in doubt retreat to shoe, meaning you've tried some things, maybe you've gotten in over your head and now you're like, I don't know. I don't know if what I'm doing is working, whatever. Now is a time or an opportunity for me to go back and follow the rules that I've, I have learned previously on how to do something. I guess in the book, it's technically referred to the pattern is referred to as retreat to competence. And I think of it as retreat to shoe because it's, I'm going back to following the rules. I'm going back to a space where I'm comfortable. I've reached beyond and now I'm coming back because learning is not linear. It's, it can go forward and backwards and, you know, I can make progress and then I can regress and I can get stuck and I can, you know, there's a lot of things that happen on our learning journey. It's not just a straightforward linear progression.

[00:07:26] Allan Stewart: And context changes around us. We've talked about this a lot of times too. Things that made a lot of sense when it costs thousands of dollars for a terabyte of storage space. You did things differently under those constraints than you do today. And so that can affect you and you might have to go back to following the rules or you might have to go and say, Hey, I need a new master that's going to teach me the ways of the big data. But then also I think about how. Yeah. There's, there's a whole spectrum of different skills that you have. And somebody who is like a really, you know, veteran expert programmer is not at the re level of transcending all rules across all different skills. What they probably have learned are, are a few skills really well, and some other skills more generally, right. A kind of a generalist approach to things. And so, so don't, don't worry about. I'm not ready for breaking or transcending any rules in that area, but there might be some other things that are related to it that I'm already good at and I don't have to worry about.

[00:09:07] Dave Adsit: Yeah. So as we talk about skill acquisition, one of the things that I think it's important to keep in mind is that we need to be aware of and avoid falling for the Dunning-Kruger effect, which is sometimes referred to as expert beginner syndrome, which is basically that as I gain more and more skill, my knowledge of the space that I'm acquiring skill in is limited to the space that I've learned. Right. I know what I know and I don't know what I don't know. And so we need to be careful to avoid thinking that we know everything when we know a little bit. You'll find that experts will say, I don't know, and are less confident more often than people in the earlier phases of acquiring a new skill. Because once you have achieved true expertise, you realize that there's too many things to consider. Yeah. There's too many variables. You start to see the full scope of knowing more about the areas that you don't know and don't understand deeply. And so there's a hazardous space where as we start to make progress on a skill where we have enough skill that we can get some stuff done, we start to think that might be all there is. And now we've fallen for this Dunning-Kruger effect of thinking that we are the expert before. We have achieved that level of expertise. I've seen this many times in self-evaluations. If you ask people to self-evaluate on skills, typically the answer is seven or eight out of 10. And that is a sign that we just don't know the scope of what is possible.

[00:10:53] Allan Stewart: One of the things that I like about the Shu Ha re-model when it comes to this is that there's the importance of each phase in the model. You're not going to go from Shu. Straight to re. The break the rules part of it. Again, it's not about you just doing whatever you want. It's almost more like the rules break you, so to speak. And you have to go through and look and say, hey, where would this... It's almost an exploration, right? Like, when does this not apply? Because everything applies in some kind of a context. And so all of the rules only make sense for a certain context. I think we've talked before. Yeah. That there are very few things that we have found to be context free. And so I think if you're starting to feel like you understand something really well because you've been following the rules and you've done it a hundred times before you start thinking that you're at a re-level, check yourself and say, hey, have I gone to the Ha level of breaking the rules? Have I experimented? When does this not apply? When do people do it differently in other circumstances? And that often helps. It helps you explore that space, your unknown unknowns, and you start looking and you're like, oh, well, I'm expanding the universe of possibilities of things that I understand.

[00:12:18] Dave Adsit: Well, and as you were talking about that, I was thinking about the old karate movies, the old kung fu movies where it's like, you have taught me to block your attack by moving my hands like this every time, every time. And so I always move my hands like that to block your attack. What happens if I move my hands this other way to block your attack? And you're like, well, then you get smacked in the face. So you can have very quick feedback loops and very quick learning once you have gotten to kind of that re-level where maybe you write code that smacks you in the face. And then you can go back to writing it in a way that you know works as you explore what will and won't work in your journey to expand your skills.

[00:12:58] Allan Stewart: Yeah, there's a quote often attributed to Albert Einstein. The more I learn, the more I learn. The more I realize I don't know or how much I don't know. I think that that's what we're really getting at is like, if you think you know it all, then you probably don't. And you're falling for this trap. You need to expand your horizons and realize that there's a lot more. And nobody knows it all. The people who do or who claim to or appear to usually are problematic people, I have found.

[00:13:32] Dave Adsit: Yeah. Yeah. That or misunderstood somewhere. That does align with my experience as well. Yes. Well, so Shuhari is one of the skill acquisition models that we like to use that we've talked about extensively and used in our in our various jobs over the last years. It's not the only one. There's another very popular or well-known skill acquisition model. It's the Dreyfus model of skill acquisition. So this was originally proposed by two brothers. Working at the University of California, Berkeley in 1980. They wrote up an 18 page paper on skill acquisition in, I think, specifically engineering. I think they were working in the engineering school and their skill acquisition model. The Dreyfus model has six stages. And so we can go through those six stages one at a time. The first is stage one, which is the novice. So novices very much like Shuhari. They rely heavily on context free rules and step by step instructions. Basically, you do what you're told as you are learning at the novice level. So novices tend to be slow and clumsy and they require a lot of conscious effort in performing the tasks or the skills. And novices really struggle to adapt to unknown or unfamiliar situations. Right. Basically, when you're at this novice level, if something unexpected happens, you might get stuck and you have to go back and ask your teacher, your instructor, what do I do? The rules didn't cover this. This is outside the boundaries. I didn't know that we were expected. You know, this wasn't in the reading. Why is it on the test type of a scenario? Right. So also novices tend to have detached their approach from their outcomes. They're not really aware of it. They're not really aware of the outcomes they're pursuing. Right. They're thinking about what I have to do moment to moment. They're so focused on the actions that they're not even necessarily as aware of the outcomes as you would be in later stages of development. So you you're operating at novice. You're in this novice stage where everything you do is feels clumsy and awkward and you're you're just following the instructions. You're reading along with the the tutorial and doing exactly what it says. And you get to a spot where something goes wrong and you don't even know what to do. How do we make progress from there? Basically, novices need to work on gaining a lot of experience and they make making mistakes in a variety of situations and learning from each of them. Right. So novices are exploring. It's if you think about it, you're exploring a very small space where you're mostly following the rules and you're doing a little bit of stepping outside the rules to learn and then coming back. And so your your progress as a novice is kind of slow and clumsy.

[00:16:31] Allan Stewart: I also think when I think about novices, you got to kind of go back in time in your programming journey to remember how things were when you were first learning or maybe get together with some people who are first learning for the first time. Because that that novice stage, there's a lot of times you skip it as you acquire adjacent skills. Things that are a little bit like something you've done before. So the very first time that you learned the very first programming language that you ever wrote any code and you are a novice, there's a very different experience from I already know seven programming languages and I'm picking up an eighth. Because you've already learned some of the meta things. You might be a novice to the language, but you're not like you already understand a lot of things around like syntax or or how compilers work or something else or how interpreters work. Yeah. And so I think you do have to really you really go back to that that feeling where everything was broken and it was bad and I don't know why. I was just trying to follow the tutorial that was online and I didn't know anything about this tool or this framework and I was just like completely lost. That's that's the feeling of the of the novice that you have to keep in mind. And unfortunately, yeah, you just you have to keep gaining experience and you have to. A lot of that comes from mistakes. Yeah. You can get a teacher to help you. But if you're not careful, they skip right over teaching and go straight to showing and and you won't progress. The next stage is the advanced beginner. So an advanced beginner starts to recognize situation specific nuances. They can apply specific rules or experience based maxims that are beyond the general rules. Right. It's like, OK, now we're starting to get a little bit more specific. You're a little bit more sophisticated in your performance, but still very analytical, still continuing to struggle with unfamiliar situations. And this is a phase where an advanced beginner, you can feel more emotionally engaged. That can go in multiple directions. You could be overwhelmed or frustrated. You could feel more excited. Because, hey, I'm making progress. Things, things are coming together. I'm actually seeing at work. I'm beyond. I got the tutorial working and I can actually make a thing. So it puts you in a in a different frame of mind from the novice. So how do you progress from that? You've got to continue building further emotional involvement and commitment to the outcomes of what you're building. Right. At the advanced beginner stage, you're still. Building towards learning. Really, you're still at the phase where that the outcomes are. Hey, it compiled. Hey, it worked. Hey, I made the button blue. And now I can do this cool CSS trick. But you're not you're thinking about that at that at that level of outcome of I I type some code and something happened rather than I made some code that achieves a purpose like a business outcome. Right.

[00:19:58] Dave Adsit: One of the things I think about is that every every action you take at these beginning stages that either a novice or an advanced beginner, you're thinking about the action a lot. Like if you if you're thinking about dancing or basketball or something, you're like, my feet have to go here, here and here in order for me to perform this step or make this layup or, you know, something like that. Like I'm operating at a level where I am very careful in how I'm doing this. I'm not going to be doing the specific things because I don't have enough experience to be feeling it out as I go. I have to be analytic about the entire the entire operation. Right. And that leads us to our next step, which is competence. Competence. You know, you've gone through novice and advanced beginner and now you've become competent at this task or this skill and competent performers. You choose specific goals. And you adopt to. You know. You. The scenario or the context that you're working in, you you adopt a perspective based on that context and you start to think about success and failure based on your outcomes. Your success and failure outcomes are based on your initial perspective of how you approach the problem and not just on whether or not you can follow those rules that were laid out previously. So as you become more competent. You get a higher emotional involvement in what you're doing. And you start to feel maybe joy and regret. I start to think about this is. Once you achieve competence with a technical skill, you can start to enter that flow state that we talk about. Right. Where you're enjoying the work. Things feel like they're happening. Well, you don't have to stop and think. Quite so often or so deeply about like what. Where do I put the comma? Is this supposed to be a comma or a semi comma? Where? What? What a parentheses doing in this part of the code. Right. You start to enjoy that flow that your actions, your outcomes become more fluid. And you'll still find yourself as a competent performer. Someone who is competent at a skill. You'll still find yourself having to spend time in analysis and calculation and deliberate planning before you do something. Right. skill as a whole, right? So if you say, Hey, I've built these seven websites and I've always used a controller and somebody is like, Hey, we're going to do this new thing where we don't even use a controller. We're just going to connect to blah, blah, blah. Instead, you're like, I don't even know what you're talking about. I'm going to go back to what I know, right? Like there's a, there's a concept in domain driven designer or programming of maybe we're going to do naked objects, meaning we don't even need a controller over them. The interface of the object is the interface of the web application. And if we're doing that, then I don't know how to do that. And so I'm just going to go back and put controllers in front of things because now I'm, that's an, that is a perspective I've taken that leads to success, right? So if I want to advance in proficiency, uh, I have to make a conscious choice to go beyond competence. You can, you can kind of muddle your way through novice advanced beginner and get into a competent state by following a group or working with others and kind of muddling along. But if you want to move beyond that, you're going to have to take an intentional choice to improve your skills. And you also need to be willing to take more risks, let go of some of the rules and procedures, and you have to start developing an intuition about when to apply which set of rules. There's a, there's a story that I've heard in, in the business space, like the, there's a way of where they use the, they teach business cases, right? You tell, basically it's a series of stories, like describe the context, talk about what the, what decision the leaders made and what the outcome was. And there's just lots and lots and lots of these business cases. And so there's the, in the story, the, the young NBA who's just graduated starts his business and it fails. And somebody says, well, what did you learn from the failure of your business? And he's like, oh, I learned that I applied the, wrong business case, right? He applied the wrong learning. And so he didn't really learn anything. He just, you know, attributes his, his failure to having taken the wrong initial perspective on what he was going to accomplish. But it's important to have a variety of, of options when we want to move beyond competence. And that takes us to stage four,

[00:25:19] Allan Stewart: which is proficiency. At this stage, you begin to have an intuitive grasp of what a situation calls for, but you still have to consciously make choices of how to deal with that, right? So you might have, you might be at the point where you can look at a situation and say, oh, well, we definitely need a database. Well, which database should we use? Like what, what fits this problem? What fits this context? I don't know. We're going to have, we're going to have to do some research, but we, or, or we know that we need to add a cue here. Okay. Well, but we, we don't know enough about cues to be able to just pick one on the spot. We, we're going to go and do some research. We're going to go do some additional learning, but you at least you're recognizing these contexts. You're recognizing these patterns and saying, Hey, I don't have to research the problem as much because I have a better intuitive grasp of what we need to do, but how to do that thing is going to take some work. It gives you a better ability to adapt to changing circumstances, but the, but those rules are still there, right? Like still understanding how and why things are used as you're applying them to, to the solutions, to the actions that you're taking. And so the, the transition transition up to the next stage is going to mean that you have to further let go of rules and procedures, right? You have to have enough experience to be able to say, Hey, I know why this works. I know the characteristics of certain problems of certain patterns. I'm not just identifying, Hey, this is a type of solution that we need, but also I have an idea of which solution to apply. And, and how that is going to kind of a vision for how, how you're going to

[00:27:18] Dave Adsit: solve the problem, not just being able to identify it. One of the things that I think of as we talk one of the things that I think about proficiency is the importance of experience. I remember when I was a very young programmer, I had read so many books and I had, you know, done a couple of college classes and I was like, look, I've put in the work. I know I have the knowledge. I can do this. I can do whatever. And what I didn't have was experience. And because I didn't have experience, I discounted the value of experience. And a lot of what I've learned since is that you, you can't skip the hard part of practicing. And trying and doing, you have to gain the actual experience if you want to continue progressing. And so that's one of the things that you're going to have to do to move beyond proficiency is grind. You're going to have to go grind out those hours and those projects and get that stuff done so that you can transition into the level of expertise, which is, you know, stage five. Right. So when we get to expertise, we see the experts demonstrate this seamless integration of perception and action. It's no longer perceiving and analyzing followed by deciding and acting. It's all kind of integrated together. I perceive it and I take action almost as though it were one operation. And so the performance of an expert, it happens without that deliberate decision-making. I'm going to put my foot in here and I'm going to put my foot there. And then I'm going to put my foot in there and I'm going to lift my arms and I'm going to throw the ball. No, it's just like all one seamless thing. And like an opportunity arises, I'm going to do a layup. And so one of the challenges that experts start to experience is that they have a hard time explaining since perception and action are integrated. They have a hard time decoupling them to explain to someone earlier on the path. Why did I do this? What were the things that I saw that caused me to do this? Why did I make this decision versus that decision? Why did I choose to put this behind a queue instead of in a cache? Why did I optimize the database this way versus that way? Why do these fields belong in this table instead of separated across three tables? These are the types of things that experts can sometimes struggle to explain to people earlier on the path because they're like, one of our friends has often said, sometimes the answer in software is, go write software for 20 years and then come back and talk to me about it. And that is a very unsatisfying answer when you're young and new in the career and you want to know everything and do everything, right? And sometimes you just have to go try a bunch of stuff in order to gain the intuition about what's going to work where. And when you have enough intuition, you lose some of your ability to explain the reasoning behind it. Because sometimes the reasoning behind it is, right? We talk about in chess, the grandmasters spend more time remembering previous games than they do thinking about the state of this game because they've seen the board in this exact layout so many times, they know what worked and what didn't because they've played through it. And the same can be true in more complicated spaces as well. There's a book, Thinking Fast and Slow that talks a lot about system one and system two, your analytical system versus your system. And they're not really separate parts of the brain. They're not like an intuitive part of the brain and an analytic part of the brain, but you can develop by making a bunch of intentional choices, analytic choices. You can develop an intuition that allows you to operate more quickly in spaces that are familiar. And that is what expertise is. You're operating more in intuition and moving more quickly, more precisely. You're moving with more grace than you were ever before in your career or in your experience with this skill. And so you've achieved expertise. Now what? What do you do to move forward from expertise? Well, you have to continually shift your perspectives and continue gaining experience and start doing some metacognition around the situation. Skill and in challenging yourself to try things that you just would not have otherwise done because you have an answer and the answer works. Right. So yeah, the, the level of expertise, everything seems very smooth and natural and graceful as you execute on this skill.

[00:32:07] Allan Stewart: As you get up into these levels, even with proficiency somewhat, but then into expertise and then into the final stage of mastery, I think you can do yourself a favor by periodically stepping back and learning how to explain how you arrived at a particular solution. And that can be difficult because it is more, it's slower. It's a lot easier, especially at the level of expertise to say, well, I just know I've seen this before. I could explain it to you, but it's going to take a while. And so let's just go. Right. It's just fast. And I just want to go. But if you can, I think this is one of the things that brings you fully into that mastery level where you can, you can explain the rationale behind what you're doing. And I think software architects in particular have a need for this because of there's, there's a lot of different concepts of what an architect does in a business, but a lot of the time it is making decisions. And communicating a decision and communicating options. We could do this and this will be a result. We could do that. And this will be a, and that, and that would be the result. And so being able to explain yourself and, and kind of go back to reasoning from first principles of why you do a particular thing helps you in that journey to mastery, because a master, they're going to be expanding and refining different perspectives. Right. They're not going to just behave a particular way. Cause this is the way I've always done it, but much more context sensitive. They can create new possibilities. They create new styles or new, new ways of working that hadn't been done previously. And then a mass at the level of mastery, you start to identify overlooked aspects of a practice. You try new approaches. You are accepting shortcomings. these parts of a process, these parts of a process, these parts of a process, these parts of a these parts of a process, these parts of a process, these parts of a process, these parts of a process, these parts of a process, these parts of a process, these parts of a process, these parts of a process, challenged that assumption and changed my mind about how this works, or I've confirmed to myself, yeah, there are only a couple of ways that this can work because here are all the pitfalls that I have identified that happen if you stray from the path.

[00:35:01] Dave Adsit: Yeah. And sometimes it's like, oh, look, and I also discovered a new path that we previously hadn't known about or tried because I tried a bunch of things. And I think that is something that mastery is really about expanding the practice as a whole and moving it beyond what it once was. I think in human performance, one of the things I think about is the progression that we've made in running, races, speed of running. It used to be no one could imagine a marathon runner, whatever, what break, what, two hours? And now you're not even at the professional level if you're not doing that.

[00:35:42] Allan Stewart: The original marathon, I believe, killed the runner.

[00:35:45] Dave Adsit: And I think it took him a lot longer than two hours. And there's also like the, what was it? The four minute mile was considered an unachievable level of human performance. And now it's considered standard for the type of sprinters who do miles. Those types of things, like you are expanding the practice beyond what it ever was by, you know, doing things that no one had previously. Considered. And so not every skill needs to be developed to the level of mastery or even expertise. Like expertise is a very high level of skill where you're doing everything with intuition and doing everything you, you know, like if you're, if you're operating in expertise, like even as contexts change, you're fluidly moving between those contexts. I'm reminded of the, uh, the sword fight scene from the movie, the princess bride. They're fluidly transitioning between all these different styles and terrains and whatever. Like, why do you need to do that? That's not like your day job is to chop wood. You don't need to be fluidly moving between different styles of sword fighting. Right. And so you don't need to develop expertise or mastery in most of these areas. In fact, most of us are unlikely to, to develop the kind of mastery where we're expanding the industry or the, the body of knowledge for a thing in our careers, or we may do it in one or two areas. And so if, if I'm not going to be an, um, if I'm not going to master every technical skill, what does it look like for me? We used to talk about being T-shaped, meaning we want to have a broad set of skills and we want to be very deep on at least one or one. I mean, it used to be like, go deep on something and be broad on various, various things. And now we talk a little bit more about being paint drip. And if you imagine a paint can that you've used for multiple projects, you've, maybe you've got that can in your garage that you use for all your touch-up projects. And it's got various drips on the rim of it. There's probably paint all the way around the rim, right? We still want people to be broad, but the drips only go as far as they need to go. Like some of them go very far and some of them don't go very far at all. And I think that that comes back to, you know, the, the, the, the, the context of your career. Do you need to be an expert at mobile development? Well, apparently not because you haven't done it in years. And so maybe if your job suddenly requires you to start developing mobile development skills, you will start going deeper on that skill. You know, you might approach competence or proficiency again, maybe once you were proficient and now your skill has atrophied. And so now you're feeling more like an expert beginner or an advanced beginner, right? Rather. And now you want to take it deeper again. So you can at least get competent and be able to contribute on that part of the code for your company. Well, I think it's not even a case of,

[00:38:53] Allan Stewart: do you need to have the broad experience that, that touches everything, but more that you can't, you can't have experience that touches everything. And so you need to just be, be careful that you're having some breadth and some depth, right? Deep enough in the areas that you can be competent, you can work well at the, with the thing that you need to do, but broad enough that you understand how these things relate to one another, how, and I think about it even, especially in software going beyond just straight programming or technical skills, right? There are a lot of the so-called soft skills that make a huge difference in your ability to work with other developers, to understand business needs, to understand what will make a product, more successful. And so you need to be able to expand your reach to those, those different areas.

[00:39:48] Dave Adsit: Well, and speaking of expansion, one of the things I like to think about when it comes to skill acquisition is that we go through kind of phases or waves of skill acquisition or knowledge acquisition, where we will expand and then we'll start to compact and bring that knowledge in more thoroughly through practice and repetition. So we may have a time when we are focusing on broadening our skills by learning a bunch of adjacencies to the things that we're doing now. And then now we've, we know more things. We want to compact that knowledge, basically turn it from system one, where we're thinking analytically and doing everything rigid, you know, through a defined process into a more of an intuition. And all of these are about that kind of moving from rigid, rigid, rigid, rigid, rigid, rigid, practice to more intuitive practice, right? And so we have to spend time practicing a thing so that it becomes burned into our brains. It becomes more of an intuitive pathway so that we can exercise it more quickly. An analogy in software is an event log. An event log, we just append, append, append, append, append. You never, you never delete, you never update. You just append to that event log. And eventually we get to a point where reading the whole event log is slow and we want to go through a... Yeah. Compaction process where we drop the unnecessary events. You know, maybe there's four updates on a field in a row. And so we're going to drop all of them and just keep the last update to what the current value is. Or maybe we're going to start making, in an event log space, we may start making snapshots that are quicker to read. And I think of that as something similar to the way our minds work when it comes to compacting and building intuition around skills. Yeah. And it allows us to operate at a higher level of abstraction. Yeah. And it allows us to operate at a higher level of abstraction as well. You know, one of the things that happens is we've talked about this before. If you and I are working with a novice developer, we, and we want to talk about how we're going to build a web application, we might spend a lot of time diagramming and explaining and showing examples, et cetera. But then if it's just the two of us, we might say, hey, let's build this web application. We'll do, we'll follow the following seven patterns. We'll do a domain-driven design. We'll do a design pattern with a repository pattern. And we'll, on the front end, we'll do, let's do front ends for back ends for this one so that we, versus RESTful. And we know what that means because we can operate at a higher level of abstraction because we've taken the time to learn about those abstractions. And so the communication can be very quick. Right. And that allows us to, you know, operate more fluidly and more intuitively and then just discuss the pros and cons of the application.

[00:42:44] Allan Stewart: One of the examples I like to use when I think about this kind of abstraction is tying your shoes. When you're first learning to tie your shoes, there's a lot that goes into that. And, you know, there's, there's rabbits going around whole around trees and into holes. And how do you move your fingers? And if you want to think about it this way, like there is a lot of, a lot more detail. Like it is. super complex, right? Like you, at some point you can get to the point where you can just tie your shoes and you don't, you don't think too much about it, but now you've got to code a robot that has to do that. Or now you want to, you know, simulate the physics of, of the string as you're pulling it in different ways. And it can get extraordinarily complex. So let's think about all the atoms, the individual atoms that are involved, but abstraction also can make it quick and faster to be able to achieve a bigger goal. And so then all of a sudden we can say, go to the store and buy milk. And that a task, that task can get accomplished easily, even though tying shoes was one of the things that you had to do along the way, you didn't have to think about all of those little details.

[00:43:56] Dave Adsit: That's right. And again, that comes from practice and experience. Yeah. So one of the things I think about is it's so complex. There's so much, that is required in order for us to build a career that we can't outsource that to anyone else. We have to make a, we have to take responsibility for our own skill development and career development. And so one of the things I like to think about is like, what do I do? Okay. I'm here. I'm novice. I'm maybe competent at a couple of skills. What do I do so that I can develop those more deeply? And so I've got a set of recommendations that I give people that I think you and I have done most, if not all of these, either individually or together. And so let me just run through that list real quickly. One of the things that I think is really important for acquiring skills is reading books and blogs. Another thing is attending conferences or workshops, either internal to your company, outside in the community, watching videos and podcasts, participating in meetups, completing training courses. Sometimes those are offered by, and sometimes you have to go pay for them yourself or sometimes find free ones online. We've talked about some of those that are available. Working on projects, either personal projects, open source projects, doing that kind of contribution allows you to develop some of your skills, practice some of your skills. And one of them that we've both done, I know is speaking or presenting either at meetups or at conferences. Basically these are, that's like, that's my quick list and that's a lot of stuff. And they can, feel overwhelming to say, you just rattled off seven bullet points and I don't feel like I can do any of those except maybe pick up a book and read it. Good news. You are at the novice stage of learning to be a software developer, go buy a book and read a blog, right? There's a lot of things that on the, on that list that help us become more comfortable to progress up that list and do more and more and more of those things. But if we're doing all of those things, we can really take responsibility for our own learning and development. And so, you know, we're going to

[00:46:08] Allan Stewart: and skill acquisition. And I assert that taking responsibility for your own learning is critical, right? Nobody else can learn for you. Your job might give you some money or time to be able to do on the job learning, but ultimately it's going to be up to you to own it. And so we were talking about the like breadth and depth before. And what I like about the list you shared there is that learning in different ways can often be helpful. Like the last one that you said, speaking or presenting, it kind of triggered for me as like, you know what? Sometimes I learn things a lot better when I go to explain it to somebody. I'm going to present or I'm going to write it down and be like, okay, let me explain why I think this way. And then it turns into this long digression. And it's like, I haven't really thought through some of these things until I was forced to expose it in some way. And so having a breadth of ways that you go to learn can be very powerful. And I think it helps us to consider, right? As we get more experience and as we get that breadth, then we're no longer thinking about simplistic terms of junior and senior developers, but more in this, you know, multi-dimensional space of there's something, that they're really good at and other places that they're not as good at. And what areas are we looking at for ourselves, for our colleagues? Where can we improve? What do we need to fill gaps on our teams and so forth? So the recommendation that I would give to everybody then is to think about these different skill models that we talked about. Shuhari is a nice, easy one to start with. There's just the three levels. The Dreyfus model, the way I look at it kind of So there's just so many levels of Shuhari and there's like the front and back of each one as you're learning. But take one of these models, think about it and evaluate yourself and say, where am I at? Or better yet, find somebody who you compare with or talk to, because it can be often difficult to evaluate yourself objectively. And so get some help, get somebody who is willing to do some evaluation together so that you can understand where you are and where you're from. you're at. Where do you think that you're at from your self-evaluation? Where do other people think that you're at? And see where that takes you and how that helps you take your next step towards mastery in a skill that you are interested in.