The Value of Having “No Strong Opinion” in Software Engineering

Having opinions in software engineering is important. Opinions about technology, design, use-cases, and implementation details have a significant impact on the end product. Many subjective decisions must be made to build the thing you want to build.

Newer engineers tend to not (and, probably should not), have strong opinions. As they are exposed to more designs, face consequences of prior decisions, and have their implementations critically assessed by their seniors, opinions begin to take shape and develop.

Conscious or not, your design documents, architecture diagrams, coding conventions, technology stack choices, and new product initiatives are influenced by your opinions.

When a particular comment on your code review irks you, it may be an internal opinion of yours making you feel defensive.

Ideally these opinions are data driven and have substantial evidence to support them, but at the end of the day, they are opinions.

As your career progresses, it is expected that you develop more opinions, which should ideally grow stronger, more nuanced, and increasingly ‘correct.’ This is why many organizations generally require an engineer of more seniority to assist and finally sign-off on the designs of those with less seniority.

No one ever became a staff level engineer by not developing and delivering from their opinions. When your opinions are backed by results time and time again, you will gain trust, scope, and career growth. Opinionated and reliable engineers are extremely valuable to a business.

It’s clear opinions are important for design, implementation, operations, product strategy, career growth, and probably a lot of other facets.

This now calls into question the article title: “What’s the value in not having a strong opinion?”

To be a bit more accurate, the title should really be ‘The Value of Having “No Strong Opinion” in Software Engineering, Specifically when Making Less-Than-Critical Decisions.’ Though, that’s a little verbose for my taste, personally.

Deciding which decisions are less-than-critical falls outside the scope of this article.

Every project requires many, many decisions to be taken, both implicit and explicit. There are decisions at every stage of every product ever produced.

Every decision carries some hidden weight of importance. Measuring this weight precisely might be impossible, but one can usually ballpark how impactful one decision may be compared to others.

During those discussions about less-than-critical decisions, I argue there can be value in having No Strong Opinion for a few reasons:

1. You can voice your thoughts without implicitly requiring others to rebut or take the time to prove/disprove your suggestions

I’d wager many software engineers have felt that pain when someone voices a suggestion as an alternative to your approach that no one on your team has worked with or understands intimately. Or at the least, they cannot provide a strong reason as to why their suggestion is better, only that it is in fact another option.

Even if the proposed solution would work fine, suggestions like these can lead to long debates on trivialities (see Law of Triviality aka “bike-shedding”), hours spent looking into the proposed idea, trying a tutorial, watching YouTube deep-dives, etc. only to ultimately keep the originally proposed solution.

This is time wasted in a business where velocity frequently matters.

If you have suggestions that may be useful but cannot substantiate your claims very well, explicitly stating that you don’t feel strongly can alleviate some of the pressure on the decision owner to spend their time on it.

Depending on the team/budget/runway/suggestion, maybe they can afford the time and really should investigate. But, at least they won’t feel blocked by your suggestions when the situation is less flexible and results need to be delivered soon.

2. You can influence less critical choices without being seen as overbearing or too controlling

As software engineers, we tend to think everything is important. Because, it all is! But when everything is important, nothing is.

Not all choices are equal, and some decisions just need to be made rather than belabored or optimized for some unknown metric or mysterious future use-case (see Analysis Paralysis).

When you make it clear this particular opinion is not strong, you’re able to inform the team of your stance and thoughts, while enabling them to move faster by being clear you won’t block them on this point.

Maybe they really like the suggestion, or maybe it’s fine as-is. Either way, your team is able to continue making progress without needing to hold another meeting on the differing points of view just to reach a final verdict.

3. You can empower others to own their choices and learn from their own successes and mistakes

Part of the dynamic of being in a team is allowing others to contribute to the whole team’s destiny: being able to experience the satisfaction from a good decision or feel some pain from a less-than-ideal decision.

A staff engineer does not have enough time in their week to build all the projects, even if they could probably do it better than most. Their job is to guide many engineers in their organization towards a shared vision and communal engineering success. This means allowing those more junior than them to have final say in many of the less critical decisions.

Software engineering at any medium to large sized team tends to be highly collaborative, which leads to many discussions and opportunities for feedback. For instance,

• Maybe you think you have a cleaner implementation than your peer’s recent PR, but their PR functionally has no issues.
• Maybe you’re aware of another technology that tends to be a bit faster but you also know can be more expensive, and you don’t know how it’d actually perform in this design.
• Maybe you prefer a snake_case JSON schema and they’ve created a PascalCase one (gross 🤢).

For these matters, it can be valuable to contribute suggestions/provide feedback, but enabling others to ultimately choose for themselves and learn along the way is extremely valuable for their feeling of ownership and personal growth.

It is a fact that many decisions are reversible, and allowing individuals to learn and grow is invaluable in building a strong team long-term.

Software engineering is a non-trivial effort. It is very important to develop opinions, understand tradeoffs, and learn why the best practices are what they are. Your opinions will shape everything you create; developing these opinions will be critical to your ability to build bigger, better, and more efficient systems. Continue to refine your opinions over time, and when someone else’s approach goes against everything in your gut, don’t be afraid to push back strongly.

But for all those decisions which aren’t as critical, those decisions that are highly reversible... consider having No Strong Opinion.