Over the years, I've encountered various kinds of people. We didn't always share the same opinion on how to solve problems in code. At the moment, generalizing quite a bit, I can distinguish two types of problems: those that help you grow, and those that need to be resolved as quickly as possible without making too many enemies along the way.

First, I'd like to talk about what I mean by problems that help you grow. What comes to mind is a longtime colleague of mine, who, like me, started his first job at the same company at the same time. To be honest, our knowledge was pretty close to zero. But over time, I noticed that our joint debates about solutions in code, or using and discovering new frameworks, gave us a real boost in terms of how fast we learned. It didn't happen without some senior mediators who sometimes had to step in. Those were very productive times. At some point something clicked in my head, and instead of trickling in like a small stream, knowledge started flowing like a waterfall! Neither of us could have gotten there alone. Even though we don't work together anymore, other friends and I still look back on that period with nostalgia — full of debates and the surprise of seeing something finally work the way we intended.

The second type of conflict within a team is, unfortunately, the kind where both sides can't reach an agreement. Nothing comes out of it. People don't learn from their mistakes, or maybe they don't want to learn about a newer approach or way of solving something. Most often this comes down to a person's lack of knowledge combined with laziness. Some people just want to get their part done and go home. That wouldn't be a problem if the other side didn't foresee dangers looming in the future with that solution. Code should be resilient to whatever might come. Of course, you can't predict everything, but to give some simple examples: not validating data coming from another system, or blindly trusting that, say, the number of items in a returned list will never change — those are unacceptable situations. As long as we don't have control over other systems ourselves, we have to assume that the data can change at any moment. In that case, we should return an appropriate message and gracefully halt the process. Blaming another team — "because they weren't supposed to change anything there, it works on our end as we agreed" — is a very weak excuse. In such cases, you need to go straight to the people responsible for quality and nip the problem in the bud right away. You can't take shortcuts.