What is the first thing you do when you're trying to solve a problem or discuss that potential solution with your teammates? Take a moment to think about your initial reaction. How do you respond to those situations? This will be highly contextual to you as a person, your personality, your experiences, your environment. All of these things will play into how you naturally respond. But in today's episode, I want to talk about two habits that successful software engineers employ when they face these situations. My name is Jonathan Cutrell and you're listening to Developer Tea. My goal in the show is to help driven developers find clarity, perspective, and purpose in their careers. We've been talking about the habits of successful software engineers on the show for the past couple of episodes aside from the interview that we had with Brian Helmick. In today's episode, we're going to continue this by talking about two habits that successful software engineers employ when they're facing a problem. It's not just a coding problem. This is any kind of problem that you're trying to solve as a team. The first habit that I want to talk about, we're going to approach this from the backwards perspective. We'll provide you the motivation habit. This is the habit that you can look at as the outcome or the goal. That is to get to the code as quickly as you can. Get to the code as quickly as you can. What does this mean? Well, it means that number one, you're not spending a bunch of time talking about things that ultimately are not going to affect whatever it is that you change. You can sub in a different word for code, but really what you're talking about is getting to some kind of implementation or some kind of proof of your processing. Whether that's a prototype or it could be a spreadsheet, it could be actual code. Maybe it's some kind of tool that you're trying to decide whether or not you're going to use it. The hope here is to get to the place where you're not just talking about the thing, but you're experiencing the thing, both by yourself and as a team. Notice that we're not saying get to the code immediately. That's because if you go to code too quickly, if you go to implementation too quickly, what you'll often find is that you make expensive mistakes that you could have avoided. Coding is expensive. Implementation is expensive. Doing it twice or three times or four times is often prohibitively expensive. Sometimes you end up outspending the value that you would have gained in the first place. This isn't always true. Sometimes we need to go through multiple prototypes, multiple iterations, but even in those cases, if you can cut down the number of iterations in half, for example, by doing some upfront thinking, then you're going to drastically improve both that iteration process and also the efficiency of what you're doing in the first place. But there is an optimum point of upfront discussion. You can think about this as a curve on a graph where you have lots of gain immediately. Think about this as a curve that starts out with a high slope and then slowly changes to a much shallower slope and perhaps it even goes downward. You may start out with a lot of value in the original discussion. The first discussion you have is infinitely more valuable than having any discussion at all. But the second discussion is slightly less valuable than the first one, the second opinion that you share. As you continue to share those opinions or continue to design and deliberate upfront, each iteration on that design and deliberation becomes less and less valuable. All the while, the learning that you would experience by actually implementing becomes more and more valuable. You have to find where that graph crosses. This isn't an easy thing to do. That's the spoiler alert. This is hard. This is one of the most important skills that developers learn over the course of their career because this is actually a business skill. This has less to do with whether you can write good code or come up with a clever solution and more to do with, can you do it with the most efficient approach? Again, when we talk about efficiency on the show, we're not talking about squeezing every single perfect productivity out of every single minute of your time. Instead, we're talking about using resources in a way that provides the return that you're looking for. It's as simple as that. Doing enough upfront thinking, enough research, that's important before you get to the code. But once you get to the code, you begin to learn more. Once you get to implementation, you learn much more. And imagining that you're going to get it all right on the first implementation is arguably 100% likely to let you down. So what is another habit that we can employ during that upfront design process that will help us get to where we want to go so we can get to implementation as quickly as possible? That's what we're going to talk about right after we talk about today's sponsor, Century. If you have ever had a customer tell you that your code is broken. You know the feeling of panic that you have and also a feeling of frustration. And customers don't really know why something is broken and they provide you with limited information. If you don't have eyes on their side of the fence, then you're kind of treating them as a Q-18 and they're not going to be very good at that. Also you're not paying them for that. They're probably going to leave. And by the time you've had one customer report the problem, who knows how many customers have actually experienced the problem? You probably actually have no way of finding that out. And unfortunately it's probably impacted your business by that point as well. Now I know what you're probably thinking. If I've experienced this kind of problem that impacts my business, then I probably didn't write the test that I should have written. And that may be true in some cases. But we can't cover every scenario with a test. Even the best developers with decades of experience still have bugs, sometimes really big bugs that bring down the entire system. So it's really hard to write perfect test coverage, perhaps even impossible. And in reality humans are really bad at not only writing tests, but expecting what a user is going to do. We can't really predict that very well. So predicting their inputs is not a very good use of our time because we're probably not going to get all of them right. So we need a multi-tiered strategy to figure out how to find bugs in our code. Not just tests, certainly you should be writing tests, but also you need a system like Century. Century provides you with all of the information you need to find out what's going on in your software in production. This is going to help you find bugs before your users do and ultimately help save your business from being impacted from those bugs as well. You get the full stack trace, you get the commit, and even the developer who wrote the code that is responsible for that bug so you can get it resolved as quickly as possible. Go and check out what Century has to offer. Head over to sentry.io to get started today, that's sentry.io. Thanks again to Century for sponsoring today's episode of Developer Tea. So the first habit of successful software engineers in today's episode is to get to the implementation as quickly as possible, get to the code as quickly as possible with the goal of learning through iteration. Now the second habit is going to be in that phase between now and the implementation in that quickly as possible phase. How can you make that happen? We've already discussed some of these ideas that you can't just jump straight into the code but you shouldn't deliberate for a long time either. So one of the most important things you can do, develop the habit of thinking in models, thinking in models. What does this mean? Well I'll give you an example. Earlier we talked about thinking about a graph with a very high slope at the beginning and then a shallow slope, perhaps a slope that goes down towards the end of the graph, towards the right side of the graph as x increases, y decreases. With the idea that x is the number of deliberations or opinions that you share, the amount of design up front that you do and y would be the value that that provides. If you can think about those relationships, that is a type of model, right? You're thinking in terms of how do these things work together and how can I explain them in a way that is comprehensive. That's one kind of model. You can think about models as a way of explaining an idea. Another example of this is the mental models that we talked about on the show before. We've probably heard about these outside of this podcast. In other podcasts, Charlie Munger is amongst the most famous for talking about mental models. The idea here is that there are many different systems that exist in the world outside of development and in software development that you can take advantage of. That certain types of information kind of wrap around. For example, if you have event-based programming, the model that you would be thinking of is a sender, some kind of sending object or sending a player in the game that sends a message. They may send it into an open space where a receiver can listen for that message and then do something about it. There may also be receivers. This concept doesn't necessarily express itself in code directly, but you can use this concept and wrap a bunch of different types of problems around it. Once you've learned these different models or paradigms, you can develop the skill of cycling through them when you're faced with a problem. To see if your problem can fit one of those paradigms, one of those models. The hope is that these models will kind of explain to you how different things will interact given that model implementation. You can have the concept of a message sending to a receiver and the semantics around that help you solve the problem in a unique way. In other words, imagine what does a message look like? What does a sender look like and what does a receiver look like? If you can use the model to help kind of prop up and provide to you a structure, kind of a predetermined structure for the way that you're thinking, when you have multiple shapes, multiple models to choose from, a lot of the time those structures are going to help you solve your problem in a much more efficient way. Rather than trying to solve it from the ground up without any structure, without any models, you can rely on these proven models, these interactive landscapes to help you solve problems more efficiently. I encourage you to seek out these different types of mental models, programming paradigms. These are all different shapes, ways, programming patterns, and not just programming, but these things apply to soft skills problems, people problems, organizational problems. These are very similar to imagine like data structures, but at a meta level. This is something that will totally change your career for the better. Thank you so much for listening to today's episode. Thank you again to today's sponsor, Cintry, at over to Cintry.io to get started with your multi-tiered solution to dealing with problems and bugs in your code. Thank you so much for listening. If you haven't yet subscribed to this podcast, I encourage you before this episode finishes. Click the button, I'll give you a second. Click the subscribe button and whatever podcasting app you're currently listening with. Lastly, a quick reminder. If you haven't subscribed to Tebrake Challenge, these are daily soft skills challenges that get sent directly to your email, head over to tebrakechallenge.com. This is totally free, enter your email there and you'll get a challenge each day. Usually it's an insight to ponder something that will take you just a few minutes to read. Thank you so much for listening and until next time, enjoy your tea.