Newsletter #4: Logical Fallacies
Did you receive this as a forward? Sign up here to get your own copy next time! You can also access our archives at https://tipsfortechnicalwriting.blogspot.com.
Tips for Technical Writing is brought to you by a trio of technical people (a chemist, an urban planner, and an engineer) turned wordsmiths with expertise in a variety of technical disciplines. You can learn more about us here: ChristaBedwin.com, ScribeTW.com, and WordsWithPurpose.ca .
Newsletter #4: Correlation vs. Causation, Hasty Generalizations, Other Logical Fallacies, and the Misuse of Data
We're covering a lot of territory this time. There's a lot to say about logical fallacies. This time we zoom in on a few that we come across frequently, and provide some advice on how to avoid falling into the trap!
from ERIN GUTSCHE: On The Correlation–Causation Conundrum
Let’s start by looking at the following chart. What do you see?
This chart was developed by Tyler Vigen using data from the U.S. Department of Agriculture and the National Science Foundation. It appears to show a correlation between mozzarella cheese consumption and the number of civil engineering doctorates awarded annually. Does that seem right?Enter the “correlation does not imply causation” principle. This principle tells us that two similar variables do not necessarily share a causal relationship. This is a tricky fallacy; it’s easy to believe that a cause-and-effect relationship exists when the pattern looks so obvious!
As technical people, we must be aware of what the data is saying versus what the data might be saying. We also need to be careful with how we present that information to our readers. For example, we should be mindful of using absolutes: “Eating mozzarella cheese causes civil engineering students to become smarter.” Conversely, “A cause-and-effect relationship may exist between mozzarella cheese consumption and civil engineering doctorates.”
Technical writers should be concerned with presenting the facts. For those cases where we don’t have all the answers, we need to be forthright in saying so. In no way should we ever seek to deceive our readers or manipulate the interpretation of data to our advantage.
from LISA ORCHARD - On Hasty Generalizations
As technical writers, hasty generalizations are something to avoid at all costs. Our work is fact-based, and a leap in logic can bury important information, and blur the true meaning of the data. Ultimately, it can have a big impact on decision-makers’ responses to serious challenges in our society.
Technical writers present information that is based on evidence. Our work is not drawn from our personal experience or opinions, nor should it be. 
Let’s take an example from urban planning. Professional staff conduct a transportation survey of traffic on a major road during the morning rush hours to build a case for new bike lanes and wider sidewalks. The survey finds that 70% of people are driving, 20% are cycling, and 10% are walking. A city councillor concludes that most people prefer to drive to work, so more money should be spent on improving conditions for drivers. Does the study support the councillor’s statement?
Of course not! The councillor made a hasty generalization. This is problematic for a few reasons:
- The conclusion misleads the public on the outcome of a technically valid study;
- The reasons that most people are driving aren’t likely to be further explored and addressed (e.g. that cyclists don’t feel safe in mixed traffic);
- Public money is likely to be spent, and likely on the wrong, or at least unproven, thing; and
- Staff are not able to advance their policy goal of a sustainable and healthy city.
The hasty generalization dodges the complexity of an important issue. As the technical writer drafting the recommendations report, a fair statement would be, “The survey found that there are more people driving than cycling or walking on this major road during rush hour”. That’s it. This is something the professional staff can then build on.
As technical writers, we often have to push our clients to clarify what they mean. When writing about a controversial subject, step back for a moment to think how the technical work was done. Consider its purpose and scope. Look at the sample size. Focus on the results, not opinions about those results.
How we frame the conclusions from data can lead to very different policy outcomes that affect all of us. Be on the lookout for hasty generalizations that get in the way of you delivering a precise, clear, and accurate document to your client!
from CHRISTA BEDWIN: On Logical Fallacies and Data Abuse
The trouble with logical fallacies is they sound so very true, but of course they're completely false. They are extremely effective, but unethical, methods of persuasion. We are seeing a lot of these fallacies lately in relation to the pandemic.
And how can we refute the ideas people read on the internet? They seem so appealing, so apparently true. For the majority of people who prefer to read memes instead of scientific papers, short words, graphics, and absolutisms seem more clear, sincere, and familiar than long paragraphs full of unfamiliar words and uncertainties. And yet true science is always a bit uncertain -- we scientists, by our training, always state things that way. But that way of talking is the exact opposite of what feels good to non-scientists.
If you are interested in logical fallacies and persuasion, you can watch the recording of this Persuasive Writing webinar for free: https://eegs.ok.ubc.ca/non-degree-programs/past-webinars/
If you'd prefer cartoons, there is a nice cartoon discussion of 8 basic types of logical fallacies at https://owl.excelsior.edu/argument-and-critical-thinking/logical-fallacies/
We all know that data can be abused, and we usually blame it on politically motivated parties. However, sloppy science and math can lead to false impressions and errors in logic, and even cause governments to come up with ridiculous policies. Let's talk about being honest with your Significant Digits.
If you forget how to do calculations with sensible proper significant digits, the following article from the European Association of Science Editors provides a nice refresher course, with several examples.
https://ese.arphahub.com/article/50999/list/13/
You may have also seen high-profile cases in the news about forensic data and whether murderers can be convicted or not, based on the precision and accuracy of laboratory evidence. In this case, it's important to know whether our accuracy in the lab is greater than the uncertainty. A positive or negative result may be useless if the range of error is large.
Implying more precision than we actually know can also lead to poor decision-making, and over-reporting of data and precision can also serve as a distraction from the required action. For example, right now, I am seeing people flounder around trying to understand information about vaccines and infection rates and make their own choices about risks, and whether this vaccine or that vaccine might be better, and what percent of risk and death makes it okay to open the restaurants again. The news is just packed with numbers that may, after all, be plucked from thin air.
By contrast, some governments and people don't find any number above zero acceptable, and math doesn't need to come into the mask law risk analysis at all. Safe is safe and the acceptable case load will be zero, and everybody keeps working together to strive towards that. It's an extremely broad brush on the significant digits, but an ethically appropriate one for the culture in maritime Canada, New Zealand, and a few other rare places. Interestingly, it's both the intellectually simplest solution, and the one that seems to leave the least room for logical fallacies to take over society and make a mess. A rare combo!
If you'd like some more goofy graph fun, there are more oddball correlation graphs on tylervigen.com.
Is there a topic you'd like us to cover? Email us at tips4techwriting@gmail.com.
Missed last week's newsletter? Access our archives at https://tipsfortechnicalwriting.blogspot.com.
Comments
Post a Comment