The stereotype that developers are highly opinionated.
In today's episode, we're talking about being highly opinionated as a developer. We'll talk about resolving opinion differences between developers in a positive way.
If you have questions about today's episode, want to start a conversation about today's topic or just want to let us know if you found this episode valuable I encourage you to join the conversation or start your own on our community platform Spectrum.chat/specfm/developer-tea
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/.
Our sponsor GitPrime published a free book - 20 Patterns to Watch for Engineering Teams - based data from thousands of enterprise engineering teams. It’s an excellent field guide to help debug your development with data.
Go to GitPrime.com/20Patterns to download the book and get a printed copy mailed to you - for free. Check it out at GitPrime.com/20Patterns.
One of the stereotypes that developers have earned over the years is the stereotype of being highly opinionated. Whether it's about a specific technology or even the way to solve a particular problem, it seems pretty common that developers have very strong opinions and that you can have two very smart developers who disagree with each other on a regular basis. This is true in other industries, certainly designers disagree with each other, but one of the most interesting parts of this being a common problem amongst developers is that developers often have some kind of relatively objective goal in mind. In today's episode, we're going to talk about how to resolve those differences in a smarter way. If you've listened to this show for very long at all, you know that this is going to start with you in your own perspective. My name is Jonathan Cutrell and I'm listening to Developer Tea and my goal on this show is to help driven developers find clarity, perspective, and purpose in their careers. Every problem you face as developer is different. Even the problems that you feel like are the same. The problems where you can take some code that you wrote before and apply it without even really changing anything. The reality is that the problem that you're facing is different. And it's not that the particulars of the problem are different, but rather that the environment around you has changed. The market has changed. Time has gone forward. So other solutions have arisen in the meantime. This is one reason why applications that you develop, even applications that are never going to change as far as the features go, they still need to be maintained because it's not just the application itself that's running. There are other things about the world surrounding that application that you have to keep in mind. This idea of having rotting code is different from something like technical debt. And let's talk about that for a minute. Code that has gone rotten didn't necessarily start out that way. Even code that is written with the future in mind can eventually go rotten. On the other hand, when you choose to take on technical debt, it's usually to make ends meet. In the same way that you might take on financial debt, taking on technical debt is done as a stop cap. It's choosing a less than ideal path, accepting that you very well may have some negative ramifications in the future and hopefully making a plan to address that technical debt as soon as practical. So why does this matter as it relates to being an opinionated developer and how you can resolve those differences in opinion? Well, what this means is that you can have a code base that was written idiomatically. In other words, it was written in the proper way the day that it was written. And you can have another code base that was written quite the opposite. It is full of technical debt. The first code base, the one that was written right the first time, has begun to rot. And the second code base, well, you're not really experiencing the issues of technical debt yet. So you end up in a scenario where the good code has gone bad and the bad code is sufficient. Now, I want to be very clear. We're not saying that everything is relative. It doesn't matter and that you shouldn't care about quality in your code. However, what I am saying is that the lines aren't as clearly drawn as maybe we want them to be. We're going to take a quick sponsor break and then we're going to come back and talk about why we try to shove our code into these kind of good and bad labels and how we can change the way we think about problems at a fundamental level to shift the way that we argue about code. Today's episode is sponsored by Git Prime. Great managers are good at debugging, not just code, but they can look at their teams and debug the problems that are causing those teams to be less than effective. And debugging is all about understanding how those issues arise, what they look like. You're not going to run into the same exact problem twice. Most of the time you're going to run into similar problems and you'll use the kind of human superpower of pattern matching, understanding that this problem is like that problem. So how do you know what those patterns are? Git Prime has compiled 20 patterns for effective software engineering teams. And they've produced a beautiful book that explains these 20 patterns. Now these are not all anti-patterns. They're not all problems. Some of these are the ways that you should organize your team. You can get the book for free and you'll get a printed copy sent to you. So you're going to getprime.com, slash 20 patterns, that's Git Prime, GIT Prime.com, slash 20 patterns. Thanks so much to Git Prime for sponsoring today's episode. If you've ever found yourself in the middle of an argument with another developer and it seems like neither side is budging, it's very possible, if not likely, that you both have the same goals in mind. And that is actually the first step towards getting on the same page with that developer. Try to walk back what your actual goals are. If you find differences in your goals, then address that problem first. For example, you may have an implicit goal that your code is maintainable into the future. And the developer that you're working with may not necessarily have that same goal. So getting on the same page about your goals or finding the overlap, that is kind of step one. If you have a difference in goals, then you need to understand your shared purpose. What is the purpose of the work that you're doing together? But the next piece of the puzzle is more about you understanding your own perspective. The reality of most problems is that they are not symmetrical with other problems. In other words, you may have a tool set that solves, let's say, styling in your application on the client side. And so you use this tool as kind of a default. But you may run into a scenario where that tool quite simply doesn't fit the problem that you're facing. This can be for any number of reasons. It may be a dependency problem or maybe it's a problem with the other people that you're working with not knowing that tool yet. And it being too costly for them to learn it. However the reason is, you have two problems, the ones that you've solved in the past with this tool and the new one that's in front of you. And very often, those problems have a high level of asymmetry. You can kind of visualize this as a three dimensional graph. And in reality, you're going to have more than three dimensions, but it's easier to visualize if we just assigned three. And each of those dimensions is some kind of feature of that problem. In other words, the team, the people working on it may be one dimension, the longevity of that code, maybe another dimension. And then the, let's say, performance of that code is another dimension. As you can immediately see, there's going to be a lot more than three. But if you were to plot these out and put that problem in some 3D space and then compare it to another problem, you'll see that they're in different places. And so when we choose our tooling or when we choose an approach, it needs to be tailored to the features of the problem. Instead, what we often do is we tailor the problem to the features of our opinions. Think about that for a minute. You try to shape the problem to the tool that you like, that you're familiar with, that you enjoy using or that you have some affinity to for some other reason. You shape the problem to the tool rather than choosing the tool that shapes to the problem. Now, of course, this means that if you can have a tool that is flexible, in other words, it covers a large space in that 3D graph that we just mentioned a minute ago. If you can have a tool that can address problems in a larger problem space, then you're much more likely to be able to use that tool even if the problems are asymmetrical from each other. Frameworks, for example, are generally designed to solve problems that cover a broad range of characteristics. But it's important to recognize that not all frameworks cover the full space. Now, it may sound like I am proposing that you always pick the perfect tool for the job, but that leaves out an important factor, and that is you. Now we shouldn't tailor the problem to ourselves, but we can't discount ourselves as a factor in the decision making process. If you're going to be significantly more productive with one tool versus another, and even if that tool is slightly less suited to the problem space, you're more likely to be successful with the one that you are more productive with if it is roughly capable of doing what you're trying to do. But here's what you shouldn't do. You shouldn't try to change the problem so that it fits that tool. Instead, you should know the limitations of your tools. Know the drawbacks, and try to find ways to supplement. If you choose a tool because you're going to be productive in it, but you know it has a drawback, consider ways that you can address the drawback. Can you compose multiple tools, or perhaps you can work with another person and have them compose their ideas and their tooling with you? Most of the time these conflicts that we have with other developers are solved by getting on the same page about our goals, and by understanding that every problem is different and applying rules across the board only leads to dogma. And the more rigid and the more dogmatic you are, the more conflict you'll have with other engineers, and the less efficient you'll be with the energy that you spend. Thank you so much for listening to today's episode of Developer Tea. I hope that this was both challenging and encouraging. Another huge thank you to Get Prime for sponsoring today's episode. You can get the book, 20 patterns to watch for in engineering teams by heading to getprime.com. That's g-i-t-p-r-i-m-e.com slash 20 patterns. That's the number two zero patterns. Get Prime.com slash 20 patterns. You can get a printed copy, mail to you for free. Thank you so much for listening to today's episode. If you enjoyed the episode, I encourage you to subscribe in whatever podcasting app you use. This is the best way to keep up with the episodes of Developer Tea and to be notified whenever we release a new one. Developer Tea is a part of the spec network. Head over to spec.fm to hear more shows that are tailored to designers and developers who are looking to level up in their careers. Here at Jackson is today's producer, my name is Jonathan Contreul. Till next time, enjoy your tea.