Earlier this year in March we did a series called Habits of Successful Software Engineers. I encourage you to go back and listen to those episodes. We talked about seeking feedback, clarity, brevity, context, getting to code quickly, and a lot of thinking it was a good, but quick dive into some of the skills that make a great software engineer a successful software engineer. In today's episode we're going to talk about another one of those skills. It's a little bit of a nuanced skill. So if you already are a successful software engineer, this might be something that you can still pick up and learn from. My name is Jonathan Cutrell and I'm listening to Developer Tea. My goal on the show is to help driven developers like you find clarity, perspective, and purpose in their careers. Most of what we do as developers is solve problems. This might sound a little bit kitschy or like a sound bite, but the truth is, every day as developers we face something that is either done wrong or isn't done yet. Of course, we should mention, as always, that context is important when we say that something is done wrong, that doesn't necessarily mean that it's broken. And when we say that something isn't done yet, we don't mean that nobody is addressing the same problem. But instead we mean that for our context, this problem has not been addressed yet. But if this is such a major part of what we do as developers, then it seems like we're underserving the skill of problem solving that we might benefit from exploring how we solve problems a little bit more deeply. Successful software engineers multiply value when they solve problems, while less successful software engineers only add value when they solve problems. We're going to talk about this nuanced difference because it often feels quite similar. But we're going to get very specific in today's episode and how a successful software engineer goes about multiplying value rather than simply adding value. But first, let's talk about what it means to have multiplied value. First, we have to think of the unit of value that we're talking about in the first place. We're not going to try to define value in today's episode. That would take maybe a whole podcast to figure that out. But instead, let's imagine that we know a particular type of value that we want to increase. Now, it's probably unlikely that successful software engineers have the power to multiply every single value in every problem that they ever solve. But instead, they should be thinking in ways that are multipliers rather than simply adding. So let's imagine that the value that we add by solving this particular problem, reducing the end user's time to value. This is the amount of time that it takes for someone to go from the starting point, whatever the start of that process or feature is to actually getting value from that process or feature. A successful software engineer is going to look at the time to value problem more broadly rather than simply tactically. In other words, are there ways that we can improve the time to value for this feature, not just by solving this particular interface area, but instead by considering the broader problem space. What exactly is this user doing when they start using this feature? Can we decrease the time to value before they begin using this particular feature? Or can we increase the total value provided by this feature? So a successful software engineer not only expands on the value that's created in a particular feature, but they can also look at parallel values that they can increase in the process of building this feature. For example, a great front end engineer might look at ways to make the interface a little bit faster for this particular area, this feature, but they may simultaneously make adjustments that improve accessibility. Accessibility and time to value are probably overlapped in most applications, finding these overlaps and parallel options, parallel ways of creating value. That's what a successful software engineer does. We're going to take a quick sponsor break and then we're going to come back and talk about another way you might increase value in a given scenario, and then more broadly, kind of the mindset that's required to think multiplicatively. Today's episode is sponsored by Flatiron School. At Flatiron School, you learn how the future is being built so you can change anything, starting with a new career in user experience or in UI design, no matter where you are in your career. Flatiron School can help you level up in your creative skills in just 24 weeks, either at one of the global WeWork campuses or from anywhere online, you can change your career with confidence. Flatiron Schools instructors have both industry and teaching experience and are backed by Flatiron Schools master teachers and learning experience designers to ensure you get the best possible support. You'll also have one-on-one support from your dedicated career coach and a money-back guarantee. You can find out more details at flydironschool.com slash terms. You can join the global community of change makers at flydironschool.com slash Developer Tea. That's flydironschool.com slash Developer Tea. Thanks again to Flatiron School for sponsoring today's episode of Developer Tea. So you want to become a successful engineer, that's why you're listening to this episode. And more specifically, you want to learn how to multiply value rather than simply adding value. Now I want to be clear that this is not the same discussion that you've probably seen online about TNX engineers. We talked about that on other episodes of this show. The idea of a TNX engineer is totally oversimplified in terms of how that value is delivered. Typically, TNX engineer delivers TNX the amount of code. And we're talking about more than that in this episode. Successful software engineers think about the value that they add to an organization as compounding, not simply being 5X or TNX better than the next engineer that comes along, but instead lifting the whole organization up with you. The simple kind of tactical example of this is no matter what problem you're solving, especially if it is somewhat of a new problem, someone unique to the organization that you work with, documentation can be a simple way to multiply the value that you're adding through that process. So here is the mindset to have as a successful engineer. You want to be thinking in terms of system effects. And when I say system effects, I mean thinking about the work that you're getting ready to perform in terms of the systems that that work belongs to. So an interface issue, let's say there's a visual bug in an application that you're working on. What systems is this work a part of? One of the most obvious systems is the system of other engineers on the team. As we just mentioned, providing documentation for particular fixes that you make is crucial to multiplying value. What other systems might a front end visual bug belong to? Well, you might think about the combination of teams. So from designers to engineers or engineers to a QA team, if that's something that your team has as participants, these are these overlaps. They might benefit from some kind of work as well. You also have systems that are actually entirely encapsulated by whatever products you're working on. So in this case, the front end system at a very practical level, if you are writing new CSS, for example, as a front end developer, for every single bug that you find, then you're probably having a negative effect on the front end system, even though you're adding value by fixing the bug for that particular problem. So the question that you can ask yourself during this kind of work is what else is affected by this work and what may have caused this to begin with? These questions often lead you to higher level understandings of the systems that are at play. Once you can do work that benefits the systems, now you are multiplying value. You can fix the individual problem and improve systems, sometimes with the same amount of energy or with a very high leverage amount of extra energy. In other words, a small amount of energy that goes a much longer way. I encourage you, as you are solving problems in your work today, as you solve problems in your work tomorrow, start thinking about the systems that are surrounding those problems. Thank you so much for listening to today's episode of Developer Tea. Of course, today's episode would not be possible without our wonderful sponsor, Flatiron School. You can join the global community of change makers at FlatironSchool.com slash Developer Tea. That's FlatironSchool.com slash Developer Tea. Today's episode was produced by Sarah Jackson. My name is Jonathan Cutrell, and until next time, enjoy your tea.