What do your systems empower? That's the question that we're going to be discussing on today's episode. My name is Jonathan Cutrell and you're listening to Developer Tea. My goal on the show is to help driven developers like you connect to your career purpose so you can do better work and have a positive influence on the people around you. And in today's episode, we are talking about systems. So real quick, what is a system? A system is a consistent way of doing something. Bonus points, if you can share a system. A system is kind of like a boundary or perhaps a procedural way of performing or operating. Systems are not always perfectly prescribed. For example, systems may have high levels of tolerance. A simple example of a pretty high tolerance system would be speed limits. Speed limits basically set for one upper bound and that's it. Sometimes on the highway you'll see a minimum speed but for the most part, speed limits are not prescribing a specific speed that you must go. Instead, they're putting some limit. And so you can think about systems as having a high level of prescription or a very low level of prescription. More like boundaries, guidelines, ways of raining something in that otherwise would have been erratic or out of bounds. And in today's episode, I want to discuss two different ways that we can employ systems to achieve various goals that we may have. And the way that you choose to employ systems may look like one of these two ways and may look entirely different. It may be a combination of these two conceptual approaches. But I think this is important to understand because we make decisions as developers every day. Very rarely when you're in the middle of your work, are you making a decision about which tool to use? This is a very common problem that we talk about on this podcast, what language, what framework. Instead, most of the time you're making decisions about how far you should go. How far should I go with this particular tool or this interaction? How far should I go with test coverage or to what degree of perfection do I need to follow this particular pattern? And these questions very often rely on systems. Sometimes you have systems that you have created without knowing it, kind of implicit systems. And then you have explicit systems. In today's episode, we're mostly focusing on explicit systems, although implicit systems are an exciting topic that we might talk about in a future episode, maybe even the next episode. So we're going to talk about two ways that you can set up explicit systems to support your goals. But before we do that, I want to talk about today's sponsor, Digital Ocean. Speaking of systems and boundaries, Digital Ocean provides a different system for pricing than some of the other cloud platforms you may have used. Pricing with Digital Ocean is predictable and affordable. You can leave complex pricing structures behind and you'll always know what your business is going to pay on a per month basis. And Digital Ocean also has the leading price to performance ratio and a flat pricing structure across all of their global data center regions. You can get started with a $100 credit. That's $100 for free by heading over to do.co slash tea. That's do is in digital ocean dot c o slash t. Thank you again to Digital Ocean for sponsoring today's episode of Developer Tea. Go and check out what Digital Ocean has to offer. So we're talking about systems today. And specifically, we're talking about explicit systems. These are systems that you define. You explicitly define them. You do this on purpose. Intentionally defined systems is another way to think about this. And there's two approaches that I want to talk about for designing explicit systems to support your goals. The first approach is to design systems to mitigate the things you care less about. So think about this for a second. Designed systems that essentially handle the things that you don't care very much about. This is something that we all do, or at least most of us, anybody who's using an abstracted language, which is pretty much all programmers these days, you are relying on an abstracted language to take care of things that you care a little bit less about. And in fact, any abstraction is a system that has been explicitly defined to abstract away details that are ultimately unimportant to the person who's using that abstracted system. So an indicative phrase for abstracted systems or for systems that take care of things that you don't care very much about is if you actually say the words, I don't really care about that. In fact, if you talk to most library maintainers and even if you talk to software developers who have worked on sufficiently large projects where code bases were shared and there were interfaces between those code bases, things like, for example, private methods, these are systems that are internalized to a given class, for example. And very often it's because the outside world doesn't really care to interface with those internals of that class. Of course there are other reasons you might use private methods. And we're not going to get into the nuance details of those reasons. But you'll notice that we're not saying that these things are unimportant. We're not saying that no one cares about those details. Instead we're saying there are other things that I want to kind of promote as more important. And I'm willing to take the systems answer to this problem. What we get in these scenarios is a trade-off. The system provides us some level of abstracted kind of energy savings. We don't have to go and implement every little tiny detail because the system can handle some of those things. The abstraction can handle some of those things. And it gives us in freedom of time is worth whatever we lose when it comes to customization or perfection of efficiency, for example. So that's the first way that you might use a system to abstract away the things that you don't care about, to take care of those details that you care less about. The second way that you may use an explicit system, a defined system, is to actually support the things you do care about. Now, in this case, we're not talking as much about abstractions, although there is a good case to be made for using an abstraction for things that you care very much about. Instead, what we're talking about here is using a system that provides boundaries. For example, a checklist. This is a very simple example of a system that you may use for things that you care very much about. In these scenarios, the system is less about abstracting away the detail and it's more about mitigating the risks of human interactions. Things like checklists are a good example, but other examples of explicit systems are regression tests. Even though this seems like a common practice, kind of a part of your development, regression tests are in fact a system, a systematic way of approaching the verification process. These kinds of systems mitigate risks and limitations that are imposed by human error. When you have a system that is created to avoid error and it's created painstakingly, there are checks and maybe even double checks and triple checks to ensure that whatever the thing is that you care about is taken care of properly. Again, this is the second way that explicit systems can be used to help you achieve your goals. It's very likely that you are going to use systems in both scenarios. We've talked about two very simple scenarios, languages, abstracted languages on top of machine code as well as regression tests. Most people who are listening to the show are probably familiar with both of these systems, but it can be very empowering when you think explicitly about what the system is protecting or mitigating. Why am I using this system? Is it too free up extra time or is it to provide some mitigation of risk? Is it to empower something or is it to protect something? Of course this doesn't cover the nuances of every single system, but these are two ways that you can use systems to better control and better empower the work that you do. Thank you so much for listening to today's episode of Developer Tea. I hope you enjoyed it and I hope that you walked away feeling more empowered and a little bit more connected to the work that you do as a result of this episode. If you haven't subscribed, go ahead and subscribe in whatever podcasting app you use before this episode is over. That will ensure that you don't miss out on future episodes of Developer Tea. Thank you again to Digital Ocean for sponsoring today's episode. Digital Ocean is giving developers who are listening to this show $100 worth of credit. It's $100 for free just by going to DO.co slash T that's DO is in Digital Ocean.co slash TEA. Thank you again to Digital Ocean. And thank you so much for listening to today's episode and until next time, enjoy your tea.