Hey, everyone and welcome to Developer Tea. My name is Jonathan Cutrellan. In today's episode, we're talking about thinking in logic paths. Today's episode is brought to you by Spec.fm. Spec is the home of Developer Tea. If you're a designer or a developer and you're looking to level up in your career, go and check out Spec.fm. We have hundreds of hours of content, both written and audio content. So when check it out, Spec.fm, today's episode is also brought to you by Zendesk. Zendesk helps your users get the help they need directly in the application that you have created. We'll talk more about what Zendesk has to offer later on in today's episode. But first, I want to talk to you about logic paths. In today's episode, we're going to reduce all of your development questions, all of the bugs that you face, we're going to reduce all of them into their core idea. We're going to talk about logic paths today. And more fundamentally, we're going to talk about input and output. It should come to you as no surprise that all of development is a series of composing inputs and outputs. In other words, a function can take an input and it should return an output. A method takes an input and it may return an output. Now you may be saying, well, there are functions that don't take inputs and there are functions that actually don't return anything. They go and do something else. But I want you to think a little bit differently about inputs and outputs. We aren't talking about adding arguments to your function. We aren't talking about returning something from your method. We're talking about conceptually the idea of an input and an output. So we're going to unpack this idea of logic paths, the input, output, connection. And then I'm going to help you understand how to simplify your applications so that you can depend on your inputs and your outputs a little bit more. So let's talk about this a little bit further. All development is a series of composing inputs and outputs. These inputs can come from anywhere. The inputs can be the state of the system, the inputs could be the time that the particular script or the application is running during. The inputs can be an actual past input. The input may be a type of data. Maybe it's a single piece of data or maybe it's a list of data. Or perhaps the input is quite simply some kind of intent. In this particular script or run this particular program. And typically when we talk about input and output, the conversation of state ends up being talked about as well. And we're going to talk a little bit further about this later on in today's episode. But I want to go ahead and say that state is a different type of input. State is a type of input that is not explicit. You'll hear this discussion when people talk about pure functional programming versus object-oriented programming. And ultimately, all of these things have the same fundamental concept of input and output. It just so happens that they implement it differently. That's the input side. The output side is equally diverse. The output of a program may be a resulting state, the output of a program, maybe a message to you or a user or perhaps to a computer. And the simplicity of the discussion shouldn't hide the complexities of the reality. Of course, inputs and outputs are not always going to be immediately discernible if you're working with a sufficiently complex system. And almost all software problems, almost all bugs, come back to this idea of misunderstanding the input or misunderstanding the output. We're going to take a break and talk about today's sponsor Zendesk, speaking of software bugs. And then we're going to come back and talk about how to simplify your application so that you can control the inputs and outputs a little bit more explicitly and hopefully ultimately have more maintainable software. Today's episode is sponsored by Zendesk. Have you ever built a flawless app? Well, of course not. That's exactly what we're talking about today. We're always striving for perfection, but it's almost impossible to build a flawless app. You really need to discover the flaws in your application. And a lot of the time you ship flaws with your application that get discovered by your users. A flawless apps are really like flawless people. They only exist in theory, but I've never met one. And while we can be forgiving with our coworkers or our in-laws, flaws in your app can easily make or break your success or your clients' success unless you have the right safeguards in place. Now, in most of today's available apps, the user trying to get help is just a contact us link. Take them to a form or it launches an email by forcing people out of the app to get help. All problems can turn into big annoyances for users and may ultimately drive them away entirely. But with Zendesk, you can bring native in-app support to your app quickly and easily. Zendesk has an API and they have an out-of-the-box iOS UI to get up and running quickly. Users will ultimately be able to view help content and submit their own tickets to support without ever having to leave your app. So check it out, spec.fm slash Zendesk. Get your users the help they need inside of your application with Zendesk. That's spec.fm slash Zendesk. Thank you again to Zendesk for sponsoring Developer Tea. So we're talking about how to think in terms of a logic pass. We've already discussed how every application, every programming construct is a series of inputs and outputs. Whether it is explicitly set up that way or whether it's implicitly set up that way. Now we're going to talk about how to simplify your application so that these logic pass are a little bit more clear. Now if you are a fan of functional programming, then you will find a lot of this to kind of come intuitively to you. That's because functions have this concept very explicitly stated. It is with any given input that function will return the same output. You limit the side effects in this way. So a function does not exist that we go and grab information from outside of the function. All that the function needs to be able to execute correctly is defined by either passing it into the function or explicitly stating it within the function. What this ultimately means is that in functional programming, your inputs are visible. And that's my first recommendation for you today. Make your inputs visible. Make them explicit. You don't have to be a functional programmer for this to work out this way. Make your inputs visible and explicit. This way you aren't relying on state that's outside of your method or outside of your function. You're relying only on the things that are locally available in that code. So that's my first recommendation. Make your inputs explicit and visible. My second recommendation is to have a single source of truth. You know, a lot of craze has been surrounding, react, and a bunch of the JavaScript frameworks that have come out, but particularly react. The concept that react relies on is having a single data source that gets rendered throughout views and sub-views. This concept comes from an older methodology of rendering, which essentially says that once that top-level data structure has changed in any way, rerender the entire view structure as well. Now, I'm not telling you that you need to go and pick up react. Instead, what I'm saying is that the single source of truth, this idea that your application has a single data source or a single input source, is incredibly powerful. So if you only have one input source, then you don't have to go and find other input sources to add to the mix. This makes identifying what those inputs are much easier. So this crosses over with number one heavily, making your inputs explicit and visible. If you only have one input source, if you only have one source of truth, then those inputs are ultimately much more explicit and visible. My final recommendation to make your code more readable and to follow these logic paths more easily is to make any specific method or any specific function, any specific named routine that your code is performing, anything that takes an input and provides the output, make that change from the input to the output as small as possible. What this ultimately comes down to is instead of taking an input and doing 10 or 15 different transformations on that input or going and fetching some other secondary input to inform the way that you're going to change your first input and then returning something that looks nothing like the original input of that particular method. Instead of doing that, do each of those transformations in their own methods. What you will find is that each of these methods, each of these functions ultimately becomes much more readable and much more maintainable if you compose those individual functions together. If you've been listening to Developer Tea for very long at all, you know that one of the most powerful things you can do is make your application, make your code, make your methods, make your classes smaller. And this may mean that you ultimately end up with more lines of code for the same job. But I would argue and you will experience this, I would argue that that same code even though it is longer is far more readable, far more maintainable. And ultimately you're going to know the inputs and outputs in every single case. It's going to be much easier to read, much easier to reason about, much easier to maintain, much easier to test. There's so many benefits to breaking these things out into their own methods and ultimately knowing what those inputs and outputs are. Thank you so much for listening to Developer Tea. I hope today's episode was inspiring and equally challenging. Thank you again, of course, to spec. If you're a designer or developer and you're looking to level up, which I assume you are if you're listening to this show, then you should go and check out the hundreds of hours of content totally free to you. Go and check it out at spec.fm. All of the shows on spec, including Developer Tea, would not be possible without our incredible sponsors like today's sponsor, Zendesk. Zendesk allows you to put customer service as a native part of your application. Instead of throwing your customers off to some external web page or a contact form, you can allow them to see a native UI structure that gives them access to tickets. It allows them to create their own tickets. Go and check it out. spec.fm slash Zendesk. Thank you again to Zendesk for sponsoring today's episode. Thank you so much for listening to Developer Tea. If you're enjoying today's episode, and if you haven't subscribed yet, I highly recommend you go and subscribe as the best way to make sure you don't miss out on future episodes of Developer Tea. And it helps the show out. So subscribe and iTunes or whatever are the podcasting app you use. Thank you so much for listening to Developer Tea. And until next time, enjoy your tea.