Originally posted in Linkedin. Photo by Alex on Unsplash

The natural human tendency toward polarization and the lack of reliable scientific data about methodologies, technical procedures, and tools can result in never-ending discussions and poor technical decisions.

If you're a software engineer, you’ve probably found yourself in one of those discussions that drive us all nuts. The debate could be over functional programming versus procedural, shared state versus stateless, tabs vs spaces, or whether you're doing TDD, or Scrum, or doing “the right way.™”

We all love passionate discussions about technology, and it's easy to argue in favor or against any of those topics with pros and cons. But the way we weight our arguments is rarely based on evidence—it’s often purely based on our own personal experiences or marvelous tales told by people or brands that we admire (“It was invented to solve the huge challenges in Facebook, so it should work for us too!” – we all said a few months before it ruined the entire web.)

Our opinions are very often not based on science. Nobody has run a serious study to measure how much a solid Haskell type system reduces the bug count compared to the lousy dynamic nature of Ruby (Disclaimer: I love both of those languages—this was just an example!), but we still love to argue about it anyway. Our opinions on those matters come basically from confirmation bias, the inherent tendency of all humans to interpret information in a way that strengthens their own convictions. This means that what you believe is likely influenced strongly by who your mentors were, what books you have read, and who you talk about tech with.

To make things worse, most of us usually hang out with groups that think alike, reinforcing our thoughts even more and making us tend to look for radical silver-bullet ideas: “If you don't do TDD correctly, you're not a developer”; “If you don't follow every point in scrum, you're not professional”; “If you still use classes, you're a dinosaur”; “We ALWAYS do this, so NEVER do it differently.”

The rate of “nevers” and “always” in a conversation about code could work as a perfect indicator of upcoming bad decisions.

This tendency is a well-studied social psychology phenomenon called group polarization, and, guess what: it's not doing anyone any favors. It makes us use the same tools or procedures for every situation, even when they are not applicable or it’s not the most practical approach. Being polarized and having extreme views on any topic in programming makes you a worse engineer, not a better one, but tragically, extremism is often confused with wisdom.

The Wikipedia page on software engineering reads /"Software engineering is the systematic application of engineering approaches to the development of software." The engineering page defines engineering as "the use of scientific principles to design and build machines, structures, and other items..."

So, where's the science in our day-to-day decisions? Are we really making decisions based on evidence, or is it just a mix of personal choices reinforced by the people around us? 

The truth is that nothing is black or white in programming because programming is complex and we’re all learning as we go. Most approaches, techniques, and technologies were created to solve a specific problem, or try to solve it in a better way. Take a look at any specific tool, and you’ll find that it was created to be the perfect tool to solve a particular problem under a particular set of conditions. Otherwise it wouldn't exist! But we cannot drive our decisions based on what we like or what we hate. We have to fight our natural biases and understand the real pros and cons of the tools and methodologies we use, especially the context (budget, team knowledge, disposability of the software, etc.), if we want to keep evolving as programmers.

Hate or rejection never helped anyone: they’re usually just an indicator of what you don’t understand. Trying something that you don't like very much tends to make it slightly more appealing and broaden your perspective, and even though you may never decide to use it in a real project, you might come to understand in which situations that language or methodology could actually be the right choice. It's OK to have favorites, but to really develop yourself, you have to stop hating and do your best, even when you're not in your comfort zone. Learn a new language, try to change something in your processes, listen to people you used to ignore (or vilify) and try to put yourself in their shoes — I can assure you that you will become better at what you do!

So, let’s keep discussing, even arguing about technology — that’s fine! There's definitely a certain amount of team bonding involved in slamming that brand we all love to hate, call it JavaScript, PHP, Monoliths or anything else, but the next time you’re arguing with a colleague around making a decision, don’t let the hate or rejection make it for you: try putting yourself in your colleague’s shoes and understand why they believe what they’re saying. Do the exercise of inverting the discourse, making yourself come up with a list of pros in addition to just cons. That could help you reach middle ground and find alternatives that you’d never thought about. That’s how you become a better software engineer, enriching your opinions with diverse ways of thinking.