Hey everyone and welcome to Developer Tea. My name is Jonathan Cutrell and today I'm going to be talking to you about the XY problem. What is the XY problem? I'm not talking about algebra. I'm actually talking about an issue that we as programmers face every single day probably. But before we get into the show, I want to thank today's sponsor one month dot com. If you are wanting to learn to program or even if you're not wanting to learn to program, you already know how to program and you want to learn something new, maybe iOS or perhaps you're starting a business and you want to do something like a growth hacking seminar. You can check out one month dot com. One month provides incredible resources for people looking to learn these kinds of things. We'll talk more about one month later on in the show. At first I want to go ahead and jump into this discussion about the XY problem and then we'll talk about how to avoid the XY problem. This is probably one of my most favorite things that I've found recently, the XY problem. If you go to xyproblem.info, you can actually read about this because it's a little bit difficult to explain on a podcast but I want to go ahead and venture a try at it because it's so interesting to me and I think it's worth talking about. The XY problem happens when you have an issue, some kind of problem you're trying to solve. My favorite one that I've seen so far is the example of trying to get the file extension off of a file and you can't seem to find the solution that pulls the file extension, whatever the code is and Ruby or something. You can't seem to find the thing that pulls out the file extension. If you ask the question, how can I get the last three letters from a file's name? This is a secondary way of approaching the problem because a lot of file extensions are three letters long and if I can just manage to get the last three letters of this string then I will have the file extension. This presents a few issues. The real problem that you're trying to solve, the X in the XY, the X problem that you're trying to solve is I need to get the file extension of a given file. The Y problem that you have decided to solve instead is entirely separate from the X problem. If you're trying to get the last three letters of a file name that is not actually the spirit of the problem that you're trying to solve and this becomes a real issue when you try to articulate your problem to another person so that they can help you solve it. This happens in IRC chats all the time. It happens over Slack at whiteboard sometimes and it even happens in person. You ask a person how to do why when you're actually trying to do X. As it turns out with our file extension problem, you wouldn't be getting the file extension with the last three characters every time anyway. Some file extensions are four characters. Some file extensions are significantly longer than four characters and some are even less than three characters. You're not adequately solving the problem anyway by solving Y. Beyond the fact that solving Y isn't directly solving X and sometimes is an inadequate approach, a lot of the time solving X is as easily or more easily done than solving Y. I'm going to take a quick sponsor break and then we're going to come back and talk about how to avoid the XY problem and how to deal with it when you see it coming up around you, how to deal with it, especially if you are in a management's position and you are getting questions that seem to be on the Y side instead of the X side. We'll talk about how to ask better questions and how to get to the root of what you were trying to do. I talk about learning all the time on this podcast and this episode is no different. Learning is an incredibly important part of a developer's career and if you want to learn how to do something in one month, it's kind of hard to do that on your own and that's exactly what onemonth.com helps you do. If you want to learn Swift for iOS in one month, you can build an iPhone app with Vimeo with Swift on iOS in just a month. If you want to learn how to build a Pinterest style website with Rails, you can do that in a month. You can learn Python, web security, programming basics and especially for those who have been waiting to learn jQuery for some reason or you have not been exposed to it yet, one month just released their new course on jQuery and you can get started right now and you get 25% off your first month. Only it is 36.75 per month or 74.25 per month for the unlimited plan but if you go to one month.com slash Developer Tea, you can get 25% off of that price. Go and check it out onemonth.com slash Developer Tea. Thank you again to one month for being a sponsor of the show. So how do we solve this XY problem or rather how do we avoid falling into this XY problem where we are trying to solve X but we instead we try to do Y in order to solve X. Perhaps it won't surprise you that we should start by stating exactly what X is in our file extension example. We should start by stating that our intention is to get the file extension from a given file name. But sometimes it's a little bit more difficult to describe exactly what X is. Sometimes it's a bit more elusive. So how do we describe X well? First of all we need to provide context. What is the actual problem we are trying to solve and the way we do this is by escaping the jargon if possible. In other words if we have for example a user class that has a first and a last name defined on that user class. You should start using the words first and last name instead of referring to it as the classical data structure name of string. Providing this context allows us to look at the problem rather than the proposed solution to the problem. Let's say for example that you are trying to create a method on the user class that returns the initials of a given person's name. When you state this problem you should use the terms initials in person and name rather than saying that you want some arbitrary method that takes a number of strings as arguments and returns the first letter from each string concatenated and separated by periods. And the reason for this is because sometimes people have a very simple way of understanding the intention of the problem that you are trying to solve. Now in that particular example describing that method in that way we get you to the solution that you need. But even in this example it is far easier to explain your intention by saying you want a method that returns a person's initials rather than going through that entire long spiel about a method that concatenates all of the first initials of an arbitrary number of strings. The other part of this particular problem is that you may be ignoring the fact that the person has a middle name or you could be ignoring the fact that a lot of the time when you see a person's initials if they also have a title like Dr. or Jr. that needs to be included as well. So actually stating the real semantics behind the issue that you are trying to solve is important to solving that issue holistically. So escape the jargon, escape the programming talk if you can and talk about the problem as it exists in reality to some extent. Okay so number one was unsurprisingly state x instead of trying to solve through y. This is kind of the obvious solution state x with all of the semantics and all of the meaning behind it. Number two is explain your process up to this point. Explain how you got to what you are trying to do up to this point. It is likely at some point in your career as a programmer you will think that you are trying to describe the x problem and in fact you are describing the y problem and explaining where you are coming from the things that you have tried to do and explaining kind of your intention throughout the entire process that helps uncover where you are that helps the person who's trying to help you determine exactly what you're trying to do and perhaps give you a better solution than you are attempting to implement. For example let's say that you are trying to validate email addresses against a rejects. Now this is a very easy to solve problem because there's a multitude of information online about rejects and emails but let's say you come up against an edge case and it's causing problems for you and you go to a fellow programmer and you say I need you to help me come up with the right rejects to validate these emails. So that programmer should take a step back and look at what you are trying to solve. The reality of what you're trying to solve is that you don't want somebody signing up with a fake email. Now you could solve this with rejects but you could probably more accurately solve this by taking a step back and saying how can I make sure that this person is actually who they say they are and is actually behind this particular email address and once you look at the problem from that perspective then you can solve it in many different ways. Perhaps the most efficient way would be to send an email to that person and make them click a link in that email that validates that they received it. So in this scenario you were convinced that the X problem was I need to validate the format of an email but the reality was that you needed to validate that the email was real and these are two different problems. So avoiding the X, Y problem it really comes down to being more articulate and being more thorough with explaining the problem. We've brought this quote up before on the show it has been attributed to many different people but a well-defined problem is most of the way solved and if you can define the problem well enough so that other people can understand the full context and your intentions then you can avoid the X, Y problem. Thank you so much for listening to today's episode of Developer Tea. Thank you again to 1month.com if you are looking to learn how to code or if you're trying to start a business especially in the software industry and particularly if you want to learn J query go and check out 1month.com slash Developer Tea. They just launched their new J query course. If you use that link in the show notes you can get 25% off your first month on 1month.com go and check it out. Thank you again for listening to the show. I have two things for you before I go. 1. I want you to go to spec.fm of course you will have to go there for the show notes anyway but there are other podcasts that I want you to check out on spec and there is a ton of content that we are constantly putting out on spec so go and check it out spec.fm. 2. Please go and leave a review for this show on iTunes. It is so important for the longevity of the show that you leave reviews because it helps other people just like you find Developer Tea. Thank you so much for listening to today's episode and until next time enjoy your tea.