If there's one thing that makes developers self-conscious, it's probably their Googling history. More specifically, the things that they Google that they've forgotten how to do. Even great developers and perhaps, especially great developers, still look things up. They still reference documentation. They still have to Google that one Stack Overflow article and copy and paste that line of code that they forgot how to write from memory. And how is this possible? How can we become truly great at something and yet still need the support from a quick Google search? That's what we're going to talk about in today's episode. My name is Jonathan Cutrell and you're listening to Developer Tea. My goal in this show is to help driven developers like you connect to your career purpose and do better work so you can have a positive influence on the people around you. It's October 1st and that means that we are nearing the end of the year. And you're probably starting to think about some of the things that you've done this year. Hopefully, you're kind of reflecting back a little bit and also preparing for the busy end of the year season. And many of us have just come through the conference season. A lot of conferences happen towards the end of summer and we get a chance to see the people that we really kind of idolize in various technology groups. We don't idolize them but at least they have accomplished something in their respective groups. And in today's episode, I really want to kind of deconstruct this myth that these great developers, the people who are presenting at conferences, the people that you are used to looking up to, the ones writing the books, the ones writing all of your favorite blog posts, these great developers, they don't have everything memorized. They don't have the entire documentation for whatever language in their heads. Now what we're not going to do on this episode is say that these developers are not accomplished. This isn't a message to try to make you feel a little bit better about your need to look things up. Although certainly you shouldn't be feeling apprehension about needing to look things up. That's not the point of this episode. The point of the episode is also not to say that these people are not as smart as you think they are. That's also not necessarily true. And in many ways, these great developers are probably even smarter than we might think. And this is true for you as well. Because we have a disconnect between what we believe is knowledge or mastery of development versus what actually is mastery. What is necessary for mastery in this field? That's what we're going to talk about in today's episode. We're going to talk about this difference, this break between knowledge, having some stored knowledge and the ability to retrieve that knowledge, the difference between that and application, understanding the ability to deliberate. That's what we're talking about in today's episode. What makes you a great developer from the perspective of mastery and knowledge? Before we get into that discussion further, I want to take a moment to talk to you about today's sponsor. The future of tech is going to be on.tech domains. I want to talk to you about three key benefits of.tech domains for startups. Number one, availability. Domain names have been around for a long time and a lot of domain names are taken. The ones that you want are very often taken. And so you end up settling for domain names that you don't necessarily want. The good thing about the.tech domains is that many of them are still available. You can get a high quality domain. You don't have to compromise or settle for a hyphenated domain or extra letters and numbers. And then the actual relevance of the.tech extension to the tech industry. This is a good keyword to have. It's intuitive. It's descriptive. It creates a great first impression and it helps you stand out in the crowd. Some good examples of.tech domains. By the way, startups that have migrated to.tech domains have raised $500 million over $500 million in funding at this point. So for example, Viacom, you don't have to, let's say you already have a good domain name. You can still use.tech domain names. Viacom has an open source portal for their brand at Viacom.tech. This strategy clearly distinguishes the Viacom.tech open source portal from the main Viacom branded site. So you can also find Intel using.tech domain at insight.tech. This is their portal for their internet of things and their embedded innovation. So if you have a need for a new domain name or if you're looking for a particularly interesting name, kind of your base domain name, I encourage you to check out.tech. And here's the most compelling part of this because you are a developer to listener. If you'll use the code spec.tech at checkout, head over to go.tech. That's a geo.cch slash spec FM. Go.tech slash spec FM. You're going to get 90% off on your registration. So you can get this on one year in five year for one year. It's going to cost you just 499 and five years will cost 2499. Go and check it out go.tech slash spec FM. The future of tech is going to be on.tech domain. So we're talking about the illusion of learning and knowledge as it relates to recall. Now, we've talked about this very recently on the show, the idea that learning is kind of based on this concept that you're putting information into your brain for recall at a later point. And so it seems intuitive that if you have to look up something, let's say you forgot the syntax or you forgot a particular procedure, that you still have a lot left to learn. And the illusion continues that those who are really good at programming those great Developer That you follow on Twitter or that you watch their YouTube videos, a conferences and that kind of thing, that they already have all that step down that they don't forget those things that they don't Google for that syntax. This isn't necessarily true. In fact, it's almost certainly not true. And the reason for this is because knowledge is not simply having a dictionary of information in your mind. And we've mentioned this before, but Blooms taxonomy. This is a kind of a way of understanding how far your knowledge goes. So in Blooms taxonomy, which we're not going to get too detailed with this, but Blooms taxonomy identifies six different layers where you understand things more and more as you go through these layers. The first one is knowledge. And this is that retrievable information in your head. You have some kind of trivial information that you can pull out of your head. And if somebody were to ask you that question, then you can retrieve it. And that's where it ends. The second is comprehension. This is being able to classify and describe things, but not necessarily use that information, which is the third level. That's application, taking that information and using it in some particularly useful way. The fourth kind of layer is called analysis. This goes beyond taking that information and using it. And instead, you can take a step back and see how it is being used. This is kind of a meta layer. The next step is synthesis. Imagine having multiple pieces of information, multiple use cases, and being able to understand how they fit together. Finally, the sixth layer in the Blooms taxonomy is called evaluation. Being able to rate and understand and appraise and compare and defend. This is kind of the ability to debate and to weigh pros and cons and to evaluate the quality of a particular use of information. And so as we look at this taxonomy, what we can realize pretty quickly is that syntax doesn't really provide that level of depth. Actually what we're talking about when we examine the career of a great developer is how is it that they arrive at that sixth level of Blooms taxonomy, that ability to compare and to have informed opinions about various types of technology, simultaneously not always having that retrievable knowledge about syntax. And the reality is that the things that a great developer cares about very often have much less to do with a particular wrote procedure or the specific syntax. They have much more to do with some level of principle, some kind of pattern, some higher level understanding of how those parts fit together, not necessarily the internals of those parts. And this understanding essentially creates an abstraction away from the particulars. And this doesn't mean that great developers don't care about the particulars. For example, this may lead to an argument that great developers don't care about performance. This isn't necessarily true. Instead, they rely on patterns and they rely on principles and focus on the kind of the largest impact that they can spend their energy on. So if they were to spend all of their energy on, let's say, memorizing the details of the syntax of a given programming language, what happens to that knowledge and how useful is that knowledge when the syntax changes or perhaps when they work on a project that uses a different language? Unfortunately, a lot of that information just simply doesn't transfer. And for that reason, that higher level of Bloom's taxonomy, that kind of shallow layer of Bloom's taxonomy, tends to be transitive. That knowledge that you would normally have kind of just available for retrieval is not particularly useful when things change. But the ability to compare and contrast the understanding that comes at a deeper level of knowledge that does transfer, your ability to understand patterns, to understand principles of programming, that information does transfer. The implementation details quickly fade away in importance. And instead, the great developer chooses to focus more on the overall effect, the meta-principle at hand. Thank you so much for listening to today's episode of Developer Tea. Hopefully, this is an encouragement to you, not only in the way of you not having to go and memorize every single little thing in every standard library of every language that you use, but also to avoid wasting time, this is kind of a key bonus takeaway for today's episode, avoid wasting time arguing over the minutia of a given programming language implementation. This is extremely important for your maturity as a developer to avoid arguing over unnecessary minutia.