Hey everyone and welcome to Developer Tea. My name is Jonathan Cutrell and today's episode I'm answering a listener question from Jon Michael Feyard. Jon I hope I didn't mispronounce your name. Jon reached out to me on our Slack community and he asked me to talk a little bit more about focus. Now we have talked about focus plenty of times in the past but specifically Jon Michael is asking about bike shedding and this is the idea of group focus and focusing specifically on the wrong things. Now this concept of bike shedding comes from the law of triviality or Parkinson's law of triviality. I'm going to read a little bit from the Wikipedia page here. Wikipedia says Parkinson's law of triviality is see North Coat Parkinson's 1957 argument that members of an organization give disproportionate weight to trivial issues. He observed that a committee whose job was to approve the plans for a nuclear power plant spent the majority of its time on discussions about relatively minor but easy to grasp issues such as what materials to use for the staff bike shed while neglecting the proposed design of the plant itself which is far more important but also a far more difficult and complex task. So the idea here is that people who meet together in an organization they're going to focus on things that are relatively easy to grasp because perhaps because they are easy to talk about rather than the harder issues at hand and I want to talk to you about how to avoid bike shedding and hopefully shed some light on this subject for you all. Today's episode is sponsored by Linode with Linode you can instantly deploy and manage an SSD server in the Linode cloud. You can get a server running in just seconds with your choice of Linux distribution resources and no location of course we are going to talk more about what Linode has to offer to develop a T-list and later on in the episode but first I want to talk to you about how to avoid bike shedding. Bulletproof ways to avoid bike shedding. Number one I've got three points here for you today. Number one make decisions about relatively trivial things before your meeting begins. Make decisions about relatively trivial things before your meeting begins. How many bike sheds exist in the world? Well I don't have a number for you but you can imagine that it's quite a few and the concept is that if there are a lot of bike sheds already out there right if that problem has been solved then why not go and look at statistics or maybe just Google the idea of a bike shed. Now they didn't have Google in 1957 but the concept is still underlying. How do you build a bike shed? Make the most common and the most proven ways of building a bike shed and reuse them. Determine standard go to answers for common problems. For example if you're building a web project don't argue over what front end framework you will use. This is incredibly tempting to do right because a lot of people want to use bootstrap and a lot of other people want to use foundation and some people want to roll their own frameworks. Instead of arguing over this kind of relatively trivial thing take a quick majority vote and use the one your developers are most excited about and familiar with that has decent followership and is regularly maintained. These are the kind of things that you want to look for. You don't need to argue over the semantics or over the way that the thing is built. Most of them have relatively similar things going on inside of them right. Maybe you have a particular way that you like to build your CSS. Well just use that one. Don't argue over this otherwise relatively trivial decision because the truth is successful projects on all of those front end frameworks are out there in the wild and they're succeeding regardless of the framework that they're on. So it doesn't really matter which one you use right. It doesn't have a major impact. Now does it not matter at all? Of course not. I'm not saying that it doesn't matter at all. I am saying that the amount of impact that it has is relatively slim. So make a decision and move on instead of spending a bunch of your energy on this otherwise relatively trivial decision. If your goal isn't to learn a new tool that is best to make standard decisions that prefer tools your team is already proficient with to avoid trivial comparisons between relatively equivalent tools in shorter sentence. All we're saying here is if you aren't trying to learn something new use something you already know how to use right use something you are already proficient with. I've got somewhat of a bonus point in here a 1 B and that is to explicitly outlaw the not built here syndrome explicitly outlaw the not built here syndrome if people are not okay with using solutions that already solve classic problems things that you've seen a hundred times and that you're going to see another hundred times they will end up trying to write far too many custom pieces of software for every imaginable purpose right. They're solving problems that have have already been solved beware of the one thing mentality that's from a call at the quote one thing mentality this open source project does everything we need except this one thing beware of that mentality and the reason that that's problematic is number one if the thing you are wanting to use let's say a task management suite has 99% of the functionality you need then it is by every imaginable rational process the right solution at the very least for the beginning of your project once again not built here syndrome outlaw it entirely because if you have this one thing mentality the problem with that one thing thinking where you say okay well this tools doesn't have this one thing so we're just going to rebuild it from the from the ground up that's completely irrational the second reason that's a problem is because if someone is suggesting that you build an entire software suite to replicate the 99% of the functionality that the existing solution already has and then only adds value with the extra one percent you're almost certainly experiencing loss you're almost certainly wasting money resources time consider creating something instead that connects to the API of the software you're currently using or the solution that already exists or connect with the creators of the existing project and ask if they would be willing to add the functionality that you have in mind that extra one percent if the project is open source you might consider forking the project or submitting a pull request but if you're experiencing a particular problem and is likely that someone else is to and extending the existing solution is a faster route to success so you may just open an issue right on that open source project and say hey I'd really like to see this extension and it's likely that someone else would like to see that same extension so again to avoid bike shedding number one make decisions about relatively trivial things before your meeting begins or before your discussion or your project begins and that one be the bonus section there was explicitly outlaw the not built here syndrome and the reason that's an extension to the first one is because a lot of people try to make the entire project fully custom and they make the decisions about what would otherwise be relatively trivial things things that have already been solved in the past like front and frameworks they have a problem you know making those decisions because they have this not built here syndrome which essentially says that since we didn't build it we don't trust it this is a fear that a lot of developers have and they would prefer to rebuild all the functionality rather than learn how someone else has already solved that problem so explicitly outlaw the not built here syndrome so you can solve these relatively trivial problems with existing software packages and we're going to talk more about how to avoid bike shedding right after this quick sponsor break today's sponsor is Linode Linode has eight data centers that plans started $10 a month and you can get a server running in under a minute Linode has hourly billing this is my favorite feature by the way hourly billing with a monthly cap on all of their plans and their add on services not to mention the fact that all of their servers are totally flexible you can run a VM you can run Docker containers you can run your private get server you could scale up for one day if you wanted to and only pay for that one day that flexibility is incredible and if you're concerned about speed well Linode has your back covered there to they have native SSD storage on a 40 gigabit network with Intel E5 processors so speed on the internal network is not going to be a problem on top of all of this if you're not happy with linode in the first seven days you can get your money back that's a guarantee that linode has and if you are not already convinced well linode is going to give you $20 to help convince you you can get a $20 credit by using the code Developer Tea20 or you can go to linode comm slash Developer Tea and that credit will be applied to your car at checkout so go and check it out linode comm $20 a free credit by using the code Developer Tea20 linode comm slash Developer Tea of course that link and all the other links from today's episode will be at spec dot fm as usual so we're talking about bullet proof ways to avoid bike shedding number one make decisions about relatively trivial things before a meeting begins and that extension the bonus point was explicitly outlaw the not built here syndrome okay number two when conducting any kind of meeting whether it is a digital and asynchronous meeting right which would be like emailing back and forth for example or a bunch of cross functional people in a conference room in person together you should always have an agenda for the meeting that elevates the things that do matter in other words decide in advance what you're going to talk about decide in advance what what topics of discussion are going to be included in today's meeting and this will help avoid so many rabbit trail discussions so many you know off the cuff discussions that should have never happened if you plan to have specific discussions if you have an agenda and make that agenda is detailed as possible by the way make it down to the minute if you can and you're you're probably going to divert from that agenda just go ahead and be aware of that don't get frustrated or don't get derailed just because you've gone away from the agenda a little bit but having those rails on your discussion this does not allow a general discussion meeting to occur right you don't open the floor for anyone to say anything instead you have guidelines you have a goal in mind you have the important things visibly in front of you this gives everyone the license to try to steer the conversation back towards the agenda right this gives everyone the awareness of what is important even if the meeting starts out as a general discussion meeting you can take the lead use the developer take the lead and cutting out non relevant discussion by asking for everyone to determine the most important and impactful topics to discuss for that particular meeting you very simply can say hey guys before we start this meeting I want to write down what we're going to talk about today so that we spend our time most effectively a lot of people will actually appreciate that nobody wants to waste their time nobody that you work with should want to waste their time at least and hopefully nobody wants to waste your time either so if you say hey let's make sure we are wasting time and let's decide the topics that we're going to discuss that's going to help steer the meeting similar to a predetermined agenda so never allow for an open discussion meeting to just kind of blossom to grow out of nowhere because typically those discussion meetings end up going down a rabbit hole or one person has one specific thing they want to talk about and they'll focus on it for the duration of the meeting it's not intentional it just happens when there isn't a good plan in place for the meeting now before we go into the final tip I want to say that we aren't just talking about avoiding bike shedding right because we can avoid bike shedding by not having meetings altogether really what we're talking about is how do we have productive meetings how can we have meetings where we are actually solving problems because again we can avoid bike shedding by just simply sitting in a room and being silent we can avoid bike shedding by not having meetings at all so this last point is actually about managing what happens when bike shedding does occur because it will you're not going to avoid it every time and part of the reason for that is because even though you spend the time making it very intentionally clear to everyone that we don't want to bike shed in this meeting right we don't want to waste time in this meeting sometimes what is important to one person is unimportant to another right that's very simple because some of us have different responsibilities some of us have different appreciations for particular topics and so very clearly especially when we get into cross functional teams those things are not going to line so number three is avoid shaming any particular topic and remember that what may be unimportant to one person could be incredibly important to another one as I said before this is especially true for cross functional teams if you're working with a designer or a copyrighter as a developer it is possible that part of the meeting will feel like bike shedding to you because it may seem irrelevant to your part of the execution however you could very easily hurt your relational dynamics between you and your teammates if you call their topics of discussion trivial or unimportant right and think about this from the personal level when you are focusing your writing code most likely or your you know maybe you're thinking about a particular problem and then eventually writing code when a copywriter is focusing they're not writing code they're not thinking about the problems that you are solving writing code so it's important for you as a developer and simply as a team member even if you're not a developer and you're listening to this if you're a designer or copywriter you're sitting in that other seat it's important to remember that you are working on a team and that you are trying to focus as a team and that doesn't mean necessarily that every single thing you're going to discuss will be relevant to your personal execution instead the group focus means that we're talking about the things that are important for this project and your participation in that group is to provide the expertise and the insight to help direct when things go off the rails so if somebody is talking about content and you you know that your system doesn't support the particular kind of content that they're wanting to put into your system then you have the opportunity to help avoid a long term problem right there in that meeting that's why you're there you're there because of your knowledge not simply to get all the information that you need for your execution but to also provide information that other people need for their execution so always ask for clarification and connection as the conversation progresses as to how it impacts the project small details and details that don't affect everyone are not necessarily unimportant however the idea of avoiding bike shedding is discussing the right things at the right time and framing them in the right scope. Jon Michael I hope that this has been a helpful discussion on bike shedding and I hope that you can go forth in your meetings with other developers and maybe with cross functional teams and help avoid bike shedding by making those decisions beforehand those trivial decisions trying to make those decisions create those standards define the tools and the tool set that you are your company defaults to for example that's going to be incredibly helpful hopefully to your process as well as other people who are facing these same problems. Thank you so much for listening to Developer Tea today and thank you to today's sponsor Linode. With Linode you can instantly deploy and manage an SSD server in the Linode cloud you can do it for seven days with a money back guarantee and you can get $20 of credit by using the code Developer Tea 20 all you have to do is go to linode.com slash Developer Tea and of course all those details can be found in the show notes at spec.fm. If you enjoyed today's episode of Developer Tea and you don't want to miss out on future episodes go to your podcasting app right now take just a few seconds all you have to do is click that subscribe button it's going to make sure that you don't miss out on future episodes because it will deliver it directly to whatever device you are listening on. As always if you thought that this show was valuable make sure you share it with someone and go and leave a review on iTunes it's the best way to help other developers just like you find Developer Tea. Thanks so much for listening and until next time enjoy your tea.