In today's episode we're talking about the idea of interfaces as some kind of expected way to interact with our code and how to take that frame of mind to our day-to-day lives.
Being explicit about what we need to make our days successful can be rare but it might make sense to imagine each day as it's own function and the outputs that you want for each day. What kind of outputs do you want to happen today and what do you need to make that possible?
If you're enjoying the show and want to support the content head over to iTunes and leave a review! It helps other developers discover the show and keep us focused on what matters to you.
This is a daily challenge designed help you become more self-aware and be a better developer so you can have a positive impact on the people around you. Check it out and give it a try at https://www.teabreakchallenge.com/.
Transcript (Generated by OpenAI Whisper)
What are the outcomes that you are expecting in your day-to-day life? This is the question we're going to be talking about in today's episode. My name is Jonathan Cutrell and you're listening to Developer Tea and my goal on the show is to help driven developers like you find clarity, perspective, and purpose in their careers. A lot of the time on this show, we talk about mental models or metaphors, ways of thinking outside of code that apply to the way that we construct software. But in today's episode, we're going to take things kind of the opposite direction. We're going to talk about this idea of interfaces, some kind of expected way of interacting with a piece of code, whether it's a class or maybe it's a definition of a function. We can think about interfaces as what we expect. We can consume code then in a way that doesn't really care about the internals, doesn't care about the implementation details, it really only cares about the contract that is signed with that piece of code, the interface. Of course, we can talk about having a public interface and then a private interface or public functions and private functions. Some of this may be a little bit foreign to you depending on what you're programming background as. But suffices to say that these are all concepts that you can apply in code that allow you to encapsulate some kind of process. And the output of that process and the input, the inputs to that process, if there are any, can be well documented. This is how you can have things like an API and documentation because you have some reliable interface. But very often in our lives, when we structure our days, when we structure our activities, we don't think about it in a similarly structured fashion. Instead, much of our lives are unstructured. We don't have specific outputs that we're looking for. We don't consider specific inputs we might need to be able to accomplish whatever it is that we need to accomplish. For example, that's imagine that you are packing for a trip. It makes sense for you to identify what inputs do you really need for this particular trip to make it successful. And most people do this explicitly. They'll list out the things that they need based on the number of days that they're gone. And sometimes they'll forget something. They take note of it and in the future, when they're packing, because of the pain they experience, they might have a better recollection or a better heuristic for what to pack this time. But being explicit about what we're packing or explicit about what we need to make this particular event successful, it's kind of rare. And most of the time, we don't really need to write down a list of everything we need to make our afternoon hanging out at our house successful. That seems like overkill. But it might make sense to imagine each day as its own function. And imagine the kinds of outputs that you want from today. And the kinds of things that you might need as inputs. And it might not just be for today. You might look weak in advance or a month or a year in advance. Because some of the inputs that you have for today might be inputs for things that you care about for outputs that you care about that you won't have for a long time. But the inputs are necessary to even get the ball rolling. And some of the outputs that you have from today will carry forward as inputs to another process. Now if you're like me, you're listening to this and I'm even listening to myself saying it, thinking, wow, this is kind of obvious, right? We should, of course, we should think about our outputs from one day as inputs to the next day. But very often we don't meet our own goals because we don't take the time to think about the input and output. Instead we just mindlessly run the same functions. Time passes by and the outputs that we're striving after we never really achieve because we didn't identify the necessary inputs. And we may be surprised by outputs that we didn't necessarily specify. So here's how I recommend you think about this, a way of practicing this. If you're looking for a particular output, imagine what might create that output? Can you be explicit about this specific thing? Or is this something that you kind of want to optimize for over time that you have a never ending kind of soft requirement for this output? Once again, since we're using a metaphor, there might be something like a recurring job, right? A recurring crunch job, if you want to call it that. These are processes that you know are good for you, even though you don't have a necessarily specific output that you're looking for. And so you might set those up and you might review them on a regular basis. These are called habits. If we have a recurring habit over time that produces some kinds of positive outputs, even though they don't necessarily produce the same output each time we do them, those habits can have a major effect on our lives. And so we might set up a habit initially because it produces some positive effect, but over time that positive effect may change because our environment changes or our bodies change, our team situation might change or family situation might change relationships. And so it makes sense to review those habits. It makes sense to review those cron jobs that we set up for ourselves. Additionally, doing mindless things or assuming that our normal everyday patterns, not just our habits, but the tasks that we take on or the attitudes that we present in a given meeting, assuming that they're going to produce the outcomes that we want, assumes that we have decided what those outcomes are and that we have kind of optimized all of those activities and we already have an implicit input system. So backing out once again, imagine this for starting at one day. What kind of outputs do you want from today? If you can define this a day in advance or even early in the morning, define the kind of outputs that you hope for from today. And of course, you need to bound this, right? You can't imagine that today you want an output that you can't achieve today. But imagine a single output that you know you can achieve. And what do you need to make that possible? Working backwards from this solution helps you prioritize and it helps you understand what inputs and specifically how your time will input towards the outputs that you care about. Thank you so much for listening to today's episode of Developer Tea. Of course, we didn't have a sponsor for today's episode, but in lieu of a sponsor and lieu of supporting us by visiting that sponsor, I'd love for you to take a moment to share this episode with someone that you think it will have a positive impact on. Thank you so much for listening today's episode, like every other episode of Developer Tea, can be found at spec.fm. Today's episode was produced by Sarah Jackson. My name is Jonathan Cutrell and until next time, enjoy your tea.