How to communicate without seeming like a person who's pretending to be smarter than the others?

Question

I am working as a software engineer. I have colleagues that believe in a set of things: SOLID, TDD etc. These are a set of practices that are very commonly known as "best practices". I don't automatically adhere to those principle and I think that sometimes they are harmful in some way. When I talk about my disagreement, I fail to persuade anyone unfortunately even when I provide arguments. I think the main reason is that my communication is somewhat violent. It's like criticising someone's religion. It's inherently violent.

Is there any books, podcasts, whatever that could be helpful in such a situation? I prefer resources that expose conversations and comment them rather than bullet points of tips but I appreciate any suggestion.

PS: I have already read nonviolent communication by Rosenberg.

Answer 1

Check out How to Win Friends and Influence People by Dale Carnegie. It's remained one of the most popular self help books for over 80 years--and with good reason.

Simply from the way you phrase your question, I can tell you're approaching this from completely the wrong angle. If people feel they're being attacked, you've already lost. Don't "provide arguments." Don't try to convince them you're right and they're wrong--you're all on the same and team working toward the same goal. Instead, ask questions and propose statements that they can agree to without feeling attacked. Lead them to the conclusion you want. (If your proposal is truly better than what they believe in, this shouldn't be all that difficult.) If they have a strong attachment to ABC, DEF, or even XYZ, don't make the conversation about these acronyms.

When they've reached the "correct" conclusion, let them think it was their idea. Again, the goal is not to win an argument but to influence behavior and the best way to do that is take our natural egoistic responses out of the equation. If you approach it from the perspective of winning an argument, you'll be met with resistance at every turn and even if you eventually win this particular argument, you still will have lost in the long term as they will come to resent you and the next time there's a disagreement, they will push back even harder.

Answer 2

You write of the standard way of doing things that "sometimes they are harmful in some way". You may well be right, but they are also extremely helpful in general. I'm getting hints that you might be looking for freedom to abandon SOLID and TDD completely on the grounds that they are "sometimes harmful". I doubt that the percentage of times SOLID is harmful rises as high as 10%, probably much less. Are you writing 90% of your code according to SOLID? If you made sure you always followed SOLID in the times it was preferable you would have more credibility when you wanted to not use it.

You also have to remember that a big part of writing good code is to make it understandable by the people who have to maintain it. That means that they see the kind of code they expect. It's why we have coding standards and patterns. If you use a different pattern from normal there has to be a *really * good reason for it - not just some minor potential benefit.

The other way to not come across as "violent" is to make sure you acknowledge the places where other people are right. Make it clear to them that you do think that SOLID works in 95% of cases. Write code like you think that. If you get in a debate make sure it is about one of the 5% of cases where it is questionable.

EDIT: If you believe you have a decomposition method that is superior to what is currently being used (remembering that SOLID is not itself a demposition, just a set of rules of thumb for evaluating decompositions) then I would suggest asking if you can present this methodology to your colleagues. Be prepared for bringing about change to take a long time. People are understandably reluctant to replace a known working system with an unknown one unless they are presented very convincing evidence, usually over a long time.

Answer 3

Generally if you want to have productive conversations then you pick topics that people want to talk about.

If you already know that they don't want to discuss something and you don't want to antagonise them or have a confrontation then don't bring it up unless asked your position or opinion on a matter.

Answer 4

Convincing a team of seasoned developers who work well together to abandon core practices like SOLID is probably never going to happen, regardless of how you tailor you communication style. They've experienced tangible benefits, and any downsides your seeing are worth it to the team.

Taking your specific example, I think you're best chance at a compromise will be attempting a shift of how you define 'Single'.

While your team may expect a REPL to have classes similar to this:

• CommandReader
• CommandEvaluator
• CommandPrinter

Each obviously only does one thing, but you can also just write a class similar to this:

• REPLRunner

It's 'single' responsibility would be driving the Read-Evaluate-Print loop.