Today's episode is sponsored by Linode! Head over to Linode.com/developertea or use the code DeveloperTea20 at checkout for a $20 credit towards your cloud hosting account! Thanks again to Linode for your support of Developer Tea.
In today's episode, I answer listener Jean Michel's question about bikeshedding.
Mentioned or relevant to today's episode:
Today's episode is sponsored by Linode! Head over to Linode.com/developertea or use the code DeveloperTea20 at checkout for a $20 credit towards your cloud hosting account! Thanks again to Linode for your support of Developer Tea.
Please take a moment and subscribe and review the show! Click here to review Developer Tea in iTunes.
Hey, everyone, and welcome to Developer Team. My name is Jonathan Cottrell, and in today's episode, I'm answering a listener question from Jean-Michael Fayard. Jean, I hope I didn't mispronounce your name. Jean 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, Jean-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 C. Northcote 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 node location. Of course, we are going to talk more about what Linode has to offer to developer T listeners 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? Take 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. They 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. 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, it is best to make standard decisions that prefer tools your team is already proficient with to avoid trivial comparisons that are not as good as the ones you're using. So if you're going to learn something new, use something you already know how to use. In a 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. Use something you are already proficient with. I've got somewhat of a bonus point in here, a 1B, 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 already been solved. Beware of the one-thing mentality. That's what I'm going to call it. 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 tool doesn't have this one thing, so we're just going to rebuild it 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 1%, 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 1%. 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, it is likely that someone else is too. And extending the existing solution is a faster route to success. So you may just open an issue 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 B, 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 end frameworks. They have a problem making those decisions because they have this not built here syndrome, which is, 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 you've done that. So let's get right to it. So let's talk about how to avoid bike shedding. Today's sponsor is Linode. Linode has eight data centers. Their plans start at $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 Git server. You could scale up. 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 too. 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 T20, or you can go to lino.com slash developer T, and that credit will be applied to your car at checkout. So go and check it out. lino.com $20 of free credit by using the code developer T20, lino.com slash developer T. Of course, that link and all the other links from today's episode will be at spec.fm. As usual. So we're talking about bulletproof 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 other things. If you're 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 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 as detailed as possible, by the way, make it down to the minute if you can. And 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. You as the developer, take the lead in 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 aren't 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, 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 align. 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 copywriter 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, you're writing code most likely, or you're, 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 a copywriter, you're sitting in that other seat. It's important to remember that you are working on a team and that you are working on a team. And that you are working on a team. 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. John 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 your, 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'll 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. .