What is the best advice that you've ever received? Perhaps the advice was about something in your career or something totally unrelated. I want you to think of it about that advice. And then I want you to think about some of the things that you've heard on this podcast or in your career about what it means to be a great developer. And indeed, we've talked about the subject. The length, in fact, we had multiple episodes where we identified ways of thinking that a great developer adopts. I want you to think about that advice as it relates to your life today, as it relates to whatever you're doing today. Is it still relevant? There's a high chance that it is, especially if you've got the advice sort of recently. And because most people are going to recall fairly recent events, it makes sense that the advice would be relevant. But imagine if you were to rewind to your teenage years or perhaps even younger in grade school years, and you try to apply the same advice. Would it be relevant then? What about relevance for 10 years from now? When is that advice good? That's what we're talking about on today's episode as kind of a primer for upcoming episodes where we give advice. And I want to set the stage for how you should be listening to advice 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 so you can do better work and have a positive influence on the people around you. And here's the thing about advice. This is almost always context dependent. And in fact, you could argue that it is always context dependent. And unfortunately, very often, we hold on to advice. Now, of course, advice that people give you over the course of your career should be listened to and judged and managed. But how do you know when to let advice go? Well, let me use a different word because we're using the word advice a lot. What does advice actually mean? Well, it's someone telling you a way or a belief that you can adopt and perhaps a resulting action that you may be able to take in order to achieve some ideal state, whether that's an internal state or maybe it's something external to you. Something state in your career, for example. Now, that's a very broad way of putting it, right? We have someone coming along in our lives or maybe it's a book that we read or in this case, a podcast that we listen to, telling us how we should see things. How should we behave in a given circumstance? And so what makes that advice reliable? What makes it applicable? The reality for most developers is that we carry advice that we received perhaps early in our careers and we hold on to it and we use it over and over and over. And eventually this advice that we receive, we codify it. We turn it into something more than just one person's suggestion. Enough people adopting this suggestion. We turn it into something like a best practice. And then the best practice becomes the way to do things. We all agree on this way of doing things. And eventually the context where those suggestions were originally kind of formed, the context is no longer available for us to judge those suggestions by suggestions that have done a lot of good for developers and helping them achieve what they were trying to achieve. Like do not repeat yourself or all of the many principles that great developers who have come before me have helped establish these things that we kind of all generally agree on these patterns of software development and even anti-patterns, ways of not doing things. And these are some of the things that we want to talk about on the show because as it turns out they are quite useful and useful in many different contexts. But the truth is that there is no single piece of advice that you will receive especially in the context of software development that is universally applicable. We're going to talk about how to hear and apply advice right after we talk about today's sponsor, Linode. Today's episode is sponsored by Linode. Linode is a long time sponsor of Developer Tea and they keep coming back because Linode invests in the developer community. Linode is not only going to continue sponsoring Developer Tea for more episodes but they're also giving Developer Tealisteners credit to use on their services. What does Linode provide? They provide Linux in the cloud at the industry leading price point that's starting at $5 years a month. Linode has 24-7 customer support and a wide range of open source projects that Linode supports to build their services. So it's not just a black box of services, it's actually developers on the other end of this that are working to make Linode better for you developers. Go and check it out. Head over to linode.com slash Developer Teato get started today and use the code Developer Tea2018 at checkout for $20 worth of credit. By the way, we mentioned that $5 a month plan, that $20 worth of credit can get you four months on Linode services. Head over to linode.com slash Developer Teato get started. Thank you, Gendel Linode for sponsoring today's episode of Developer Tea. So we're talking about whether or not you can trust advice and we've already kind of proven. Hopefully you recalled some advice that wouldn't necessarily be applicable in your teenage years or your young life in your grade school years or perhaps even 10 years from today that advice may not apply at all. And so it's important to understand that advice is given within a context. And we should be able to realize that this is true for all of our best practices as developers. A very good example of this is writing maintainable code. Now there's some really good argumentation about this, some great conversations online, civil disagreements between people about whether or not it makes sense to always write maintainable code. And the short theory of the side that says that it's not always necessary to write maintainable code and in fact, may even be wasteful to write maintainable code every single time. The theory essentially says that if you know for a fact that this code is going to be disposed of, it will be used once and then gotten rid of or for whatever reason it's going to be locked and never touched again. In the point of writing maintainable code no longer exists. And maintainable code costs more to develop than non-maintainable code. And you'll notice here that the core concept that the advice puts forward, that maintainable code is good, is not being challenged by this new context. Maintainable code is good. However in some contexts it is also too expensive. In other words, maintainable code may still continue to be a good thing, but it's also not necessarily the best choice in this particular context. And naturally our brains don't really like to think about our beliefs in this manner because it requires us to re-evaluate what we believe is the right course of action. So when we walk into a given project, we bring with us our experiences and therefore our assumptions about the world and about this project. And as we move forward into a project and we apply advice that we've received in the past very often we do so through the lens of some assumption. One of these assumptions that I personally have experienced in the past was the assumption that the thing that I was making needed to be profitable, that the users who came to use this product would find it useful enough to pay for it. Now this seems like a reasonable assumption, especially if you worked in a startup world or if you worked on a product for a young company and they're trying to build a viable product. But in this particular case, I was working with an established company and they were developing a product that they wanted to provide to their existing customers purely as an improvement to their customer experience. The product was not intended to drive some major amount of revenue. Now this was a counterintuitive thing to encounter as a developer because most of the time my assumptions don't line up with that view. And so the advice of always looking for expensive black holes of complexity for example, that may not necessarily apply in the same way in that kind of project. So it's important to evaluate your context as you're moving through, ask yourself what assumptions am I making and therefore what advice, what best practices, what am I bringing into this project that hasn't explicitly been validated as necessary. This is truly the birthplace of so many costly mistakes that we make as developers, not as necessarily the birthplace of bugs that we bring into the software, but instead of things like over optimization. And so as we move into episodes where we talk about things like anti-patterns, I want you to understand that these episodes are intended to assume kind of an average context. That average context is that you're working as a developer in a professional atmosphere for a company that relies on whatever you're doing as some kind of profit center. In other words, the code that you are writing will be iterated on and it matters to the company that the code is high quality. This is a specific context. It's a very common context, but it's a specific context that some of the things that we may discuss if we were not in that same context, they may not apply in the same way. But hopefully as you'll see, there are some things that really apply quite broadly that we're going to discuss in these episodes. So a very simple takeaway, a piece of homework for today's episode, as you work today, identify maybe a list of three assumptions that you make. Don't necessarily have to change them. Don't necessarily have to do anything different. Just identify them as assumptions. Things that somebody hasn't necessarily told you about that project, but that you went ahead and kind of filled in the blank. Thank you so much for listening to today's episode. Thank you again to Linode for sponsoring today's episode with Linode. You can get an SSD server in the cloud for only $5 a month and you're going to get $20 or $20 worth of credit just for being a Developer Tealistener. Head over to linode.com slash Developer Tea and use the code Developer Tea2018 at checkout. Thank you so much for listening and until next time, enjoy your tea.