One of my favorite operating principles is the idea of “strong opinions, loosely held”. There’s some controversy around this thinking so I’d like to share my perspective on it.
I believe strong opinions are a mark of a discerning engineer. If you are able to look at a problem statement with multiple solutions that are all correct but with different tradeoffs, are you able to pick one?
- If so, are you convinced it’s the best choice given the current set of information you have?
- How strongly do you feel that this is the best choice?
- How would you defend this choice when questioned about its relevance?
- Would you get defensive or be stubborn?
- How would your answer evolve in light of new information?
I’ve come at this from both sides - been the engineer that needed to make a decision and have managed a team where I assigned a task to an engineer and wanted them to make an informed decision.
When I am playing the role of a manager / lead, I don’t particularly care about the decision as long as you, the engineer, have invested enough time and research into the topic and feel convinced about the decision.
I feel like a lot of upper management (at least the good ones that don’t interfere with technical decision-making) is of the same thinking. They want to let the engineers pick the right tool for the job. Pick something, make sure you like what you picked and make sure you can articulate that decision clearly when questioned.
This kind of free rein, unfortunately, leads to some amount of bias. An engineer might be tempted to pick the solution they find dearest and choose that to be a hill they’ll die on. We’ve all been there and had these conversations over and over.
- React vs Vue
- Bamboo vs Jenkins
- Gitlab vs Github
A discerning engineer, however, would make the decision based on a set of constraints instead of personal choices. This makes it easy to enlist WHY a decision was made without blanket statements like “it makes sense” or “is perfectly fine”.
Were those constraints to evolve, you should be willing to reevaluate your decision. It is seldom the case that you make a decision 2 years back and those problems are exactly the same now.
I think “strong opinions” is a misunderstood term. It allows for a little bit of arrogance in the workplace. My understanding of strong opinion takes the form of:
Given these set of constraints, I strongly believe X is the right choice for us.
This allows you to explicitly state what constraints you are solving for and thereby allows for you to have a “loosely held” opinion. Since you are anchoring the decision based on a set of assumptions, if those underlying assumptions change, you can be open to changing your decision.
This segues well into the weather-man analogy - which is a great example for strong opinions, loosely held principle. As we all know, predicting weather, even with all the technological advancements we have, is pretty hard. However, when you watch the news, they give you a prediction with strong conviction.
They strongly believe there’s going to be 3 feet of snowfall within your county. But as the day progresses, and they receive more up to date information, they are perfectly willing to reevaluate and say the storm has crossed over without affecting your county. It’s the nature of the job to constantly reevaluate based on new information. No one gets pissed with the weather man for not predicting exactly ahead of time because it’s impossible. That’s the epitome of this principle is to constantly evaluate based on facts. However, this cannot apply directly to software decisions because software is all about tradeoffs. There’s opinion mixed with facts.
I do think it explains the idea well. If you picked a framework because “most of the team is familiar with it” - that’s a perfectly valid reason to make that decision. If “most of the team”, in the future, prefers a different framework, would you be willing to reevaluate the decision? Not wanting to switch is different from not wanting to reconsider. You could still argue that “although this seems to be the popular choice, the cost of switching at this stage is really high”. That would be an objective statement.
For example, a team I worked on picked Vue as the framework of choice for building a large scale e-commerce application. The decision was made before I joined the team but it appeared the reasons for picking Vue, at the time, were:
- Easy for backend engineers to pick up the templating compared to JSX
- Good for rapid prototyping and getting a proof of concept
- React learning curve is steep
Two years later, the team ramped up, hired a bunch of UI engineers - all with experience and desire to work in React. The team also had several open positions. This means, we are out of rapid prototyping and into a more sustainable app-development phase. There are a lot more UI engineers who have more experience with React. And, hiring for folks with experience in React was objectively, a lot easier.
This change in circumstances, invalidates all 3 assumptions made when the original framework was chosen. A good engineer, when faced with someone questioning the validity of this choice now, should be able to have a conversation and be open minded enough to see that those assumptions don’t hold now.
Instead, if you “strongly hold” your opinion that no matter what anyone says, the decision you made 2 years ago is still valid, that’s an adamantly held opinion.
One thing that would come up in this real-life scenario mentioned above was “Vue is closer to web components spec than React”. Which maybe true, but was not a driving factor for making the decision, so is irrelevant.
In conclusion, being a decision maker is a difficult position because you must also be able to articulate this decision when questioned without getting defensive or allowing your own implicit biases affect the decision making process. In reality, a lot of other factors come into play and it’s hard to remain objective when dealing with politics or entitled jerks.