What does it mean to be a software developer?
A lot of developers out there, even with a lot of experience, will speak about writing code with good performance. They will speak about design pattern, microservices, languages (and why the ones they know are better) and code syntax. They will throw to you a diatribe full of technical jargon.
Is it really it?
We have tendency to forget that being a software developer means dealing all day long with humans. Interacting with others, communicating, explaining ideas, adapting to your team members are very, 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 to the people you work for.
Do you really know when to argue? When to stop a debate more infinite than the universe itself? Are you ready to defend your ideas efficiently?
Let’s assume you are.
The Benefits of debating
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 I-want-to-destroy-the-codebase plan, you will save some headaches for you, Dave and whoever will work on the codebase. Congratulations.
Debating can bring value and reduce technical debts. It can avoid bugs and improve scalability.
If you know how to argue and if you do it when you need to, you will be seen as well as somebody interested in his work. An important quality for any company out there.
It can show that you are interested in what you’re doing, in the company you’re working with and that you’re able to progress and learn. A lot of good qualities, which is as important as raw knowledge, specifically for a beginner who doesn’t have a lot of experience.
In short, you will 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 improve you communication skills if you really pay attention to do it in a smart way. It can bring you as well technical knowledge, especially if you’re wrong. It can be painful, but like failures, it can bring you a lot.
Now look around you: are your colleagues open to discussions? Can you propose your ideas, even if they look silly for everybody? 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 ever listens to you and never explain why what you’re saying is wrong, constructively, you really need to try to improve the situation and explain the benefits of debating and discussing in general… or you need to search another job.
When should you begin a debate?
Discussing and debating have definitely benefits. However, before going into a heated conversation with anybody, ask yourself: should I debate?
Think twice before instantiating or participating to a debate
Let’s be honest: a lot of discussions in the software world are useless. It’s the grotesque example of arguing about “space vs tab”:
- It doesn’t bring value, to anybody.
- It’s purely ego based: you argue that space is better than tab because you’re right, and the others are wrong.
Going into an argument with somebody means that you will spend time and energy trying to convince him that there’s a better way. Therefore, you should argue about things which matter for the business you work for.
I insist on this point: 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 every war engineers fight about technologies. If they lack arguments and seem to be in loop on “this technology is better ‘cause x reasons not related to the business”: flee, you fool.
However, customers will care if there are a lot of bugs because the codebase is so complex nobody knows how to extend it anymore, without crashing half a dozen other functionalities.
Debating takes time and cost energy. Choose your debates wisely.
You need to learn when to stop
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 with your argumentation. Maybe he lacks self-confidence. Maybe he never wants 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 still doesn’t want to follow your idea and extend the god class instead of refactoring it, I would suggest two possible solutions:
You can go to your boss (CTO, team leader and whatnot) and explain the problem. Ask somebody external to the conversation to solve your differences. 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 his argument, 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 this god class or when somebody will complain about it, launch a new debate with this new knowledge. Show him concrete consequences of his idea. At that point, you might want to claim loudly through the open office space: “I told you so, you miserable pig! I curse you and all your family!”. Please don’t. Nobody reacts well to the famous “I told you so”. It doesn’t bring anything valuable 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 can have, or even better showing these consequences, 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.
This last approach won’t work all the time, and your colleague might be so unsure about himself that he needs to defend everything he thinks, even if you have enough arguments and concrete examples to prove him wrong. Personally, I try as hard as I can not to work with people who can’t accept good and precise arguments. Patience is key, but is limited too.
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 technical debts 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 argumentation 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 by 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 his 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 downsides, especially in software development. Every decision has a cost: time, money, technical debts. Assess your ideas, understand what are the possible trade-off and explain them during your argumentation.
Don’t let external factor or 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. Think 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 your emotion before letting them take possession of your mind. Being able to stop and think before going into a diatribe full of anger, for example, is really useful.
How to argue effectively
There are some ideas which are worst discussing for, but you need strong arguments for them.
The ego problem
If you need to follow a golden rule when debating, take this one: don’t take it personal.
In other words: don’t feel attacked, as a person and human being. 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 not debate.
Being a developer is a concrete job where you have to bring value to a company. You bring value by automating things with your beautiful code. 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, regroup and find good arguments to defend your ideas.
Another important thing: you need to be ready, when expressing your disapproval, to be wrong. Nobody is always right and being wrong is a sign of humility and a proof that you are open to learn new things. You need to be able to question yourself.
Don’t think about being wrong as something negative.
Gurus and other evangelists speak (often) the truth
This one works most of the time: when you defend an idea, simply quote somebody who agrees with you.
More people you will 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 evangelists concerning different subject (which are important and often source of endless conversations, like unit testing for example) in my note system to have them when I need them.
It makes sens: these people have a lot of experience, are passionate and put a lot of their time into development. Thus, their opinion is worst the consideration.
Be careful though: not every good practice from evangelists will apply to your specific problem. Use these arguments if it makes sens. Don’t quote for the sake of quoting.
Use concrete data
Don’t hesitate to wave surveys result and scientific studies to the one(s) you’re debating with. Concrete data is always good, especially if the studies you reference explain precisely how the data was collected and analyzed. The source of truth should be a reliable one.
When you read a book (or an article) where these studies are mentioned, take note of them somewhere to be able to find them easily when you need them. I note them in my note taking system most of the time, to be able to bring them on the table when needed.
Dave, your colleague developer, thinks that doing unit test is useless? If you gather studies and evangelist argumentation which goes in your direction, you normally have everything to prove that testing is really important for the company you work for.
Studies are not the only source of data available. You can use static analysis tools to show that a project need to be rewritten or at least heavily refactored.
You have a dependency graph where every single class depends on each other? The complexity of your application is beyond the roof and there are no tests to cover it? These are good arguments to prove that something needs to be done.
It’s powerful because it’s not your subjective opinion we speak about here. We speak about rational, concrete data.
Your experiences are 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, the arguments you’re giving and the present context. More correlation you will have, more effective your argumentation will be.
In order 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 one could have been avoided and the possible solutions.
If somebody is ready to do the same mistake and debate with you, 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 concrete and rational is key. Again, purely subjective arguments have little weight.
Forecasting about the future
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 debates of what should be done for the future?
This is one of the most complicated thing to do: the future is always uncertain and guessing on it is dangerous.
Yet, companies need to predict the behavior of their customers and try to find what they need to do in the future. They need to plan their roadmaps. If you begin to argue with your colleagues or your management that this or that feature in your shiny 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. Yep, again.
If you disagree with some future guessing, propose to do some A/B testing to see who’s right. Propose to create well-made surveys with precise questions for the company’s customer target. Look at the complains of your users and analyze the data. Prototype some functionalities and ask your customers what they think about it.
Don’t let your judgement deciding everything: you are most likely not part of the marketing target for your company’s products.
I know and saw too many companies forecasting the future without any fact or data and make disastrous feeling-based decisions. If you’re in a debate to know if this functionality will please your customer, please try to find facts to support your hypothesis.
I know what you think: I’m a developer, I don’t need to take care of that. However, I believe deeply that your job is not only to code but to use your knowledge to bring value to the company you work with. You are an intelligent human being, you can as well give advises which can help your company growing. If your management is ready to listen to their employee and take their opinion in consideration, of course.
Trust me, you will feel even more useful at the end of the day if you adopt this mindset, and you will learn a lot.
When do you win?
Big surprise: It doesn’t matter if you’re personally wrong or right. What matters is, at the end of the discussion, that you need to take the good decisions for your company, at that point in time.
Winning an argument as a software developer means bringing (or discarding) ideas to ultimately create value for your company.
Don’t forget: recognizing that you’re wrong makes you more humble, show the weak spots in your knowledge and therefore is a good opportunity to learn. If you think you’re always right, you won’t learn anything from the debates you will have with your fellow colleagues. In return, they might think you’re a pretentious douche.
Every idea or technology can be potentially useful, it mainly depends what problem you’re trying to solve. Adapt your thoughts 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 or your client will thrive if you try to keep this mindset.
However, and this is a really important last point, there are limits to your engagement: if you know that your company is doing something illegal or if they push you to do something illegal or even amoral, it’s not about debates anymore. Just fly away and find a company you trust and share the values.