Strong opinions, weakly held

One thing I’ve learned about myself is that I have strong opinions when it comes to software development. I know I’m not alone. You’ll often see people turn up their nose at the thought of writing Java. Perl is mocked for being too hacky. Haskell is mocked for being too academic. Rubyists think Python is ugly and Pythonistas think Ruby is slow. Maybe it is our need for a sense of belonging that we create an us vs. them mentality around the tools we choose.

A good friend gave me some great career advice. “Have strong opinions, weakly held.” This took me a very long time to internalize. I first understood it as “occasionally allow people to make decisions you disagree with,” as if allowing others to be “right” from time to time was the definition of teamwork. I’ve since realized that it is much deeper than that.

What is a strong opinion? It is easy to misconstrue them for values or principles. Strong opinions are not fundamental truths that serve as the foundation of your decision making. An opinion is defined as “a view or judgement formed about something, not necessarily based on fact or knowledge.” So what makes them strong? Personally, I think a better term for this would be well-reasoned opinions. A strong opinion is one you are prepared to defend in a reasoned manner. You have some evidence, however anecdotal, that you are right.

So what about weakly held? This means that while you will defend your opinion, you will listen when someone has a contradictory opinion. It is important to be an empathetic listener and respect that the other person’s opinion is held just as strongly as yours. You should each be willing to understand the experiences that created the opinion. Sometimes by personal experimentation of their ideas, to try and empathize with them more.

Recently, I’ve run into a difference of opinion that caused some heartburn on my team. We were building out a new system using a microservice-based approach. Many of these services had some shared code for cross-cutting concerns such as database access, logging, etc. The application teams eventually agreed on using a monorepo to store all the projects, so the shared libraries can be easily updated in lockstep across all the services. This was in conflict with our platform teams that were building a system for deployment that used git repositories as the unit of building and deployment.

We had two conflicting opinions, monorepo vs many repos. Both had their merit. Both were right in some ways, wrong in others. It was largely a matter of perspective. As we discussed it between the teams, it was clear who was holding on to their opinions a little too strongly. To be fair, one of those people was me. We eventually settled on the monorepo approach, but it could have gone smoother.

I believe that in order to get better at anything, you need to practice. Letting go of my opinions is something that I want to get better at, so I’ve devised a way to practice. Like my first examples of opinions, there are certain programming languages I find objectionable. I realize my bias against them is not based upon facts of any kind. In the case of Go, the language that I’ve decided to learn next, it is based in my thinking that the language is ugly and the type system is flawed. These opinions are either superficial or based upon the experience of others. By building something non-trivial, I can form my own strong opinions and maybe I’ll like Go a little more. At the very least I will have a better understanding why others like it.

blog comments powered by Disqus