The Art of Debating for Software Developers
thevaluable.dev
thevaluable.dev
The article linked here is actually about the art of rhetoric: about convincing someone I'm right. And, as it happens, it's mostly about marshaling my arguments about why I'm right and biding my time. Those are good. But in a good debate, both I and the person I'm debating marshal our arguments.
The old slogan is true: we have two ears and only one mouth. Listen more, talk less.
My goal is to come out with a plan that works best. That almost always involves taking criticism and advice into consideration, and sometimes involves not doing things my way. Sometimes I'm even completely wrong. But sometimes I'm completely right. There's no way to know before having the "argument".
You are thinking of a very specific scenario of debate where knowledge is merely a set of observable/observed facts and everything in the discussion is fully described, strictly bounded and available for scrutiny.
In such a "sandbox" of logical positivism, sure, one can see a debate as an unfolding of consequences from logical primitives.
That's very far from what most actual real-world debates are like. There's typically a profound lack of facts, knowledge and experience. Deciding something like "how to proceed" with a business decision involves dabbling in a lot of uncertainty, subjectivity and emotional baggage from both sides. Subjectivity is often a dirty word amongst software developers but, outside of stackoverflow.com, it's fundamental to human experience and argument.
Though, it's possible to keep arguing after by challenging the internal consistency of the other person's assumptions. You can often win arguments by demonstrating that their set of assumptions leads to a illogical and contradictory result, or you can show how their assumptions prove something that they don't agree with.
My aim is always to try and understand a different perspective, because this forces me to account for that in my own perspective.
My mind can be unchanged or I can 'win' the argument and still have learned something new with this approach.
Of course the above is a big if. I don't think I've ever done it. But that is my goal.
Most of the time though you are right, I want to find the truth which might or might not be what I think it is.
I have, once. Or at least I came close. The lady had two arguments: vaccines, like most medicine, make our immune system weaker; and "they" put poisonous stuff in vaccines. I pointed out that (i) vaccines aren't a crutch that may relieve or replace our immune system, but a kind of kick in the butt designed to strengthen our immune system, and (ii) that yes, they put poison in it, because that's how we can ensure our body reacts to it and prepares itself for the real thing.
That was enough to cause her to reconsider her conspiracy thinking. I think one key here was to acknowledge one of her arguments (the poison thing). I also did not discuss regular drugs, so I could focus on vaccines. I did not deny drugs makes our immune system weaker, even though I don't think they do in most cases.
Turned out listening can be a rhetoric weapon as well as a learning tool.
Often times once a person feels listened to, they stop worrying about "being right" and are willing to make compromises, or even drop their demands entirely.
A great way to help someone see why you think their solution is wrong is to ask questions. "What happens if the user clicks X?" "How will the database handle the increased scale?" "What will be the costs of implementing that?" etc. etc. Just pure, calm curiosity.
But yes, even if you're in a debate where the sole purpose is to win, listening is important. Look at politicians during political debates -- they listen like hawks when it's not their turn. The reason is simple: you can't effectively negate an argument you haven't even heard. We're all smart people and capable of coming up with a million counterarguments to everything, but hearing EVERYTHING someone says is the really hard part, and is worth practicing.
I personally wish I could learn to do the reflexive listening thing more. Maybe I should practice with everyday conversations so that it happens habitually during heated conversations when your attention is on something that truly matters.
I also remember reading a book about camping. It had an interesting introduction, that talked about family camping. Although it talked about equipment and other important details, one bit talked about communicating with them. It basically said you should be saying "what do you think?" throughout all the planning and preparation. I saw it as the difference between hauling your family to the woods, and having a lot of participants out camping together.
Meditation helps me a lot to have this millisecond of "Wait. Don't say that and listen first.".
"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."
"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."
Or that they are wholly correct and I am wrong.
> about convincing someone I'm right.
Worth keeping in mind what one is trying to accomplish:
- do I want to convince (influence) the other person
- do I want to help find the best solution
- do I want to learn something
Regardless of mode, I think a critical skill / behavior is genuine curiosity.
Convincing people of anything at a company starts way before by building rapport with people and other techniques. It is largely proven than with most people it is your current standing, perceived intent and subtle speech/visual cues that are more important than the actual content.
Want make it more likely people agree with you? Try to be helpful, ensure people consistently think they are better off agreeing with you. Ensure people are safe investing in cooperation with you (so no talking behind their backs, ensure if somebody achieved something you will attribute it to them even if they are not present). Ensure you listen to people and they don't get impression you are welcoming their point of view. Let people know when you make mistakes (I like to use this as learning opportunities). Congratulate people on their achievements even small, but never do this if you are going to sound banal.
Do this and you might be able to convince people of about everything and even if you make some mistakes they will let it slide.
(If it felt like "How to win friends and influence people" then it wasn't an accident. Developers are like any other people and same timeless tips apply.)
I agree with you in theory, but in practice, sometimes, with some people, this strategy will tend to infinity on a time scale.
1) Try to be friendly, try to create a mentor/mentee relationship with them, and get on their good side. If that works, maybe they will be slightly receptive to what you say. Regardless of the outcome, though:
2) Ultimately just do what they say.
I know that's anathema to many people in the field -- and it was a damn hard lesson for me to learn -- but you have to understand when you're picking a fight, and who stands to lose. (Hint: you're picking a fight by disagreeing with an Ego Monster, and if you have less clout than them, you're going to lose.)
By losing, maybe you'll get less favorable work and less recognition. Or maybe they will eventually "manage you out" of the organization. But you will not get what you want in any sense of the word.
Swallow your pride, go along with it, and maybe look for a workplace that's more accepting of new ideas. There is no winning.
But as I said, it's very risky. You could lose your job. If the Ego Monster has a lot of clout, you might suffer permanent career damage. Think well before taking this approach. But it's the only one that offers any hope for your current workplace.
So many people, many of them younger, do not seem to realize there isn't an objective arbiter of what is right and wrong -- there's only politics -- and you aren't going to be rewarded for being right. And most people of higher level don't really give enough of a damn about your petty code problems (oh no, he likes inhertiance and I read something that asserts composition is better) to stick their neck out for you.
I meant it only for something big enough that it's threatening or damaging to the organization as a whole. That is, it's not just causing problems for you. It may not be right or wrong, but it's definitely better or worse, and not just for you. People above the Ego Monster care if the Ego Monster makes it harder for the team to deliver.
And why would it make it harder for the team to deliver? Because the Ego Monster doesn't listen, and isn't omniscient. That leads to the Ego Monster making dumb decisions - decisions that don't actually work in the real world.
But so many juniors are convinced they need to fight seniors and management based on things they read a medium article about. I try to tell them to stop on the internet all the time. I wonder if they ever actually listen.
Debate is structured and, importantly, proctored to adhere to a rigorous set of standards for which the participants have prepared. It is helpful on an individual level but often not a good way to inform decisions.
But what I have often found is that the best debater wins.
And some debaters are so good they can win both sides of a debate.
This wouldnt be that much of a problem if you assume verbal iq is an independent variable uniformly distributed through the population. But I have often found verbal iq is highly co-related with other biological traits and markers. This creates a biased situation where debates often lead to erroneous conclusions and bad results.
I actually have a considerably higher test verbal IQ than mathematical and have perfect verbal section test scores to show it. However, I used to really suck at debates because I was naïve and unpracticed.
I went through a few years of spending too much time on reddit, though, and now I can wallop most average people. The most important thing BY FAR is to immediately establish definitions and frame the debate. You force your opponent to operate in the tiny amount of air space that you've given them, and constrain them to talk about things that you've chosen so you probably know more about them.
> You force your opponent to operate in the tiny amount of air space that you've given them, and constrain them to talk about things that you've chosen so you probably know more about them.
You've got to respect and address any alternative framing that your "opponent" is operating under, they're not going to comply with an arbitrary framing of an argument that you provide, just because.
Now, you become an annoying ass when you try to turn every discussion into a debate, and try to win every time. Don't do that. Sometimes it's better to let other people win or just feel heard. But if you want to win, that's how you do it.
> ... you say "There's plenty of room to discuss those issues you brought up, but I'm still interested in your thoughts on my original question."
That pisses people off, it's seen as an aggressive move and can easily backfire.
Framing the debate is perhaps the most difficult task towards "winning" a debate.
Trying to "win" can definitely backfire, so you should do it sparingly. In truth, the only place I really debate people is on the internet, most visibly with my pro-Trump relatives on Facebook :).
However, the person I was responding to was talking about "how to win debates," and that's how you do it. Yes, if you want to win, you do need to be hard nosed and aggressive (I prefer gently guiding them down the garden path until they realize it's too late to turn back). Whether or not you should do it is a different point entirely, and to be frank, I completely agree with you there.
(Meta note: do you see how I'm actually making a belated attempt to frame the debate right here, and it's not necessarily as aggressive as I describe? Really sometimes it's just needed to establish clarity.)
Interestingly those type of people will rarely venture on message boards, because this requires a lot of reading and writing and they would rather spend their time on other pursuits(maybe more visual?). Its interesting to imagine the section of viewpoints that dont even get represented at this level.
If you're feeling verbally blocked it's probably more likely that your problem is some form of social anxiety. (That was mine.) If you become much more talkative when drunk, for instance, then the problem is inhibition.
You can meet plenty of garrulous people who can talk circles around you, but it doesn't mean they're necessarily bright.
Maybe it's art about debating software developers? You could probably write a good short story about it.
It is much better to just stay humble. Show your insecurities and lack of knowledge openly and early, you'll be surprised to see how people reactions change from hostile/confrontational to outright helpful.
But your comment totally convinced me, thanks. There's no need for strong opinions, even when weakly held. It adds nothing.
Amazing how a few sentences can do more than entire blog posts sometimes.
A long form article is more likely to try to make many points at the same time, some strong, some weak, some wrong ones.
Comments are usually short, making only one point. Furthermore they're sorted and filtered by popularity. This means that strong, pithy statements are displayed much more prominently.
Likewise this article could use some editing.
I like it!
I would argue it's possible to be serious about your convictions (i.e. take them to their conclusions), humble and open to being proven wrong.
We never have all the information, so we create opinions based on the available information we have. You can do this without being arrogant.
To me, changing your mind when presented with new evidence shows humility.
I was doing martial arts in school, and my sensei had me demonstrate some forms. Being new, I was very hesitant.
He was annoyed at this and explained that when I kept hesitating, I didn't complete a motion fully. He couldn't see what I was trying to do because I wouldn't commit to it. Thus he couldn't show me what I was doing wrong and teach me the correct way to do it.
"Strong opinions weakly held" is trying to address the problem of not committing to a position. It can manifest as not fully expressing your ideas, or adding unnecessarily qualifiers to them, or not following them to their conclusions.
The consequences can be you don't fully advocate your position, or someone with a different idea isn't able to identify the weaknesses in your argument.
> If you have a strong opinion, you look like a fool if you change your mind when evidence is shown to you.
If you present your views as mush, you can also sound like a fool. If you're citing a standard and say, "the standard says this, but I'm not really sure I read it correctly," you don't sound humble, you sound like you can't read.
If, otoh, you simply cite the standard, then your colleague is clear on where you're coming from. So now he can object that implementations don't follow it; the discussion can advance.
I think the problem you're getting at is someone staking their reputation unnecessarily on their views. You're right: that's a mistake. I've been in an argument over a fairly subjective design decision where one guy got frustrated and said, "look, my 20 years working with databases says we do it this way."
To avoid that, the key is to be specific; "we tried that on project X and it worked / didn't work, and this is very similar." Now it's not your reputation at stake, you're simply giving a factual account of your experience.
And sometimes the matter really is subjective or the data isn't great. If that's the case, you want to be clear about that uncertainty, "we just don't know because our data is crap." Then it becomes clear the team needs to put more resources into getting better information.
With people who have strong opinions and stick to them you can at least learn their opinions and adapt or fight once. If they change every week, you have to fight or adapt constantly. Last week you need to use x syntax wherever possible, this week you must not use it. And big deal about difference each time.
> With people who have strong opinions and stick to them you can at least learn their opinions and adapt or fight once. If they change every week, you have to fight or adapt constantly. Last week you need to use x syntax wherever possible, this week you must not use it. And big deal about difference each time.
If they are constantly changing their opinions back and forth based on whatever blog they read most recently, those aren't strong opinions weakly held. They're just weak opinions, strongly advocated (or strongly enforced, depending on your co-worker's authority).
Also, if they are privileging opinionated blog posts over the arguments of their colleagues, the solution is simple: start a blog.
For example, if you have very narrow job titles and roles in a team ("he is our DevOps, she is our architect"...) everyone will have to defend their role, often trying to sound infallible.
If instead you make the whole team responsible for all team tasks, everyone will be more open to leveraging everyone else's suggestions.
Politicians, for example, are masters in using fallacies to make arguments that less educated people find persuasive.
Here's a good video about argument types:
https://www.youtube.com/watch?v=NKEhdsnKKHs
And this one (and follow ups) about logical fallacies:
https://www.youtube.com/watch?v=8qb-h0sXkH4
Knowing these I think is more important than using the more vague advice this blog post mentions.
On contrast, the article is more about maintaining relations and work culture than deciding a debate, which is indeed vague, but at least as valuable.
Not only your opponent's but your own also! That's very important... knowing the fallacies you're less likely to use them, which I think many people do out of their ignorance of the topic.
The truth of this is probably apparent to anyone who has ever worked through a typical Philosophy 101 midterm. On the exam you apply your mind to spotting the problem or problems with an argument first, and then compare that problem to an index of goofy latin names for fallacies that you've perhaps memorized. Knowing the names of fallacies is only important to the people who care about the names of fallacies (a category that, strangely, does not include the philosophy professors administering these exams).
> 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.
Software development has an ego problem, and I wish there were more resources out there to address it.
I think this is a good point. Not everybody wants to debate and reach consensus if they can find other means.
Also, some people don't like debating because it makes them uncomfortable for some reason. Debating should be done in good faith with the goal of reaching the best outcome, but some people take it personally and see it as an attack against themselves and their values.
On an unrelated note, the page uses:
hyphens: auto;
text-align: justify;The only things which helped me was meditation and trying, again and again, to breath and trying calm done when I see myself too passionate. But again, I think it's really personal.
Thanks for your comment on the formatting! I'll try to justify the text see how it goes.
Well, that was unexpected
When I got to my first job, I was hugely fortunate to have colleagues that wouldn't judge anyone for their views/opinions, whether right or wrong (technically, obviously they were expected to be respectful). As such I found myself learning and growing so to such a greater extent, and quicker, in those first couple of years of employment.
It's something that goes both ways, if you're respectful and positive of colleagues who may be wrong, you'll help them to learn and develop, which in turn will contribute to a better team overall, more collaborative and more competent. I think it's especially important to try and include the quiet ones, again they may be wrong, but as long as you impress that it's fine to be wrong and work with them to improve their knowledge and understanding, that bit of extra effort will go so far.
This does assume the argument is being conducted in good faith though. If it's not, you'll only irritate the opponent as their logic gaps and lack of good faith will become blindingly clear.
One of the smartest ways I know to approach a discussion with insight in mind, is called steelmanning. It is the opposite of strawmanning. In strawmanning you attack altered, weakened versions of the other side's argument. In steelmanning you attack its best, most convincing version. You even seek to corroborate the argument and verify it with your opponent before attacking it. The benefit is that you genuinely have to understand the other's arguments before arguing against them.
The following blogpost explains it very well. https://themerelyreal.wordpress.com/2012/12/07/steelmanning/
There are situations where you are attacked personally and need to respond. Whether the attack is direct or through sleazy implications. This is not some kind of rare occurrence, people who try to use debate to either show/gain dominance, get equal or just try to win by sleazy tactics exists. Pretending this does not exists does not make you win the debate, it makes the sleaze personal attack stick and makes you look bad (less capable or weak).
And I know, because when I was younger I listened to advice like this and that is exactly what happened.
Nowdays, I call it kindergarten rules of behavior. They sound good and are sort of what adults say to kids. Except that they assume that you are put in an idealized situation. They miss crucial "how to recognize and react when the sleazy tactic was used" and instead pretend it is not happening.
> 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.
The author sounds to me exactly like the guy who likes to run talkshops, for the sake of talkshops.
Your ideas work, if you can push them through, largely regardless of their merit.
For example, assuming easy access to elite staff (dev & users) and having lots of time for perfecting a domain model is often unrealistic in business. Getting the "right" answer seems more important to them than resource constraints a typical business faces. They are perfectionists in their models and tools but not perfectionists in resource management because they either don't have enough practice there, or are rusty.
One has to agree on resource metrics up front, otherwise the debate won't get anywhere.
Or in other words, argument from authority/popularity over ideas / merit. This is the opposite of good debate, even more so with the dubious distinction of a tech "influencer" being an authority.
By all means, borrow arguments if they are good, but please do not promote them because of who said them.
1. It ensures I actually understand the other person
2. The other side is more likely to listen
This is wrong. If your company is still using tabs, it is already at a competitive disadvantage. If you force me to use tabs, I will be unhappy about that, because it greatly affects the mechanical part of my work. I will perform worse at my job and probably create debates about this very issue, all the time. I insist on spaces. I am the majority of programmers, because the ergonomic benefits of spaces are obvious.
If, for some odd reason, you have team members that insist on tabs - a position that I have never encountered in the wild - then make them change, not me.
The wise thing would be to find another job, because this codebase and the company that maintains it is a sinking ship.
(POSIX 'make' insists on tabs, I wonder what you'd make of that)