What does it mean to be a software developer?
You can think about writing code running in a reasonable amount of time. You can think about design pattern, microservices, programming languages, and code syntax. What else?
We have tendency to forget that being a software developer means dealing all day long with fellow humans. Interacting with others, communicating, explaining ideas, adapting to your team members are very important skills.
The art of debating is part of this set of communication skills you need to have. 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.
I propose to dive into the art of argumentation today for you to have a bigger and, hopefully, a better impact on what you’re working on. We’ll see:
- When should you argue with your peers, and when should you avoid the debate.
- Tools and advice to have constructive debates.
If you want to be meta and argue with me on the subject, the comment section is ready for our arguments.
The Benefits of Improving Your Debating Skill
Imagine this: Dave, your colleague developer, thinks that creating a multi level inheritance tree to specialize a god class of 10 000 lines is a good idea. Obviously, 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 whoever will work on the project. Congratulations!
Debating can bring value and reduce technical debts by creating new ideas. It can avoid bugs and improve scalability. Communication is a very important quality, even more important as raw knowledge.
If you know how to argue and if you do it when you need to, you’ll be seen as well as somebody interested in his work. You’ll show that you’re not a code monkey.
Debating, even if it can be tiring at first and tricky to do correctly, can as well teach you a lot by confronting your ideas with others. Whatever the outcome, you will always learn something. It will increase:
- Your communication skills.
- Your technical knowledge, especially if you’re wrong.
It can be painful as well, but, like failures, it can bring you a lot.
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 you and never explain why what you’re saying is wrong with good and reasonable arguments, you really need to try to improve the situation and explain the benefits of debating and discussing in general… or you need to find another job.
To Debate Or Not To Debate
Discussing and debating have great benefits. But before going into a heated conversation with anybody, ask yourself: should I debate?
Think Twice Before Creating or Participating in a Debate
Let’s be honest: many discussions 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 ego: you argue that space is better than tab because you’re right, and the others are wrong.
If you try to convince somebody that there is a better way, you should argue about things which matter for the business you work for. About things which bring real, concrete value. Spaces instead of tabs in a codebase won’t bring any value to a company. On the contrary, improving the UX of an application, for example, can bring a lot of value.
In general, beware when Dave, your colleague developer, comes to you, full of anger, to fight about code syntax rules: nobody, except him, care about that, even less the customer who pays good money for the product you work on. I 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”, you have to run away.
That said, customers will care if nobody can understand the codebase anymore and fix bugs or add new features. Most debates about technology might be useless, but some are very important to have.
Debating takes time and cost mental energy. Choose your debates wisely.
Patience and Calm are Valuable Developer Skills
Now 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. He might never want to be wrong.
Whatever the reason, as a rule of thumb, don’t let a debate go beyond 20 minutes.
After this lap of time, you should have been able to throw 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 external to the conversation, and therefore neutral, to solve your differences. It could be another colleague or even your boss (CTO, team leader, and whatnot). Be aware though that you might make Dave angry if your boss think you’re right. Yet, it’s still better than letting very bad idea be 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 object 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, except maybe flattering your ego for a couple of minutes. Explaining with calm, in a simple and concrete way, the bad consequences an idea have or can have, is better than blaming to show how smart you are.
I insist on the 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 try to keep your voice low and your movements deliberate, smooth and controlled.
Sometimes, you have to let some creepy code, bad ideas or nonsense features live in your shiny application. As a developer, not everybody will take your opinion in consideration, unfortunately. Keep in mind that coding is an iterative process: you can always refactor later, if the entropy doesn’t go through the roof.
At least, you tried to show the way. If nobody’s ready to take it, they might listen to you another day. Don’t forget as well that time is sometimes necessary for people to really understand your arguments and ultimately accept your opinion. A debate, even not resolved, can bring new ideas and can have consequences on a longer term.
You Don’t Have the Perfect Answer
Problems can be tackled in many ways. Don’t be closed to everything a colleague tells you because it sounds silly at first, or because you never heard of it before. 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, try to keep your mind open. You might learn way more by really taking every idea into consideration. Notably if the colleague you argue with is an interested developer you trust.
Be aware as well that everything has benefits and trade-offs. Every decision has a cost: time, money, 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 Emotions Cloud your Judgment
The mood you’re in can change your perception of 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 subject 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.
Of course, 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 is really useful.
Developing the Skills to Argue Effectively
The Ego Problem
If you need to follow a golden rule when debating, take this one: don’t take it personally. In other words: don’t feel attacked directly, as a person. You’re a professional and therefore you work for somebody. It’s not about you, it’s about this somebody.
If you try to defend your ideas just for the sack of being right, whatever the reason, you should stop the debate. Being a developer is a concrete job where you have to create value. Therefore, 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. If they feel weak, stop the discussion, think about it, and find good arguments to defend your ideas if it’s worth defending.
Another important thing: you need to be ready, when expressing your disapproval, to be wrong. Nobody is always right; 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.
Don’t think about being wrong as something negative. It’s a vector of learning.
Use Experiences From Others
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 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. Opinion leaders should provide you these concrete arguments; if they don’t, their names alone shouldn’t influence your decisions.
Other developers on the Internet might have good and concrete arguments, without being “famous”. Don’t hesitate to borrow them, too.
Use Metrics and Other Scientific Data
Don’t hesitate to wave survey results and scientific studies to the one(s) you’re debating with. Concrete data is always good, 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 doing unit test is useless? If you gather studies which go in your direction, you normally have everything to prove that testing is really important.
Studies are not the only source of data available. You can use static analysis tools to show that part of a project need to be refactored. You have a dependency graph where every single class depends on each other? The complexity of your application goes beyond the universe, and there are no tests to cover it? These are good arguments to show that something needs to be done.
It’s powerful because it’s not about your subjective opinion, but about rational, concrete data.
Your Experience is Valuable
If you don’t have any data to support your arguments, you can speak about your own experiences. Try to be precise enough for people to correlate your experience with the present context. More link you can draw between your past and the present, more effective your argumentation will be.
To be as precise as possible when I share my experiences, I write in a journal when I see weird bugs. 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 have little weight.
The Difficulty of Forecasting
I covered mostly argumentation about things which happened in the past (technical debt, legacy systems, bad features and so on) and things which need to be fixed in the present. What about the discussions about what should be done for the future?
This is one of the most complicated things to do; the future is always uncertain and trying to guess it can be dangerous. Yet, companies need to predict the behavior of their customers and the evolution of the market. They need to have a vision for future. If you begin to argue with your colleagues or your management that this or that feature in your application is stupid because you know better, I advise you to find better arguments.
To predict the 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 your customers what they think about it.
Don’t let your subjective judgement deciding everything. You’re most likely not part of the marketing target for your company’s product, so you don’t know what would be best for this target.
I know and saw too many companies forecasting 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 believe deeply that our job is not only to code but to use our knowledge to bring value to the company you work with. You are an intelligent human being, you can as well give advice which can help your company growing. If your management is ready to listen to their employee and take their opinion in consideration, of course.
When Do You Win?
Big surprise: It doesn’t matter if you’re wrong or right. What matters are the decisions you make following the discussion. Winning an argument as a software developer means bringing (or discarding) ideas to ultimately create value.
Don’t forget: recognizing that you’re wrong make you more humble and show the weak spots in your knowledge. As a result, it’s a good opportunity to learn. If you think you’re always right, you won’t learn anything from the debates you’ll have with your colleagues. In return, they might think you’re a pretentious douche.
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.
Creating a win-win situation following a debate would be the best outcome. No animosity, no bitterness, ideally everybody should learn something from it, and it should ultimately drive everybody to take the good decisions.
Your company, your client, or your customers will thrive if you try to keep this mindset.