Being right

Bronislav Klučka on June 29, 2025

Is it worth always "being right"? What does it mean to "be right" in software development? How important is it for a leader to "be right"? When does it all becomes arogance?

Have you ever had to deal with someone who always has to be right?

Developer's point of view

I'm going to use this section to explain my reasoning.

As developers, we like to think that we are rational. Based on my experience, though? Not really. We're still people who often make decisions based on subjective preference and then rationalize them to sound smart. Making decisions based on preference isn't inherently wrong; rationalizing is.

My previous statement might sound strange. Making a decision based on preference? Really? Let me give you a food example.

It's wrong to not eat at all. It will cause you to suffer and die. I think we can all agree that it's objectively wrong.
There is a strong argument that steak with potatoes is a higher quality food than cake. But where does the "wrong" lie? Where is the exact line between eating three whole cakes a day and one slice a week? Who has the authority to determine what is right or wrong?
And now? Which is better: beef steak with potatoes or fish with rice? You can quote any article or authority supporting one over the other based on any metrics; I will find a opposing statement and authority.

At a certain point, unless you have specific needs, the choice doesn't matter. Arguing about it becomes a mere pissing contest.

So, you are about to write a typical backend for a web application with lots of CRUD operations. Your choices are PHP or Node.js. The question is: Which is better? Unless you can prove that one of those options is better in every way, it comes down to which qualities are more important to you and which negatives you find more significant. Search for a performance comparison between Node.js and PHP (hint: It's pointless. There is very little agreement, even on specific metrics.)

Suppose one is 10% better than the other at CPU-intensive tasks. Okay, so what's your point? Does that make it better for regular CRUD applications? You spend milliseconds on raw computing and much more time transferring data between the client and server and talking to the database. Sorry, but unless you're building something where this is actually relevant and affects customers, it doesn't beat how comfortable you are programming in a particular language.

PHP is often deployed as "fire and forget" processing, whereas Node.js is usually deployed as a persistent server. Memory leaks are less of a concern in PHP, but memory leaks in Node.js (ECMAScript) can be pretty nasty due to closures. If PHP crashes, , it only takes down one request. If Node.js crashes, the whole server is down. PHP wins! Or does it? Using Node.js as a server gives me better and simpler control over the HTTP protocol itself, and I can use the fastest cache: an in-memory cache. What about memory leaks? Learn the language and monitor memory usage. Crashes? Fix them. It's harder, but solvable.

So again? Based on which objective, universal metrics is one better than the other?

A few weeks ago, the team was discussing the PHP vs. Node.js question, and for some reason, they ended up discussing garbage collector performance. May be nice theoretical discussion on garbage collector strategy, sure. But if you're concerned about garbage collector performance and have optimized everything else to the point that the garbage collector is an issue, or if your performance or computation demands are so high that the garbage collector becomes a question, then just go with Rust 😉.

There is no such thing as the best folder structure, the best implementation of DDD or separation of concerns. There is no such thing as best language, database, or framework.
The more specific the solution is, the more specific the use cases it covers.

You can either be right or you can be in a relationship.

Leader's point of view

I'll be brief: I'd rather have a cooperative team of ordinary developers than a bunch of really good, arrogant individuals who have to be right at all costs.

This is also, by the way, a false dichotomy. There are great developers who are also great team players.

It's difficult to let go of a talented person who has personality and communication issues. But when such person becomes toxic, it's time to let go. This isn't about giving up technical excellence and mastery. The difference lies not in the code itself, but in communication.

How do you spot such person:

Is everything important? Is everything a matter of life or death? Does everything have to be perfect? And is that person the arbiter of perfection?
Do they teach, explain, or do they order people around?
Are they angry when they "lose"? Do they disregard agreements?
Do they inspire people? Or do they drain them?
Do they encourage people around them to come up with ideas, or do they simply present the solution?
Do they have to do all the hard work because the others are too stupid to handle it?

The long-term health of the team is more important than the performance of any individual.

What would I do after spotting this person?

Talk to your team about teamwork and the importance of cooperation over being right.
Explain that their job is not only to write code, but also to collaborate with others.
Explain that they are responsible not only for the health of the code base, but also for the health of the team.
Explain that fixing poorly written code is much simpler than fixing a broken team.
Make it clear that this is important to you and that it's not a trade-off between quality and cooperation.
Make it clear that this is something you are going to focus on.

You should have this as one of priorities anyway.

During a one-on-one with the person causing the problem, make it clear that their behavior triggered this situation. Tell them that you are interested in cooperating under certain conditions.

Readjust team roles. This behavior is about power, so eliminate it. It's a form of punishment and an opportunity for this person to grow, as well as an opportunity for others to grow. If this person has a unique role, distribute their responsibilities among the others.

If the situation does not improve, but there is still value in this problematic person, isolate them. Assign them tasks in which they excel and limit their interaction with others.

Of course, it can come to a deliberate and planned replacement.

Alone, I go faster. Together, we go further.

Architect's point of view

What is the architect's responsibility? The system is functioning within the expected parameters (budget, number of users, etc.). The system can be maintained and evolved in the long term. This is a high-level (very high) overview of the technical aspects of your role. There are other aspects, but let's stick with these. In other words, it's not your responsibility to make short-term plans or tactical decisions. If the team asks for your help, help them. If there is a discussion, share your opinion. However, you should not micromanage the developers or make all the decisions.

Establish boundaries for the team. Set higher-level expectations, but don't interfere in day-to-day work unless those expectations are jeopardized.

Don't make any choices unless you absolutely have to. Be very careful with decisions as well. Let the team grow.

One more thing is your responsibility: educate the team!