SivaLabs

A few years ago, I was working at a fintech company in Germany. Our business unit planned to build a new offering for customers in Germany and the UK. Our team — product owner, business analyst, developers, and QA — gathered at a location and ran brainstorming sessions. Since we were also using the product ourselves, we were essentially both the builders and the end users.

After a full day of discussions, we collectively came up with a list of features for the first MVP. The BA took brief notes, and later, together with the developers, prepared JIRA cards for all those features. We then expanded on the requirements to flesh out the use case details and added acceptance criteria. In that company, we (developers) worked closely with the product owner and BA throughout the entire requirements process.

A few years later, I worked at a client site on a banking project. The culture was very different. Business folks with deep domain knowledge were always busy and could only spare limited time for requirement-gathering sessions. Typically, the BA would talk to the business team, prepare requirement documents, and get approval from the business owner — only then would developers enter the picture. That was simply how that organization operated.

Now consider a solo entrepreneur building a SaaS product. They have to wear many hats: market research, validating the business idea, writing requirements, implementing them, testing, and releasing the product. In this context, the developer does it all — from preparing requirement specs to shipping the software.

The bottom line is that different organizations have different ways of working. In some, the BA owns the requirement specs; in others, the PO, BA, developers, and QA all collaborate on them together. And in the solo-entrepreneur scenario, the developer steps into the roles of business owner and end user to prepare the specs themselves.

To truly appreciate this diversity, you either need to have worked across organizations with different cultures, or have the open-mindedness to accept that your way isn’t the only way.

What if a developer spent their entire career at companies where fully-prepared requirement specs were handed to them, and developers simply started from the implementation phase — and then decided that’s the only right way to build software?

Some people live in a bubble, too close-minded or arrogant to even consider that other organizations might operate differently. For them, the very idea of a developer taking a rough requirement and fleshing out the details and acceptance criteria seems unthinkable. But if they stepped outside that bubble and talked to people from other organizations — or to solo SaaS builders — they might gain a very different perspective.

Recently, I came across a LinkedIn post asking: “In the age of AI-assisted development, do you care about code quality?”

While most people replied “Yes, code quality is important,” one CTO responded:

We used to care a lot about code quality and put a lot of quality gates in the delivery process. But now we are optimizing for the quality and speed of the outcome, not for code quality.

The original post author then went: “Our friend XYZ thinks code quality doesn’t matter. Let’s help him” — subtly implying, “You are wrong and you need help.”

My knee-jerk reaction to hearing “code quality doesn’t matter” would be “That’s ridiculous — of course code quality matters.”

But what if, instead of being judgmental, we actually tried to understand why he feels that way?

After all, he is a CTO — responsible for leading his team and making sure things are going well. If he’s saying they manage to deliver a solid product without obsessing over code quality, isn’t it worth asking how he pulls that off?

We may strongly believe code quality matters, and we likely have painful past experiences to back that up. So how about asking the CTO how they handle the problems that typically come with lower code quality? By simply asking those questions, one of three things happens: you understand how they manage without it, the CTO realizes they hadn’t considered your points, or you realize the CTO is simply bluffing.

Either way, asking questions to gain clarity is far better than deciding someone is wrong and needs saving.

There’s no shortage of judgmental people who live in a bubble and believe only they know what’s right.

If you think you can change their minds by explaining your point of view, you’re most likely wasting your time. They’re incapable of seeing things from your perspective. Clarify one point, and they’ll immediately find another angle to prove you wrong.

In this fast-paced world, your time and mental peace are precious. If there’s a disagreement with a teammate or colleague, it makes sense to invest time in understanding each other and reaching a common ground — that’s worth it.

But spending energy explaining yourself to a random judgmental stranger on the internet who has zero interest in asking questions or understanding where you’re coming from? That’s just draining yourself for nothing.

Be open to constructive criticism. But if the other person is only interested in proving you wrong because you hold a different opinion — with no interest in genuine dialogue — don’t engage. Life is too short.

If you disagree with someone, ask questions first. Don’t be so quick to judge.

In today’s world of AI-assisted development, much has changed. The way we write code, the way we use tools, and the way we learn — all of it is evolving at a pace we haven’t seen before. While some core principles remain as valid as ever, many long-held assumptions deserve a fresh look.

There’s a fine balance to strike. Those who ignore the lessons of the past are doomed to repeat the same mistakes. But those who cling too tightly to old ideas will never innovate. The sweet spot is being grounded in fundamentals while staying genuinely open to experimentation.

We are all figuring this out together. Some new tools and approaches will prove transformative; others won’t pan out. That’s how progress works — and that’s okay.

The real superpower in this era isn’t having all the answers. It’s setting aside your preconceived opinions and being willing to try something that looks ridiculous on the surface. You never know what you might discover.

Cheers.