Hey, everyone, and welcome to Developer Tea. My name is Jonathan Cottrell. 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 at Gmail. I highly encourage you to do that. I love getting questions from the users of this 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... When you shouldn't listen to what I have to say, and what 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... 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 that 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. At the end of the day, evolution brings evolution. At the end of the day evolution brings evolution. At the end of evolution brings evolution. 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. 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 billed 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 Tea listeners a $20 credit when you use the code DeveloperT20 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. DeveloperT20. 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. And to 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. Your 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. In 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. Right. 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 login. It's likely that you want to. Give them the sense of security. That a multi-step login 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 a hundred people. That it is also ready for a thousand 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 game. In 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 co-workers. 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 this special code. By going to spec.fm. Slash Linode. The special code is developer T20. 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. Bye.