Skill acquisition is a difficult process to say the least. We aren't really 100% certain how people acquire skill. It still is theoretical. A lot of the reason for this is because most of what we can do is observe. We can observe how people acquire skill and we can hopefully learn from those who acquire skills efficiently and compare them. And ultimately though, most of the ways that we describe skill acquisition are still in terms of theory rather than science or I guess proof. But the theories that do exist are pretty interesting and we're going to talk about one of those in today's episode. My name is Jonathan Cutrell and you're listening to Developer Tea and my goal on this show is to help driven developers like you connect to your career purpose and to do better work. So you can have a positive influence on the people around you and one of the most important things you will do in your career is continue to acquire skills. Acquiring a skill is really kind of the directed process of learning. We talk about learning very recently on the show and over the course of the show's entire kind of lifespan but more recently we've been discussing kind of how learning occurs in usable ways. And in today's episode I want to discuss this more in that directed skill acquisition perspective. So just to delineate between these two a little bit more clearly, skill acquisition is learning for the sake of applying knowledge in some performable way. A skill is something that you can use your mind and not only to recall that information but to apply that information and typically the way that we talk about skills is as a useful thing with relation to your career that is certainly true. Although it's also important to understand that not all skills will necessarily be directly useful and this model can still apply to skill acquisition in those arenas as well. So the model is called the drafus model or maybe the drafus model. Not really sure how to pronounce his name. And this is new to me and I'm really excited to share this with you because this model can really help you understand different phases that you go through when you're learning. And we're going to kind of talk about this model rather than talking about it purely in stages. First, I want to kind of give you an idea of how this progression works out for most developers. So when you first start out as a developer, you have this sense that there are rules. There seem to be some really obvious things that you need to be paying attention to. And so you go and you learn the very basic beginner rules. You start out with the documentation and you don't really stray anywhere beyond that. Most of the time you're copying and pasting code or you're reading things directly from a previous example or maybe you're doing things exactly how another person's style guide has said to do them. And so everything seems to work. You're not producing anything particularly groundbreaking but you're also not experiencing a lot of friction. You're not really running into a lot of problems. And so you move forward and perhaps this first phase that you're in, you're kind of building the single example but then you move on to the second example. And you're taking the rules that you had in the first example and you're trying to see how do these same rules apply in this new scenario. And so as it turns out, even in the second example, you're still kind of learning and applying the rules and so you're not really facing a lot of friction. And as you continue forward, you continue to find the rules useful. So you start encountering contexts where those rules don't really apply in the same way. And perhaps they start colliding with the context in a way that you're finally experiencing a little bit of friction. And so you're having to pick and choose which rules do apply. And as you figure out which rules apply, this is the first time where you start actually experiencing some failure and perhaps even failure that leaves you completely confounded. But eventually as you continue to gain experience, as you continue to see many different contexts where all of these various types of rules and ways of doing things, they apply in those particular contexts, you become more familiar and perhaps comfortable. Now rewinding back to the beginning, when you were applying the rules that you found, you didn't really know why you were applying them. And you weren't even really sure exactly what the point was in some of the actions you were taking. You were just kind of following the rules. But now at this stage, you kind of have an intuition. You know what your goal is. And now you're not really sure every single time right off the bat, which rules are going to apply, but you do have an intuition and you know where you're headed. And eventually after doing this over and over after gaining the intuition for your goals and then applying rules and achieving those goals, at some point the intuition for what rules apply in a given scenario kind of becomes automatic. Now of course, I'm not endorsing this theory as 100% true and there's some reasonable criticism of this theory. Like for example, the fact that people who are at that high level of mastery, the very end of that phase that we just discussed, they still very often are very methodical about their decision making. And so intuition is not the only hallmark of being a master at a given subject. But the specifics of the dry fits model as they come together are particularly interesting. As you go from this very early beginner stage, where you have no context, nothing is integrated. You really don't know anything about what you're doing. You're just kind of the middle man between the rules and the actions. You're sort of faking it. And in some ways, the faking at part is giving you the muscle memory that you need to get to the next stage. The second stage is that advanced beginner stage where you're taking these rules that you're learning in one context and you're applying those same exact rules in the new context. So even though you may not understand why you're applying these rules, you do understand that the context has changed and you're starting to learn about how that context changes over time. The third stage is perhaps the most interesting stage because it's the first stage where you begin to make some mistakes. And the integration begins to happen. You start having enough rules available to you at your disposal that they don't all apply all at the same time. So now it's not only that you recognize context, but you're also starting to pick the rules that you want to use in a given context. And this stage is where you become competent. You have context and you're using that context to actually make decisions. However, you haven't developed much of an intuition yet. Everything is a very intentional and methodical process. And this stage is really about being able to observe what is happening. You can see what's happening. You can see the inputs and the outputs. You understand the picture and how you are affecting it. Eventually you will get to the place where you have proficiency. This goes beyond competency and you start to gain intuition when you are proficient. Proficiency means that you have a clear picture of the goal. You may not have all of the actions lined out in your head immediately when you see the goal, but proficiency gives you a stronger intuition for how to achieve what you're trying to achieve. And then finally, the kind of fully automatic intuition for what rules apply and what context. And what combination of rules. This is full blown mastery of a skill. So how does this work out? How does this actually apply to your career? How can you use the skill acquisition model to drive the way that you're thinking and learning as you progress through your career? Well, the first thing that you can do is recognize where you are in this line, right? What phase are you at with various skills? For example, software development has a whole litany, a whole list of skills involved. And you can pick any one of them and really understand kind of where you sit in these five stages. An example might be refactoring. Are you a proficient refactoring developer? And how would you know this? Well, do you have a very clear picture of the rules? Do you understand how to apply them? And do you understand what context to apply those rules in? And what you can do is take this information and use it to drive your learning goals. So if you don't have a clear picture of the rules, then perhaps that's a good first step. You need to understand the rules, understand the playing field. And then you need to apply those rules in multiple contexts, right? And then just walk through this, this dryfish model and figure out places where perhaps your understanding is missing or maybe if you're in the later stages of your skill acquisition, where your intuition is lacking. Ultimately, as we've already mentioned multiple times on today's episode, these kinds of models are theories. At the end of the day, they don't describe skill acquisition perfectly. For example, you may have a very strong level of skill writing HTML, let's say. And you may not have a perfect full dictionary of all of the rules for HTML, but you may be quite proficient with it. How can we have these two things in tandem with each other? Well, this is partially because some of the rules of HTML don't necessarily actually apply to you. Not that they don't apply in general, but rather that you're not encountering situations where those rules apply. And so having that knowledge doesn't really have an overall detrimental effect on that skill. And so the whole point of that is not to say that you don't have to learn all the rules, but rather to say that everything is contextual when we talk about these learning models and ways of thinking about things like skill acquisition. So I encourage you to use models like the dryfish model to understand where you're at and to try to get a clearer picture of your profile, the way that you learn and things that you may be able to work on. But don't take this model and treat it as if it's the definitive truth or go and decide that instead of building something with JavaScript that you need to go and learn this spec, right? That's not the message that I want you to take away from this show, but instead understand that we progress and eventually we move from this kind of disintegrated picture of a skill to a fully integrated and intuitive practice with that skill. Thank you so much for listening to today's episode of Developer Tea. We didn't have a sponsor in today's episode and in lieu of spending time listening to a message from a sponsor. I encourage you to take a moment and subscribe in whatever podcasting app you use. Thank you so much for listening and until next time, enjoy your tea.