One of the most critical and fundamental skills any developer must cultivate is the ability to map. Mapping is the concept of taking some information and relating it to some other information. This seems overly simplified, but if we apply this to actual maps, we can see the direct correlation. For example, when we take a picture with a satellite, we have pixels, and we can map those pixels to actual latitude and longitude points in our physical world. What's interesting is that latitude and longitude is, in and of itself, a mapping exercise. And so it stands to reason that we can map the map of the world. It stands to reason that we can stack maps on top of each other. We can add new information using old maps. That's exactly what we're doing when we're creating routes on these existing maps. We're taking the many different layers and compressing them together, creating multiple maps that are abstracted from underlying maps. In fact, almost all of the information that we operate on on a day-to-day basis is abstracted from underlying maps. It relies on some kind of mapping. But it stands to reason that, as with most things that humans try to do, very often we get our mapping wrong. In today's episode, we're going to talk about how forcing a concept into the wrong model can cause major problems in software and in your career as a whole. My name is Jonathan Cottrell. You're listening to Developer Tea. And my goal on this show is to help you learn how to map in a way that works for you. is to help driven developers like you find clarity, perspective, and purpose in their careers. As with all models, a model is not a pure picture of the truth. Alfred Korzybski first said that a map is not the territory it represents, but if it's correct, it has a similar structure to the territory, which accounts for its usefulness. Once again, if we think about actual maps that we use, Google Maps, for example, satellite imagery on Google Maps often is out of date. In fact, it's always out of date to some degree. Therefore, it cannot ever be exactly the territory. However, models are useful. Just because a map's satellite imagery is not the territory, it's not the map's territory. If a map's satellite imagery is not perfectly up-to-date, it doesn't mean that those images don't represent some picture of today's current reality. In most cases, those images are up-to-date enough to be useful. And it's important to recognize, as with so many topics on this show, the necessity of context. In what way can a map be useful? In what way can a map be useful? In what way can a model be useful? We talked about models in the last episode of Developer Tea. Specifically, we talked about the idea of having implicit and explicit models that inform our various processes. And it's important to think about your models, but it's also necessary to think about how models can steer us wrong. Models can, and often do, give us a false sense of confidence. But it's not just because we pick a model. It's because we pick a model. It's because we pick a model. It's because we pick a model. It's because we pick a model. It's because we pick a model. It's because we pick a model. We shouldn't always blame the model. And in today's episode, I want to talk about how we can easily abuse a model and distort and otherwise change the original problem to fit the model that we choose. But first, I want to talk about today's sponsor, Linode. As a developer, you've probably got a project that you're working on. Whether that's a project that you're working on, or a project that you're working on, or a project that you're working on, a personal project, or if you're managing your enterprise's infrastructure, Linode has the pricing, the support, and the scale that you need to take your project to the next level. Linode has 11 data centers worldwide, so you're not going to have to worry about latency. Their newest data center is in Sydney, Australia. They have enterprise-grade hardware, S3-compatible storage options, and a next-generation network. Linode delivers the performance you expect at a price that you don't. For example, their Nano plan starts as low as $1,000. At $5 a month, Linode is a company built for developers. This is why you're going to get root access to your server along with a very mature API. It's already at version 4 and a Python CLI that you can use to manage your Linode servers in customized and automated ways, limited basically by your imagination. You can get a dedicated CPU plan with physical cores reserved just for you with no CPU steal. Or you can get something like a GPU compute plan that's suitable for AI, machine learning, or video processing. Linode has block storage. They have native SSD storage on a 40 gigabit internal network. You can do object storage with Linode. You have one-click installs for most popular apps, including things like WordPress on a LAMP stack, game servers for Minecraft, and much more. Head over to linode.com slash developer T. Use the code developer T2020. That's all. One word developer T2020 at checkout for $20 worth of credit as a developer T listener. Thanks so much to Linode for sponsoring today's episode of developer T. We're talking about mapping concepts to models in today's episode. But I want to take it from the other direction. It's possible that if you're working in software, you already have a model. This model may be a framework. It may be a set of tools that you use. Perhaps even some habits that you've picked up. And while most of these things can be generalized to solve many different types of problems, they are still indeed some kind of model. And when you take a model to a problem, it's necessary to understand that you're doing the same kind of mapping. And this shouldn't be a surprise. It's a problem that's going to be a problem. If you approach a problem using an MVC structure, then it's necessary to identify the models, the views, and the controllers that are part of that problem domain. You're mapping the concepts to the model of MVC. And of course, these kinds of frameworks, these broad, generalizable models, can be very flexible. For example, language. Language is another kind of model that allows us to map seemingly an infinite number of concepts to. But every model has its restrictions. And the more specific your model gets, the more likely those restrictions will come into play for a given problem scenario. And what often happens with developers who only have a limited model to work with is that they'll take a problem and reshape the problem. At the very least, they may find the problem to fit the model. This isn't explicitly wrong per se. It might mean that you are solving a different problem than you thought you were solving. It might mean that you are translating the problem into a different domain. But if this translation is a large enough jump, or if you are changing the problem enough to fit the model that the problem doesn't really look like it did at the beginning at all, perhaps it's not recognizable as the same problem, perhaps it's time to consider a different model. It's also important to recognize that this doesn't always happen in a single action. You might think that the model fits the problem to begin with, and you start working on that problem using that model, using that set of tools, using that particular framework, and you walk down that path, iterating on your code base or whatever. And eventually, you start running into problem after problem that requires you to do something that is kind of on the edge of the model, or requires a translation jump that is not necessarily natural. Imagine, for example, that when you were given directions from Google Maps or something, that you could only represent directions with colors on the screen. Now, blue is a left, and red is a right, and you have a list of those colors kind of laid out before you as your directions. Now, of course, this is a contrived example, but you might approach this problem initially and say, well, of course, this makes sense. We have a one-to-one mapping. Blue is left and red is right. There's nothing more to figure out here. But then you realize that the system is insufficient. The model of using the system is insufficient. The blocks of color for directions is insufficient. For example, do I take the next road? Do I take the next left? Or do I wait a few roads and then take the left? And in this obviously contrived example, you can quickly see those restrictions. But in your work, it's likely that you won't see those restrictions as quickly. So it's important to try to think forward, to play all the way through to the end. And imagine the model as it might look in a later stage. One thing you can do to try to catch these kinds of problems is a pre-mortem and specifically focus your pre-mortem on whether the model fits. Do your various models and almost every project of sufficient size is going to rely on multiple models. Not just models for building software, but multiple mental models. Multiple models for building software. Multiple domain models. And so it makes sense to evaluate some of these models ahead of time. Does the model fit the problem well? Or are we trying to change this problem to fit our model? Remember that no model is going to fit any problem perfectly. But choosing good models is about creating maps that are useful. Thank you so much for listening to today's episode of Developer Tea. I hope you enjoyed it. If you did, please share it with someone you think will benefit from it. And if you enjoyed today's episode, please share it with someone you think will benefit from it. And subscribe to whatever podcasting app you are currently listening to. Today's episode was produced by Sarah Jackson. My name is Jonathan Cottrell. And until next time, enjoy your tea. Bye. Bye.