What does it mean to be a software developer?
We could think about creating scalable design, writing good microservices, using nice programming languages, or be aware of the problems we might find along the way. What else?
We sometimes forget that being a software developer means working all day long with human beings. Communicating, explaining ideas, adapting to your team members are very important skills, and the art of debating is part of this set. It’s something we do a lot, sometimes without a real good reason. This is a complex subject which has its own rules and outcomes.
In this article we’ll dive into the art of debating to understand how to have a better impact on what we’re working on. More precisely, we’ll see:
- When should we argue with our peers and when should we avoid the debates.
- What are the tools you can use to have constructive debates with positive outcomes.
Let’s dive into the wonderful world of debates.
The Benefits of Improving Our Debating Skill
Imagine this: Dave, your colleague developer, thinks that creating a multilevel inheritance tree to specialize a god class of 10 000 lines is a good idea. If you speak with Dave and succeed to put down his plan to destroy the codebase, you’ll save some headaches for you, Dave, and all your colleagues. Congratulations!
Even if it can be tiring to go into a debate and sometimes tricky to do it correctly, it can also teach you a lot by confronting your ideas with others. Whatever the outcome, you’ll always learn something if you want to. It can improve:
- Your communication skills.
- Your knowledge, especially if you’re wrong.
Now, look around you: are your colleagues open to discussions? Can you propose your ideas freely, even if they might sound silly? Do they let you express your concerns and listen to your proposals of improvement?
This is really important if you want to learn more and blossom like a little flower: a company culture should be as open as possible to new ideas, even if it creates discussions and arguments. If nobody listens to us, never explain to us why what we’re saying is wrong with reasonable arguments, it’s important to try to improve the situation and encourage people to discuss more and share their ideas. Innovation comes from collaboration, and collaborating implies debating.
Thinking Twice Before Debating
Let’s be honest: many debates in the software world are useless. It’s the grotesque example of arguing about “space vs tab”:
- It doesn’t bring any value, to anybody.
- It’s purely based on the ego of the participants: Dave will argue that space is better than tab because he’s right and the others are wrong.
If we try to convince somebody that there is a better way, we should argue about things which matter for the business we work for. About things which bring real, concrete value, directly or indirectly, like time or money. Using Spaces instead of tabs in a codebase won’t bring any value to a company. Improving the UX of an application, for example, can bring a lot of value to the end users.
We could extrapolate to most technology wars between engineers. If they lack arguments and seem to be in loop on “this technology is better because of X reasons not related to the business”, it’s useless to debate. That said, customers will indirectly suffer from a legacy codebase where it’s costly to fix bugs and add features. Most debates about technology might be useless, but some, with potential real benefits to the application, are important.
Debating takes time and cost mental energy. Choose your debates wisely.
Debating With Respect and Patience
Let’s imagine the following situation: you’re in a heated discussion with Dave, your colleague developer, about this god class he wants to keep and extend. You know it’s wrong. Everybody knows it’s wrong. Still, Dave wants to do it. Maybe he felt attacked personally by your arguments. He might lack self-confidence. Maybe he never like to be wrong because he’s very insecure.
Whatever the reason, as a rule of thumb, don’t let a debate go beyond 20 minutes. It’s enough to give your best arguments. If Dave doesn’t want to follow your idea and extend the god class instead of refactoring it, I would suggest two possible solutions:
- Ask somebody more neutral, external to the conversation, to help solve your disagreement. It could be another colleague or even your boss (CTO, team leader, and whatnot). But be aware that you might make Dave angry if your boss think you’re right. Yet, it’s still better than letting very bad idea being implemented.
- Accept the arguments, for now, and be patient. Write somewhere that you had this discussion. If you were right, there will be consequences. When bugs will occur because of the topic of the debate, or when somebody will complain about it, launch a new conversation with this new knowledge. Show concrete consequences of the bad idea.
As a general rule, when you’re proven right, don’t claim loudly through your open office: “I told you so, you miserable pig! I was right! Therefore, I curse you and all your family on three generations!”. Nobody reacts well to the famous “I told you so”. It doesn’t bring anything to anybody, it will only flatter your ego for a couple of minutes. Explaining with calm, in a simple and concrete way, the bad consequences an idea have can have is better than blaming to show how smart you are.
I insist on this idea of calm. During a debate, everybody is more sensible about the tone of your voice and your body language. I struggle myself with this, but I think we should try to keep our voice low and our movements deliberate, smooth, and controlled.
Sometimes you have to let some creepy code, bad shortcuts, or weird features live in your codebase. As developers, not everybody will take our opinions in consideration, unfortunately. Keep in mind that coding is an iterative process: you can always refactor later, if the entropy becomes unmanageable.
At least, you tried your best to improve the situation. If nobody is ready to take it, they might listen to you another day. Also, don’t forget that time is sometimes necessary for people to really understand your ideas and your arguments and ultimately accept your opinion. A debate, even not resolved, can bring new ideas and can have consequences on a longer term.
We Don’t Have the Perfect Answer
Problems can be tackled in many ways. Don’t be closed to the opinion of a colleague because it sounds silly. Maybe the solution is valid but you never thought about it. Learning to pause and think is important: what could be the benefit of this approach? What could be the drawbacks?
In short, listen and try to keep your mind open. You’ll learn a lot by trying to take every idea into consideration. It might sound easy at first but it’s not: truly listening to people take time and practice. It means that we need to:
- Avoid interrupting the other to give our opinion.
- Really thinking about what the other person is saying and not about our own opinion or about our lunch.
- Ask questions to be sure we didn’t misunderstand anything.
Also, be aware that everything has benefits and trade-offs. Every decision has a cost: time, money, or technical debts. Assess your ideas, understand what are the possible problems in the specific context you’re in, and explain them during your argumentation.
Don’t Let Your Emotions Cloud Your Judgment
The mood you’re in can change the perception you have about basically everything. If you feel that you argue because you’re in a bad mood, or because of other external factors which have nothing to do with the topic of the conversation, it’s time to stop the debate. Reflect on why you reacted like you did, and try not to let your emotions drive your argumentation.
Like many things, it’s easier to say than to do. Personally, I know that meditation is a great way to be aware of my emotions before letting them take possession of my mind. Being able to stop and think before going into a diatribe full of anger has been proven useful to me many times.
The Ego Problem
If you need to follow only one golden rule when debating, take this one: don’t take things personally. Nobody is attacking you. You’re a professional and you’ll often work for somebody. If it’s not a company, it will be your clients or your customers. It’s not about you, it’s about them.
If you try to defend your ideas just for the sake of being right, you should stop. Again, the goal of a developer is to create value. We automate things to gain time and money. As a result, you, personally, is out of the equation when it comes to debates.
It’s easy to see if you argue for the sake of being right or if you don’t: just listen to you arguments. Try to be honest with yourself. If they feel weak, stop the discussion, think about it, and find good arguments to defend your ideas if they’re worth defending.
Another thing: it might sound obvious but you need to be ready, when expressing your disapproval, to be wrong. Nobody is always right; recognizing being wrong is a sign of humility and a proof that you are open-minded. You need to be able to question yourself to grow.
It’s not negative to be wrong. It’s a fantastic vector of learning.
Using Metrics and Other Data
Don’t hesitate to wave survey results and scientific studies to the one(s) you’re debating with. In my opinion, it’s the best tool you have for a constructive debate, especially if:
- The study explain precisely how the data was collected and analyzed.
- The study was repeated multiple time by different groups and led to the same conclusions.
When you read a book (or an article) where these studies are mentioned, try to find the original and read it. I often note them in my note taking system, to be able to put them on the table when needed.
Dave, your colleague developer, thinks that writing unit test is useless? If you gather studies which go in your direction, you have good arguments to change his opinion.
Studies are not the only sources of data available. You can use static analysis tools to show the pieces of your codebase which need to be refactored. You have a dependency graph where every single class depends on each other? The complexity of your application goes beyond infinity and there are no tests written? These are good arguments to show that something needs to be done.
It’s powerful because you show that it’s not about your subjective opinion but about rational and concrete data.
Our Experience is Valuable
If you don’t have any data to support your arguments, you can speak about your own experience. Try to be precise enough for people to correlate your experience with the actual context you’re in. The more links you can make between your past and the present, the more convincing your arguments will be.
To be as precise as possible when I share my experiences, I write in a development journal when I bump into weird bugs or other defects. I write precisely why the bug occurred, how it could have been avoided, and the possible solutions. If somebody is ready to do the same mistakes and launch a debate, you can pull off your notes from your journal.
People like stories. If you have a precise one which relate fully to the situation you’re in, use it. Trying to stay lucid and rational is key. Again, purely subjective arguments should be avoided.
Using Others’ Experiences
When you defend an idea, simply quote somebody who agrees with you. This somebody should be important in the field, a big name like Martin Fowler. Chances are that they have many good arguments to support your idea.
More people you’ll quote, stronger your argumentation will be. It’s not your ideas against somebody else’s anymore, it’s influencer’s proven-to-be-right-ideas against ideas with less weight.
I used to copy past some quotes from opinion leaders concerning different subjects (which are important and often source of endless conversations, like unit testing for example) in my note system. After all, these people have a lot of experience, are passionate, and spend a lot of time thinking about these issues. Thus, their opinion is worse the consideration.
Be careful though: not everything from evangelists will apply to your specific problem. Don’t invoke the Single Responsibility Principle spell without any argument why it’s useful and valid. Always look at their source of inspiration to see if they didn’t deform the reality for their own benefit. Like everything, we should try to dig the subject and look at other opinions to forge our own.
Additionally, it’s considered a fallacy(the “The ad verecundiam fallacy”) to only quote a higher authority figure to prove the truthiness of an idea, especially when the opinions of experts are divided.
Other developers on the Internet might have good arguments with concrete examples, without being “famous”. Don’t hesitate to borrow them, too.
The Difficulty of Forecasting
I covered mostly debates about things which happened in the past (technical debt, legacy systems, bad features…) and things which need to be fixed in the present. What about the discussions to decide what should be done in the future?
This is is a complicated thing to do; the future is always uncertain and trying to guess it can be dangerous. It can lead us to implement useless features increasing the complexity of our codebase. Yet, companies need to predict the behavior of their customers and the evolution of the market. They need to have a vision for the future.
To predict this future, one thing can really help: concrete data. Again.
If you disagree with some future guessing, you can:
- Propose to do some A/B testing to see how things evolve and extrapolating from there.
- Propose to create well-made surveys with precise questions for the company’s customer target.
- Look at the complaints of your users and analyze the data.
- Prototype quickly some functionalities and ask the end users what they think about it.
Don’t let your subjective judgement deciding everything. We can’t predict the future with 100% accuracy, so our judgement is still important, but it shouldn’t be the only thing backing up our decision.
I saw too many companies trying to forecast the future without any fact or data, and making disastrous feeling-based decisions. If you participate in a debate to know if this functionality will please your customer, please try to find facts to support your hypotheses.
You might think right now: “I’m a developer, I don’t need to take care of that!”. That’s true; yet, I deeply believe that our job is not only to code but to use our knowledge to bring value to the company you work with. You are a smart (and awesome!) human being, you can also give advice which can help your company growing. If your management is ready to listen to their employees and take their opinions in consideration, of course.
Trust me, you’ll feel even more useful if you adopt this mindset and you’ll learn a lot. Finding a purpose and feeling useful in our daily job can reduce our stress and prevent us to burnout.
When Do You Win?
What did we learn in this article?
- We need to think about the value we can create from a debate. If there is none, the result doesn’t matter; we shouldn’t discuss it.
- Being right or wrong is not the goal. What matters are the decisions we make following the debate and the ideas we’ve created.
- Winning an argument as a software developer means bringing (or discarding) ideas to ultimately create value; it’s not about us.
- Recognizing when we’re wrong help us find the gaps in our knowledge. It’s a good opportunity to lean and improve.
Every idea or technology can be potentially useful; it mainly depends on what problem you’re trying to solve. Adapt your thoughts, your arguments, and your decisions accordingly.
Your company, your client, or your users will thrive if you try to keep this mindset.