Hey, everyone and welcome to Developer Tea. My name is Jonathan Cutrell and in today's episode, we're talking about when advice fails you. On Developer Tea, we give you a lot of advice. And hopefully that advice has helped you in many situations. We have people who ask questions, they send in questions to Developer Tea Gmail. I highly encourage you to do that. I love getting questions from the users of the show, or from the listeners rather of this show. We also get a lot of great conversation happening on the spec Slack community. If you go to spec.fm slash Slack, you can see some of those conversations. A recent conversation talked about the idea that inspired today's episode. And the idea is simply when user experience recommendations are wrong. Another conversation on the spec Slack community. They were in the Developer Tea room and they were talking about polymer. And they were talking about the positives and the negatives of polymer. And this kind of also feeds into our discussion. You know, the plug-and-play concept, and when that is useful, and when maybe it's a little bit more hurtful. So I want to take a moment and discuss this a little bit further and talk about when my advice is wrong. When you shouldn't listen to what I have to say and went other people who are giving you advice have to say, everything that I say on this show should be taken with a grain of salt. And we're going to talk more specifically after the sponsor break in just a minute about when traditional recommendations or some of the advice that you may even hear on this show would be not applicable when you would actually find that going against that advice is a better idea. But more broadly, I want you to think about this for a second, a little bit deeper. You know, you would develop these ways of thinking as a developer and you learn how to view things through a certain lens. You start gaining some intuition over the course of your career. For example, you gain an intuition by hearing over and over and over. The optimization is a good thing. You gain intuition by hearing over and over and over and over that maintainable code should be a top priority. You gain intuition when you read the title of a book that says, don't make me think. Now, of course, a lot of this is good conventional wisdom. And ultimately, what you have to do is build a general way of thinking about things and apply it and then test that general way of thinking about things against that specific situation. And we're going to talk about a few of those specific situations right after this quick sponsor break. Today's episode is sponsored by No Stranger To The Show. Linode has been sponsoring Developer Tea for quite a while. And for good reason, people who listen to this show, you need a service exactly like Linode. Linode offers two gigabytes of RAM on a $10 server. This is a Linux server that you can do almost anything that you can think of with. They have eight data centers and all of their plans are built on an hourly basis. And again, the best part of this is that it's absolutely the best deal that you're going to get on a server because not only is Linode only $10 a month for their two gigabyte tier, they're also offering Developer Tealisteners a $20 credit when you use the code Developer Tea 20 at checkout. So go and check it out spec.fm slash Linode that's spec.fm slash Linode that will take you directly to and apply that special code Developer Tea 20 that gives you $20 of credit at Linode. Thank you so much again to Linode for sponsoring Developer Tea today and many other times in the past and into the future. Thank you again to Linode. So we're talking about when conventional wisdom or advice doesn't serve you well as a developer, you need to be able to look at the specific scenarios that you are facing and apply this knowledge that you have, the general rules that you use about development. So for example, the discussion that inspired today's episode was in the general room in the spec slack community and we were talking about logins and when logins are too simple. As a general rule, we know that it's important to make the user's login experience as seamless and simple as possible. We want people to log in very easily to our application assuming they have the right credentials. But there are times when you want login to be a little bit more difficult and this specific scenario that was discussed in the spec slack community. One of those times may be when your application is dealing with sensitive information. For example, in this case, the health information for you or your family or private health information that you don't want someone else getting a hold of. And the reason this is so important to think about is because if someone feels like your application is not secure, which was the case, and some of the research that was being done by these individuals, if someone feels that way about your application, they may not use it at all anyway. So it's important that your specific scenario, in this case, your health information that you use the user's actual scenario to make those decisions about your user experience. For most users with something like sensitive data, for example, a bank log in, it's likely that you want to give them the sense of security that a multi-step log in provides. Another example of this was not necessarily discussed in the spec slack community, but creating a beta invite experience is very likely that if the beta is ready for 100 people, that it is also ready for 1,000 people. Now, the only bottleneck here may be customer service or some kind of customer support. There may be an actual bottleneck there, but most likely, what people are creating when they do a beta invite experience is some level of psychological benefit. So even though the tech would allow you to scale as quickly as possible, you may decide that the psychological benefit of feeling like you're being invited to something exclusive, that may prove to be just as valuable as scaling quickly. Another example is building applications mobile first as a rule. Now, this one's going to be probably the most controversial example in today's episode, because as a general rule, progressive enhancement is going to be more cost effective for a given scenario. But if you know that your target application will always be run on desktops, or even in the 95% use case, it's going to be run on desktops and that the mobile experience is always going to be underserved, then it is not unreasonable to go against the conventional wisdom of building your site in that case, mobile first. What this comes down to is doing your homework, doing your research, understanding what your user is going through, not only what your user is going through, but what they are thinking about. What are their priorities? What do they prefer? How do they feel when they're using your application? While most people are in a hurry, they will likely slow down to secure their health data. And in the same way that health data may change the specifics of that application, any other variable could change the specifics of your application. So the lesson here is to take the advice that you get on this show, and in any other place on the internet, or from your superiors, or from your coworkers, take all of that advice with a grain of salt, and do your research, understand your situation. Instead of just using the most popular library that's come out most recently, think about why you would use that library. Understand why it has become popular. Understand the good parts and the bad parts. Don't take advice or trends at face value. Do your research. Thanks so much for listening to today's episode of Developer Tea. I hope you've enjoyed our discussion on when to listen to advice. Thank you again to today's sponsor, Linode. If you're looking for a server, and most of you probably need a server, at least for your side projects, go and check it out, Linode.com. And you can get the special code by going to spec.fm slash Linode. The special code is Developer Tea 20. That will give you $20 of credit at checkout. Thank you again to Linode. Thanks so much for listening to Developer Tea. If you're enjoying today's episode, go and check out the other shows on the spec network. That's spec.fm. And of course, you can join the conversation by going to spec.fm slash Slack. That is the spec Slack community. Thank you so much for listening and until next time, enjoy your tea.