This handbook takes you on a journey from fundamental logical principles to their practical applications in software development, scientific reasoning, and critical thinking.

Whether you're a high school student learning to think more clearly, a professional debugging complex systems, or simply someone curious about how sound reasoning works, this handbook provides tools for sharper, more reliable thinking.

What We’ll Cover:

Part I: Foundational Theory

We start with the bedrock of formal logic – understanding implications, truth tables, and the core rules of reasoning.

You'll learn the scaffolding for everything that follows:

• How "if-then" statements actually work (spoiler: it's not always intuitive!)

• The power of truth tables to map all possible scenarios

• Why some arguments are valid while others are logical fallacies

• The elegant relationship between Modus Ponens, Modus Tollens, and Contrapositives

Part II: Practical Applications

Here's where logic comes alive in tangible ways:

In Software Development:

• How debugging mirrors logical reasoning, and why your tests might be lying to you

• The logic behind Test-Driven Development and Mutation Testing

In Scientific Thinking:

• Karl Popper's falsification principle and why it matters beyond academia

• How Hypothesis Testing is just statistics meets Modus Tollens

In Everyday Reasoning:

• Spotting logical fallacies in arguments, media, and your thinking

• The art of considering multiple causal paths instead of jumping to conclusions

Part III: Philosophical Depths

The final section confronts the beautiful complexity of applying pure logic to an impure world:

• Why perfect "if-and-only-if" relationships are the goal but rarely achievable

• How modern software systems hide their complexity

• The butterfly effect of bugs and why root cause analysis is often harder than it seems

• Formal verification tools: from Prolog to Coq to TLA+

What You'll Gain

For Students:

• Critical thinking superpowers: Learn to spot flawed reasoning in arguments, social media, and news

• Academic advantage: These concepts appear in debates, philosophy, computer science, mathematics, and statistics

For Software Engineers:

• Debugging mastery: Modus Tollens for debugging: "If the output is wrong, what could cause it?"

• Testing philosophy: Move beyond "make the tests pass" to "prove the code is correct"

• Problem analysis: Avoid jumping to solutions before understanding the real problem

• System design: Think more rigorously about failure modes and edge cases, evaluate cause-and-effect relationships in complex systems

• Communication and career growth: Present arguments more clearly and persuasively, gain logical thinking skills that separate senior engineers from juniors

For Scientists:

• Experimental design: Strengthen your understanding of hypothesis testing and falsifiability

• Peer review: Better evaluate the logical soundness of research claims

• Grant writing: Structure arguments more persuasively using solid logical foundations

Pre-requisites

I’ll introduce code samples starting in the second half of the article, so knowing a programming language would be helpful. The concepts in this article are programming language-agnostic, but I’ve used Python throughout for readability.

No prior formal logic or philosophy background is strictly necessary, but the following will let you reap the most benefits from this article:

• Experience in testing and debugging during software development.

• Know what REPL (Read-Evaluate-Print-Loop) is if you want to try the Proof Assistants.

• Knowledge of logical operators (NOT, AND, OR), and the fact that they take 1 or 2 boolean values as input and return a single boolean value as output.

• Basic Algebraic Thinking: representing statements as variables (P, Q), the concept of NOT (¬) as an inversion of statements, and the concept that different input combinations can reach the same output.

• Exposure to deductive reasoning, where inferences are made based on some facts, and fallacies, which are some ways arguments can be flawed.

• Willingness to engage in conceptual back-and-forth between concrete English examples and abstract logical symbols.

• Holding possibly conflicting ideas between the ideal logic world and the impure real world.

• Openness to challenging intuition and following logical rules before applying your real-world experience.

Table of Contents

1. An Introduction to Logic

2. Truth Tables: Mapping All Possibilities

3. Contrapositives, Modus Ponens, Modus Tollens

4. The Origin of P⟹Q: Science and Reality

5. Revisiting Argument Forms: Valid Inferences and Common Fallacies

6. Denying the Antecedent: A Database Example

7. Assigning Real-World Meanings to Logic

8. Applying Logic to Software Testing

9. A Closer Look at Testing

10. Revisiting the Four Statements for Coding

11. The Missing Ingredient - If and Only If

12. Mutation Testing: Testing the Tests

13. Toward If-and-Only-If Confidence

14. Real-World Challenges

15. Glimmers of Hope: Tools and Practices for Clarity

16. The Power of Falsification in Testing

17. Proof Assistants

18. Food for Thought

19. Q.E.D.: The Enduring Power of Logic in an Uncertain World

20. Resources

21. Glossary

An Introduction to Logic

Imagine that the following statement is True:

If you are a coding instructor, then you have a job.

Now, do these make sense?

1. You have no job, so you are not a coding instructor

2. You have a job, so you are a coding instructor

3. You are not a coding instructor, so you have no job

Interpretations

Based on logic:

• Statement 1 is correct.

• Statement 2 is wrong because you may have other jobs without being a coding instructor.

• Statement 3 is wrong because you may or may not have a job, and as before, you may have other jobs without being a coding instructor.

Growing complexity

These statements grow increasingly complex due to:

• Changing from 2 valid statements to 2 invalid conclusions

• Moving from a clear job status (1, 2) to uncertainty about job existence or type (3).

Let’s get familiar with some notation before seeing how Truth tables help manage this complexity.

Notations

Truth Tables: Mapping All Possibilities

What is a Truth Table?

A truth table is a powerful tool in logic that helps us determine the overall truth or falsity of a compound logical statement. It does this by systematically listing all possible combinations of truth values (True or False) for its individual component propositions.

For every way the "inputs" (our propositions like P and Q) can be true or false, the truth table shows you the precise "output" (the truth value of the entire logical statement, such as P⟹Q).

Why are Truth Tables Helpful?

Truth tables offer critical benefits for clear thinking:

• Clarity and precision: They eliminate ambiguity by explicitly showing the outcome for every single scenario.

• Systematic analysis: They ensure no possible combination is missed, which is vital for sound reasoning.

• Foundation for understanding: They define how logical rules work, forming the bedrock for analyzing more complex arguments in any domain.

How to Read Our First Truth Table:

Let's examine the truth table for the implication P⟹Q ("If P then Q").

Each row represents a unique scenario, combining the truth values of P and Q to show the resulting truth value of P⟹Q.

Let's break down each row:

• P and Q Columns: These show the input truth values (True or False) for our two propositions. Since each can be one of two values, we have 2×2 = 4 unique combinations, filling all four rows.

• P ⟹ Q Column: This is the output truth value of the "If P then Q" statement for each combination of inputs P and Q.

  • Row 1: P is True, Q is True.

    • If P is true (you are a coding instructor) and Q is also true (you have a job), then the implication P⟹Q is True. (The "If...then..." statement holds).

    • This row is key for Modus Ponens.

  • Row 2: P is True, Q is False

    • If P is true (you are a coding instructor) but Q is false (you have a job), then the implication P⟹Q is False. This is the only scenario that disproves an "if-then" statement.

    • This row is key for Falsifiability.

  • Row 3: P is False, Q is True.

    • If P is False (you are not a coding instructor) but Q is True (you have a job), then the implication P⟹Q is still considered True. This can seem counter-intuitive.

    • The reason is that the implication statement only makes a claim about what happens when P is true. If P is false, the implication's claim isn't tested, so it is considered vacuously true.

  • Row 4: P is False, Q is False.

    • If P is False (you are not a coding instructor) and Q is False (you have no job), then the implication P⟹Q is also considered True.

    • Similar to Row 3, since the initial condition (P) was false, the implication's truth value remains True, as it hasn't been disproven.

    • This row is key for Modus Tollens.

The "Used In" column serves as a preview of the specific logical arguments or concepts that rely on each row's behavior, which we will explore in detail later.

Understanding the Implication (P⟹Q) Deeper

Most programmers are familiar with truth tables from logical operators like AND (∧), OR (∨), and NOT (¬), where they define the output based on combinations of inputs.

The implication (P⟹Q) works similarly, its output is defined by the rules of propositional logic, not by any real-world causal relationship or your “common sense”. For any given pair of inputs for P and Q, the result of P⟹Q is fixed.

If this feels counter-intuitive, consider that mathematical logic, like any formal system, is built upon agreed-upon axioms. These basic accepted truths allow us to construct complex systems of ideas. If later found ineffective or contradictory, these axioms can be redefined, or a new system can be developed.

In formal logic, this implication is also defined as being logically equivalent to "NOT P OR Q" (¬P∨Q).

This is the fundamental logical rule that dictates why, if P is False, P⟹Q is always True, regardless of Q's truth value. You can also understand this using the NOT P OR Q form.

• If P is False, that means NOT P is True.

• Using the rules of Logical operation:

  • True (Not P) OR True (Q) is True (NOT P OR Q)

  • True (Not P) OR False (Q) is True (NOT P OR Q)

  • NOT P OR Q is True regardless of what Q is.

The above explains rows 3 and 4 of the truth table from the NOT P OR Q form. As an exercise, you can apply the inputs (P, Q) from the first two rows of the truth table to NOT P OR Q to arrive at the same results defined in the P⟹Q column.

This formal definition allows us to use implication to reason in powerful ways, not just in the "forward" direction (P⟹Q, leading to Modus Ponens), but also in a crucial "backward" direction.

This backward form (Contrapositive) involves swapping and negating the propositions (¬Q⟹¬P).

For example, if "If you are a coding instructor, then you have a job" is true, then it must also be true that "If you have no job (¬Q), then you are not a coding instructor (¬P). ".

This "backward" way of reasoning, which underpins Modus Tollens, is a powerful tool for inferring conclusions from observed outcomes.

We'll explore the Contrapositive and two argument forms (Modus Ponens, Modus Tollens) in detail next.

Contrapositives, Modus Ponens, Modus Tollens

We've explored the fundamental implication (P⟹Q) and how truth tables reveal its behavior.

Now, we explore reasoning tools that build upon this foundation: Modus Ponens, Modus Tollens, and the concept of Contrapositives. These are bedrock principles of valid argument and efficient logical thought.

What is Logical Equivalence?

Before we dive into these specific concepts, let's clarify what logical equivalence means. Two statements are logically equivalent if they always have the same truth value under all possible circumstances. In simpler terms, if one statement is true, the other is always true. If one is false, the other is always false. They are, in essence, different ways of saying the same logical thing.

Understanding logical equivalence is incredibly useful. It:

• Simplifies logic: It allows us to substitute one statement for another without changing the truth of an argument, which simplifies complex proofs and reasoning.

• Reduces complexity: In fields like circuit design, it can lead to fewer physical gates.

• Maintains software correctness: In programming, it helps maintain code's correctness during refactoring and debugging, especially when simplifying conditional statements, by ensuring the transformed code still behaves identically to the original under all conditions.

The Contrapositive: An Equivalent Implication

One of the most important logical equivalences involves the Contrapositive of an implication. The contrapositive of an "If P then Q" (P⟹Q) statement is "If not Q, then not P" (¬Q⟹¬P).

You might intuitively question how "If P then Q" could be logically the same as "If not Q then not P." Let's demonstrate this using a truth table.

We'll start with our familiar P and Q columns and the P⟹Q implication. Then, we'll add columns for ¬P (Not P) and ¬Q (Not Q), and finally, the implication for the contrapositive, ¬Q⟹¬P.

Let's look at how the truth table explicitly shows this equivalence:

Explanation of the table

1. P, Q, P ⟹ Q (Columns 1-3): These are our standard propositions and the implication we've already defined.

2. ¬P (Column 4): This column simply shows the negation (opposite truth value) of the P column. If P is True, ¬P is False, and vice-versa.

3. ¬Q (Column 5): Similarly, this column shows the negation of the Q column.

4. ¬Q ⟹ ¬P (Column 6): This is the contrapositive. We apply the same rules for implication that we learned earlier, but now using ¬Q as our "if" part and ¬P as our "then" part. For example, in Row 2, ¬Q is True and ¬P is False. According to the implication rule (True ⟹ False yields False), the result for ¬Q⟹¬P is False.

5. The Proof of Equivalence: Now, compare Column 3 (P⟹Q) with Column 6 (¬Q⟹¬P). You'll notice that for every single row, their truth values are identical! When P⟹Q is True, ¬Q⟹¬P is also True. When P⟹Q is False, ¬Q⟹¬P is also False. This perfectly illustrates why they are logically equivalent.

So, "If you are a coding instructor, then you have a job" (P⟹Q) is logically the same as saying "If you have no job, then you are not a coding instructor" (¬Q⟹¬P). They convey the same information about the relationship between being a coding instructor and having a job.

How Modus Ponens and Modus Tollens Relate to Implication

Having defined logical equivalence and the contrapositive, we can now precisely understand two of the most fundamental and valid forms of deductive argument: Modus Ponens and Modus Tollens. Both of these argument forms rely on a core premise that an implication (P⟹Q) is true, and then use additional information to draw a valid conclusion.

1. Modus Ponens (Affirming the Antecedent): This is often considered the most intuitive and direct form of logical inference. It works in the "forward" direction of the implication.

   • Premise 1: We are given that the implication is true: If P, then Q (P⟹Q).

   • Premise 2: We are also given that the "if" part, the antecedent, is true: P is true.

   • Conclusion: Therefore, we can validly infer that the "then" part, the consequent, must also be true: Q is true.

Example:

• Premise 1: If it is raining (P), then the ground is wet (Q).

• Premise 2: It is raining (P).

• Conclusion: Therefore, the ground is wet (Q).

This directly corresponds to Row 1 (True, True) of our truth table for P⟹Q.

2. Modus Tollens (Denying the Consequent): This argument form works in the "backward" direction and relies directly on the logical equivalence of an implication and its contrapositive.

   • Premise 1: We are given that the implication is true: If P, then Q (P⟹Q).

   • Premise 2: We are also given that the "then" part, the consequent, is false: Not Q (¬Q).

   • Conclusion: Therefore, we can validly infer that the "if" part, the antecedent, must also be false: Not P (¬P).

Example:

• Premise 1: If it is raining (P), then the ground is wet (Q).

• Premise 2: The ground is not wet (¬Q).

• Conclusion: Therefore, it is not raining (¬P).

Modus Tollens is valid because if P⟹Q is true, its contrapositive (¬Q⟹¬P) must also be true. Applying Modus Ponens to this contrapositive (with ¬Q as our second premise) directly leads to the conclusion ¬P. This corresponds to Row 4 (False, False) of our original truth table for P⟹Q, where P and Q are both false but the implication is still true.

These two argument forms are central to rigorous deductive reasoning, allowing us to draw certain conclusions based on the truth of implications and related facts.

The Origin of P⟹Q: Science and Reality

In science, hypotheses often take the form "If P, then Q" where P is a cause and Q is its predicted effect –for example, "If a drug is given (P), then symptoms improve (Q)."

Ideally, P is controllable, as in experimental studies, but even in observational studies, P must be clearly defined and measurable.

Each experiment yields one observation, reflecting one of four possible truth-value combinations of P and Q.

The Falsifying Case in Science and Logic

Each experiment produces a single observation – one of the four possible combinations of P and Q.

• If P=True, Q=False is observed (row 2 of the truth table), the hypothesis is falsified

• In all other cases, the hypothesis is not falsified (yet)

Thus:

• If all observations fall in the 3 truth-preserving rows, the hypothesis remains viable.

• If at least one experiment yields P=True, Q=False, we either:

  • Conclude falsification, or

  • Re-examine the experiment and attempt replication before accepting falsification.

The Power of the Falsifying Case

In the Logical World

The falsifying case is not useful for inference with Modus Ponens or Modus Tollens because these two argument forms require starting with P⟹Q = True. I’ll explain both arguments in detail later.

But the falsifying case is useful for showing counterexamples to disprove the implication, or proof by contradiction.

In the Real Scientific world

The falsifying case embodies Falsifiability – a crucial concept in Science.

In so far as a scientific statement speaks about reality, it must be falsifiable: and in so far as it is not falsifiable, it does not speak about reality.

— Karl R. Popper, The Logic of Scientifc Discovery

Scientific theories come about through hypotheses that are continually tested and survive attempts at falsification.

Popperian Falsification and Hypothesis Testing

These two approaches, one philosophical and one statistical, are distinct but complementary in the scientific method.

• Popperian Falsification starts with a scientific hypothesis (for example, "P has an effect on Q"). Its core aim is to actively seek evidence that would disprove this hypothesis. If such disproving evidence is found, the hypothesis is falsified.

• Statistical Hypothesis Testing begins with a null hypothesis (H0​) (for example, "P has no effect on Q"). Its goal is to determine if the collected data provides sufficiently extreme evidence to reject this null hypothesis.

If the null hypothesis is rejected, it provides statistical support for the alternative hypothesis (that P does have an effect on Q). This statistically supported hypothesis then becomes a stronger candidate, continually subjected to further Popperian attempts at falsification through new experiments and observations.

The Nuance: Implication is Not Causality

P⟹Q does not inherently imply that P causes Q.

Consider these examples:

• "If the fire alarm is sounding, then there is smoke." The alarm doesn't cause the smoke.

• "If a colleague screams during code review, then the code is bad." Does the screaming cause the bad code, or merely reveal it? (Perhaps sometimes both! 😰)

Causality is a real-world concept crucial for making informed decisions, predicting outcomes, and inferring the underlying reasons for events.

It's often central to predictive modeling and supervised learning in data science, where the target variable is the effect and the predictors are proposed causes. A common pitfall here is data leakage, where predictors are inadvertently influenced by (or are themselves effects of) the target, violating the causal assumption.

Logic, however, doesn't model time, mechanisms, or interventions. It only cares about truth values and formal structure. Logic defines what is true based on premises, not what makes something true in a causal sense.

Revisiting Argument Forms: Valid Inferences and Common Fallacies

We've now established the rules of implication, understood logical equivalence, and learned about two powerful, valid argument forms: Modus Ponens and Modus Tollens. But when we try to reason using "if-then" statements, it's easy to fall into common logical traps.

In this section, we'll systematically revisit the four common ways we might try to draw conclusions from an implication P⟹Q (If you are a coding instructor, then you have a job) introduced at the start of the handbook.

Two are valid arguments (Modus Ponens and Modus Tollens), and two are common logical fallacies. Understanding the differences is crucial for sound reasoning.

First, let's quickly define the parts of an "if-then" condition:

• Antecedent: The "if" part of the condition (P).

• Consequent: The "then" part of the condition (Q).

Now, let's examine these four argument forms, using our knowledge of truth tables and the coding instructor example.

Affirming the Antecedent (Modus Ponens)

This is the first valid argument form we discussed. It's called "affirming the antecedent" because it asserts the truth of the "if" part (the antecedent, P) to conclude the "then" part (the consequent, Q).

• Argument Form:

  1. If P, then Q (P⟹Q)

  2. P is true.

  3. Therefore, Q is true.

• Examples:

  • You are a coding instructor (P), so you have a job (Q).

  • You provided invalid input data (P), so the code will show an error (Q).

• Interpretation: This argument directly aligns with Row 1 (P=True, Q=True) of our truth table, where the implication holds true. It's often the most intuitive form of logical deduction. In programming, it's natural to expect bad input to lead to error messages if the code is designed correctly.

Denying the Consequent (Modus Tollens)

This is the second valid argument form. It's called "denying the consequent" because it asserts the falsity of the "then" part (the consequent, ¬Q) to conclude the falsity of the "if" part (the antecedent, ¬P). As we learned, Modus Tollens derives its validity from the logical equivalence of P⟹Q and its contrapositive (¬Q⟹¬P).

• Argument Form:

  1. If P, then Q (P⟹Q)

  2. Not Q is true (¬Q).

  3. Therefore, Not P is true (¬P).

• Examples:

  • You have no job (¬Q), so you are not a coding instructor (¬P).

  • There are no error messages (¬Q), so the input data is valid (¬P)

• Interpretation: This argument corresponds to Row 4 (P=False, Q=False) of our truth table, where P⟹Q is true, and both P and Q are false. This form of reasoning is critical for skillful debugging, allowing you to infer reasonably true conclusions about the cause (P) from observations of the outcome (Q), assuming your program logic (P⟹Q) holds true.

Affirming the Consequent (Fallacy)

Now we move to the common pitfalls. This is an invalid argument form where we attempt to conclude that the antecedent (P) is true simply because the consequent (Q) is true. It's a fallacy because the truth of Q does not guarantee the truth of P, as Q could have been caused by something other than P.

• Argument Form (Invalid):

  1. If P, then Q (P⟹Q)

  2. Q is true.

  3. Therefore, P is true. (**Incorrect inference!**🚨)

• Examples:

  • You have a job (Q), so you are a coding instructor (P).

    • Incorrect: You could have many other jobs.

  • The code showed an error (Q), so you provided invalid data (P).

    • Incorrect: Other things besides invalid data can cause errors.

• Interpretation: This fallacy highlights the difference between a one-to-one and a one-to-many relationship. Looking at our truth table, when P⟹Q is True and Q is True, P could be True (Row 1) or False (Row 3). The argument mistakenly concludes that P must always be True. The uncertainty arises because observing Q as True doesn't uniquely point to P as the cause – there could be many other reasons or paths that lead to Q.

  • Think of walking down a forest path, unaware that another trail has merged into yours from behind you. When retracing your steps in reverse, you encounter a split (Q) at that merge and feel disoriented, unsure which path leads back to your start point (P). Just as multiple paths can converge on the same point, multiple causes can produce the same outcome.

Denying the Antecedent (Fallacy)

This is another invalid argument form. Here, we attempt to conclude that the consequent (Q) is false simply because the antecedent (P) is false. It's a fallacy because P being false does not guarantee that Q will also be false. Q could still be true for other reasons, or the implication might not cover all scenarios where Q occurs.

• Argument Form (Invalid):

  1. If P, then Q (P⟹Q)

  2. Not P is true (¬P).

  3. Therefore, Not Q is true (¬Q). (**Incorrect inference!**🚨)

• Examples:

  • You are not a coding instructor (¬P), so you have no job (¬Q).

    • Incorrect: You could have a different job.

  • You provided valid data (¬P), so you have no error (¬Q).

    • Incorrect: Valid data doesn't guarantee no error. Other factors like network issues, memory leaks, or non-idempotent operations can still cause errors.

• Interpretation: Similar to Affirming the Consequent, this fallacy stems from incorrectly assuming a unique relationship. From our truth table, when P⟹Q is True and P is False, Q could be True (Row 3) or False (Row 4). The argument mistakenly concludes Q must always be False.

Both of these fallacies (Affirming the Consequent and Denying the Antecedent) creep into our thinking when we prematurely assume a single cause for an effect. In complex real-world systems, many factors can lead to an outcome, and narrowing your thinking too soon can lead to missed bugs or incorrect conclusions.

Fallacies and Implication: A Prerequisite

Both the fallacy of affirming the consequent and denying the antecedent assume the underlying implication (P⟹Q) is true.

If this implication is false from the start, there's no logical argument to be made, and thus, no fallacy to speak of.

Exercise: Identifying an Argument Form

Which of the 4 forms of argument is this?

• Penguins can’t fly. I can’t fly. Therefore, I’m a penguin.

Hint: Rephrase the first statement into an if-then form.

Denying the Antecedent: A Database Example

We just saw that Denying the Antecedent is a logical fallacy, meaning that even if the initial implication (P⟹Q) is true, concluding ¬Q from ¬P is not a valid inference. To make this abstract concept concrete, and to illustrate why this fallacy can be particularly dangerous in real-world systems like software, let's explore a practical example involving a database.

The implication: If the database is down (P), we’ll see a connection timeout error (Q).

Now, applying the fallacy of Denying the Antecedent, we might incorrectly conclude: If the database is not down (¬P), we will not see a connection timeout error (¬Q). ❌

But even if the database itself is perfectly operational and "not down," you might still encounter a connection timeout error. This could happen due to a variety of other, independent reasons, such as:

• Network problems

• Firewall rules

• The database is up but extremely slow

• The query engine is stuck

This specific example of multiple potential causes for a "timeout" highlights a broader, critical skill in software development: thorough case analysis.

This is precisely why technical assessments, especially in areas like algorithms and system design, frequently demand that you consider exhaustive possibilities. For instance, you are often asked to handle base and recursive cases in dynamic programming, or to ensure mutually exclusive and collectively exhaustive coverage when grouping multiple scenarios in problems like interval merging.

Such strong case analysis is vital for minimizing bugs and cultivating an open-minded approach to considering multiple causal paths, driven by experience, curiosity, and a dedication to craftsmanship.

But even perfect case analysis doesn't guarantee a correct implementation. Weak language mastery or mistaken assumptions can still lead to errors, making tests a crucial last line of defense.

Before jumping into applying logic to software testing, let’s practice our agility in conceptually switching between real-world concepts in English and symbols in logic.

Assigning Real-World Meanings to Logic

We must define what P, Q, and P⟹Q refer to when applying logical theory to real-world concepts.

How we define these variables affects our truth tables.

For example:

• If P means "valid input," then ¬P means "invalid input."

• If P means "invalid input," then ¬P means "valid input."

Imagine we define P = "Good input" and Q = "No Error."

• When testing the happy path, we are verifying that the implication P⟹Q (If input is good, then no error) holds true.

• When testing the unhappy path (mutation testing, more details later), we are verifying that ¬P⟹¬Q (If input is not good, then an error occurs) holds true.

In any test, a failure indicates that the tested implication is false. This warrants investigation into whether the issue lies with the specification's interpretation, the implementation, or even the test itself.

Applying Logic to Software Testing

Software development relies on constructing systems that behave predictably. Software testing is our primary tool for validating these behaviors. At its core, testing is a process deeply rooted in logical implications, where we propose a hypothesis about our code and then run an experiment (the test) to check its truth.

A test case is carefully designed to evaluate a specific piece of code. This involves:

1. Setting up Preconditions and Inputs: Before executing the code under test, we meticulously establish a specific environment and provide particular inputs. This includes:

   • Function/Method Arguments: The precise values passed into the code being tested.

   • System State: Setting up relevant data in a database, preparing the content of a file system, configuring an object's instance variables, or dictating the responses of external services (often through "mocks" or "stubs").

   • Environmental Factors: Controlling elements like the current time, specific network conditions, or user permissions relevant to the code's execution. This precise setup ensures that the code runs under defined conditions, allowing us to evaluate its behavior consistently.

Once the setup is complete, the code under test is executed, and its output or behavior is observed. This observation is then compared against an expected result.

To precisely analyze test outcomes, let's establish our specific logical mapping:

• P: The code under test is correct for the specific scenario defined by the test. This refers to the actual, objective state of the code's internal logic and implementation when presented with the test's preconditions and inputs. If P is True, the code is without defect for this case. If P is False, there is a bug or deviation.

• Q: The test passes. This means the actual output or behavior observed from the code precisely matches the expected outcome defined in our test case. If they do not match, the test fails.

• P⟹Q: If the code under test is correct for this specific scenario, then the test will pass. In pure propositional logic, the truth value of P⟹Q is indeed defined by the truth values of P and Q. But in the context of software testing, P⟹Q represents our hypothesis or desired specification for how the code should behave. We don't directly "know" P's truth value beforehand. Instead, the test's execution provides empirical data (the actual Q) that allows us to evaluate whether this hypothesis holds true in practice, and thereby infer the actual state of P.

Understanding this mapping is vital for interpreting test results. Let's examine the different outcomes of a test run, referencing the truth table for P⟹Q:

• Row 1: P is True (Code is correct), Q is True (Test passes)

  • Interpretation in Testing: Ideal State/Validation

    • This is the desired outcome and strengthens our confidence that the code adheres to its specification.

    • This scenario directly confirms the truth of our hypothesis (P⟹Q).

• Row 2: P is True (Code is correct), Q is False (Test fails)

  • Interpretation in Testing: Logical Contradiction / Falsification of Hypothesis

    • This row means our overall hypothesis P⟹Q is false for this specific instance.

    • This demands investigation: either our initial assumption that P was True (meaning the code was correct) is wrong (i.e., there's an actual bug, so P is actually False), or the test itself is flawed (its inputs/expectations are incorrect), or the specification is wrong.

    • This is where rethinking of the P⟹Q hypothesis itself happens.

• Row 3: P is False (Code is incorrect), Q is True (Test passes)

  • Interpretation in Testing: False Positive / Inadequate Test

    • This is a problematic scenario. It implies the test is not robust enough to detect the defect in the code, or the test's expectation is flawed.

    • While P⟹Q remains true vacuously, this outcome is misleading and means the test is not effectively verifying code correctness.

• Row 4: P is False (Code is incorrect), Q is False (Test fails)

  • Interpretation in Testing: Bug Found / Confirmation of Incorrectness

    • This is a beneficial outcome, as the test has successfully identified a defect.

    • When P is truly False, P⟹Q is vacuously true.

    • This row can represent either a known, intended 'P is False' state (e.g., TDD Red phase) or the actual state discovered via deduction (explained below in Scenario 1).

Note on this Contextualized Truth Table and Probabilistic Nature

This truth table differs from a purely abstract logical truth table by being explicitly contextualized for software testing.

• Specific Definitions: Unlike a generic P and Q, here they have precise meanings within the domain of code correctness and test outcomes.

• "Interpretation in Testing" Column: This is the key distinguishing feature. It translates the raw logical outcomes of (P, Q, and P⟹Q) into actionable insights and common debugging/development scenarios for software engineers. It explains what it means when a particular row is observed in the context of testing.

• Probabilistic Confidence: While formal logic operates in binary (True/False), real-world software testing often involves probabilistic confidence. A test doesn't provide absolute logical proof of correctness (for example, a passing test doesn't guarantee P is 100% True due to the possibility of undiscovered bugs or false positives). Instead, test results increase our confidence that the code is correct, or provide strong evidence that it is incorrect. Testing is fundamentally about reducing uncertainty and increasing the probability that our code functions as intended.

Let's now explore how these logical outcomes are interpreted in two common testing scenarios:

Scenario 1: Debugging an Unexpected Defect (Applying Modus Tollens)

This scenario occurs when a test that was previously passing, or a newly written test that we strongly trust as a precise and correct specification, unexpectedly fails. In this context, we assume the validity of the implication P⟹Q for this specific test case, treating it as an unbreakable rule for how correct code should behave.

1. Our Core Premise (Trusted Specification): We operate under the assumption that the implication "P⟹Q" ("If the code is correct for this scenario, then the test passes") is True for this specific test. Our confidence stems from the test's meticulous design, its history of passing, or its role in a well-established regression suite.

2. Test Execution and Observation: We run the test, which has its preconditions and inputs set.

   • If the Test Fails (Q is False): This is the key observation. Since we trust our premise that P⟹Q is True, and we observe ¬Q (the test fails), we are logically compelled to deduce that our initial belief about P (the code being correct for this scenario) must be false.

     • Application of Modus Tollens:

       • Premise 1: If the code is correct for this scenario (P), then the test passes (Q). (P⟹Q, assumed true as a trusted specification).

       • Premise 2: The test did not pass (¬Q).

       • Conclusion: Therefore, the code is not correct for this scenario (¬P).

     • Outcome: This inference directly points us to a defect in the code. The test's failure, given its trusted nature, reveals that the actual state of the code for this scenario is P is False. This effectively places the scenario in Row 4 (P False, Q False) of our truth table, confirming the presence of a bug that needs fixing. This is typical in regression testing, where a previously correct feature suddenly breaks.

Scenario 2: Validating/Refining the Specification (Falsifying P⟹Q or Confirming Known Incorrectness)

This scenario arises when a test fails, and our primary focus is not immediately on debugging the code as if it's a regression. Instead, it's on understanding why the P⟹Q relationship (our hypothesis for this specific behavior) isn't holding, or simply confirming an expected failure. This can involve questioning the test itself, the underlying requirements, or confirming a deliberately incorrect state of the code.

1. Our Hypothesis (Being Challenged or Confirmed): We are either actively evaluating the validity of the implication "P⟹Q" for a specific behavior, or we are running a test against code we know is incomplete or incorrect.

2. Test Execution and Observation: We run the test with its defined preconditions and inputs.

3. If the Test Fails (Q is False): The interpretation here depends on our prior knowledge or intent about the code's state (P):

   • Sub-scenario 2A: Falsifying P⟹Q and Rethinking Specification (Corresponds to Row 2: P True, Q False):

     • We observe Q is False (the test fails).

     • If we then examine the code and the requirements, and we conclude that the code should have been correct for this scenario (meaning, our expectation/belief was P is True), then the test result means the specific instance of our hypothesis "P⟹Q" is FALSE.

     • This direct falsification reveals a contradiction. We must then investigate:

       • Is our initial belief that P was True mistaken (that is, is there a genuine bug in the code that makes P actually False, moving this to a Row 4 scenario)?

       • Or, is the test itself incorrect (its inputs or expected output are wrong), meaning our P⟹Q premise needs to be re-evaluated and corrected?

       • Or, have the underlying requirements changed or been misunderstood?

     • Outcome: This critical outcome prompts us to "rethink" – either the code needs fixing, or the test needs adjusting, or the specification needs clarification. This is common in exploratory testing or when working with new/evolving features where the exact behavior is still being defined.

   • Sub-scenario 2B: Confirming Known Incorrectness (Corresponds to Row 4: P False, Q False):

     • We observe Q is False (the test fails).

     • We already know or intentionally designed the code to be incorrect for this scenario (that is, we are actively developing a feature and haven't written the full code yet, or we're running a test against a known, un-fixed bug, so our expectation is P is False).

     • The test result simply confirms our prior knowledge that P is False. The test correctly highlights the missing or incorrect behavior. In this case, the P⟹Q implication is vacuously true, and the test effectively served its purpose of showing the existing defect.

     • Outcome: This is typical in Test-Driven Development (TDD) in the Red phase, where a failing test for a not-yet-implemented feature confirms the "P is False" state, guiding development to make P True. It also applies when verifying that a bug fix indeed works: the test initially fails (confirming the bug), and then passes after the fix (confirming P is now True).

A Closer Look at Testing

The Illusion of Correctness: Affirming the Consequent

Consider a common scenario where a test passes, seemingly validating our code:

def get_user_role(user_id):
    if user_id == 42:
        return "admin"
    return "guest"

# test
assert get_user_role(42) == "admin"

Here, our implicit claim (the specification) is: If the code is correct (P), then the output will match the expectation (Q).

In this example, the test passes – the output is "admin" (Q), but can we definitively conclude that the function is correct (P)? Not necessarily.

This scenario often exemplifies the logical fallacy of affirming the consequent. We see the desired outcome (Q) and mistakenly assume that our specific intended cause (P, the correctness of our specific implementation path) was the reason.

The Problem: What if the real condition for an "admin" role should be checking a database, but we have temporarily hardcoded the value for testing? The test would pass, but the correctness is illusory. If we see P as false because the code did not implement the behaviour from the full specification, this corresponds to Row 3 (P False, Q True: False Positive) in our truth table.

As I mentioned before, deliberately implementing ¬P works well if ¬Q is observed, but is not useful, or even erroneous, if Q is observed.

Even without hardcoding, the output might match by coincidence, or because of factors outside the direct logic we intended to test. This can happen due to:

• Default behavior: A broader system default might produce the expected output.

• Caching: A previous successful operation might have cached the result, bypassing the actual logic.

• Fallback logic: An unintended fallback mechanism produces the correct output despite an error in the primary path.

• Test harness bugs: Flaws in the testing setup itself might obscure real issues.

The Role and Risks of Test Doubles

The challenges highlighted above are particularly relevant when using test doubles, such as Stubs and Mocks. These are artificial components that replace real dependencies (for example, databases, external APIs, time-sensitive operations) during testing.

• Stubs focus on state: they provide pre-programmed fake data or return values to get the rest of the code under test working predictably, like the get_user_role example

• Mocks focus on behavior: they allow you to verify interactions, such as the number of calls made to a certain API, or how control flow flows through specific parts of the system.

Both remove external dependencies, allowing you to isolate and focus on the internal logic of the code without noise or side effects. But using them without understanding their limitations can lead to false confidence.

If a test double simulates a "correct" response, but the real dependency it replaces has a bug, or the way the main code interacts with that dependency is flawed, the test will pass (Q is True) – yet P (the code's overall correctness in a real environment) might be False, leading to a dangerous false positive.

Whether you encounter such logical fallacies in your testing depends on precisely what behavior or state you are attempting to verify, and whether you are over-interpreting the test results.

Test Scope and Interpretation

The choice of testing scope – from narrowly focused unit tests to broader integration tests, system tests, user acceptance tests (UAT), and even testing in production – represents a continuum. On this spectrum, various trade-offs are involved, especially concerning the effort-reward ratio. This effort is influenced by factors like individual developer skill, company engineering practices (for example, responsibility split between feature developer and dedicated tester roles), and industry regulations.

Generally:

• Smaller-scoped tests (for example, unit tests) have fewer assumptions baked in and a shorter chain of logical implications. This translates to less risk of committing fallacies in both test implementation and test result interpretation. They are excellent for quickly verifying isolated units of code.

• Larger-scoped tests (for example, end-to-end integration tests) incorporate more real-world complexities and dependencies. While providing higher confidence in the system's overall behavior, they inherently increase the potential for confounding factors that can lead to false positives or make debugging more challenging.

Being acutely aware of the assumptions implicit in each test, at every scope level, is paramount. Passing tests for the wrong reasons will inevitably cause problems down the road.

Debugging, Observability, and Mental Models

Failing tests are not failures of the testing process but are, in fact, incredibly valuable learning moments. They represent opportunities to:

• Run focused debugging experiments to pinpoint the exact cause of the failure.

• Refine your mental model of the code-to-outcome (P⟹Q) link. A failing test (where Q is False) tells you that your current understanding of P, or of the P⟹Q relationship, is flawed. Use this feedback to update your understanding of the code's actual behavior.

• Improve both the code and the tests themselves.

Enhance system observability to better detect and confirm outcomes (Q). The more clearly, from multiple angles, and through diverse methods we can observe Q (for example, logs, metrics, tracing, output inspection), the more confident we can be in its causes and, by extension, the actual state of P.

Crucially, avoid blindly fixing tests just to make them pass. Always ensure you thoroughly understand why a test failed and update your P⟹Q model accordingly. The ultimate goal is not just to fix current bugs, but to prevent them in the future by continually strengthening both the correctness of the code and the verifiability of its behavior.

Falsifiable Tests Reveal Regressions

Beyond avoiding false positives (where the code is incorrect but the test passes), a good test must also be falsifiable. This means the test must be genuinely capable of failing under certain (incorrect) conditions. An unfalsifiable test is a broken test – it cannot serve its purpose of revealing regressions or confirming the presence of bugs.

While we strive for the implication P⟹Q to hold true for all the scenarios we care about, it may not be true for all cases due to unforeseen or mistaken assumptions, or simply because the code is incorrect. The test's ability to demonstrate this incorrectness by failing under specific, well-defined conditions makes it profoundly valuable.

Some common culprits for unfalsifiable or "bad" tests include:

• Vague or Untestable Specifications: Statements like "The system should behave well under most conditions," "It shouldn't crash randomly," or "The algorithm is robust" lack clear, measurable criteria. It's impossible to design a test that definitively passes or fails against such statements, thus rendering them effectively unfalsifiable.

• Broken Implementations of the Test Suite: The test code itself might be flawed, perhaps due to logical errors or control flow issues that prevent assertions from ever being reached or correctly evaluated, inadvertently taking the same passing path regardless of the code under test.

• Insufficient Test Data or Edge Cases: If tests only cover "happy path" scenarios and fail to include challenging inputs or boundary conditions, they might pass for incorrect code that only breaks under specific, untested circumstances.

A robust specification clearly defines what constitutes success and failure. Correspondingly, a good test suite correctly implements that specification, making its tests both accurate and truly falsifiable.

Take a step back

Critical thinkers might observe that the application of the four fundamental logical argument forms to coding scenarios, as initially presented, could be misleading in the complexities of real-world software.

The next section shows some nuances that arise when we transition from the clear-cut rules of formal logic to the often messy reality of software development.

Specifically:

• The first two points below show why the seemingly valid arguments of Modus Ponens and Modus Tollens may not always lead to reliable conclusions when applied to coding scenarios.

• The last two points below show why the two common logical fallacies, Affirming the Consequent and Denying the Antecedent, may actually provide correct insights under specific real-world coding conditions.

Revisiting the Four Statements for Coding

Here are the four arguments and their associated coding examples:

1. Modus Ponens: If you provide invalid input data (P), the code will show an error (Q).

2. Modus Tollens: There are no error messages (¬Q), so the input data is valid (¬P).

3. Affirming the Consequent (Fallacy): The code showed an error (Q), so you provided invalid data (P).

4. Denying the Antecedent (Fallacy): You provided valid data (¬P), so you have no error (¬Q).

Now, let's dive into the nuances of each:

Modus Ponens

• Our coding example: If you provide invalid input data (P), then the code will show an error (Q).

• Why it may not always hold: This application of Modus Ponens assumes that either your code or any third-party code it relies upon will always properly detect and explicitly raise exceptions or show errors on bad data. In reality, systems might automatically fix or sanitize bad input, silence errors, or simply proceed with unexpected behavior without explicitly signaling an error, leading to a passing (or non-failing) state (¬Q) even when P (invalid input) was true.

Modus Tollens

• Our coding example: There are no error messages (¬Q), so the input data is valid (¬P).

• Why it may not always hold: This application of Modus Tollens assumes there are no automatic mechanisms within the system to fix or silence bad input before errors are typically displayed. If such "silent correction" or "error suppression" occurs, you might observe no error messages (¬Q), but the input data could still be invalid (P), rendering the conclusion (¬P) false despite the premise (¬Q) being true. This highlights the dangers of incomplete observability.

Affirming the Consequent (Fallacy)

• Our coding example: The code showed an error (Q), so you provided invalid data (P).

• Why it may actually be correct: While logically a fallacy, in specific, highly constrained real-world conditions, this inference can gain practical validity. If the error message is so uniquely and specifically defined that it can only be caused by invalid input data (P) and no other known factor, then this statement can become reliable. This is rare and typically requires meticulous error handling design where each error message maps unambiguously to a single root cause.

Denying the Antecedent (Fallacy)

• Our coding example: You provided valid data (¬P), so you have no error (¬Q).

• Why it may actually be correct: Although a fallacy in general logic, this inference can hold a high degree of practical confidence under certain programming paradigms (Functional Programming). If the code is sufficiently simple, purely functional (meaning outputs depend only on inputs and have no side effects), and has no external dependencies (like network or database interactions), then the absence of invalid data (¬P) can indeed make us reasonably confident that there will be no errors (¬Q). The lack of external variables and internal state makes the code's behavior highly predictable and directly tied to its inputs.

You may now be thinking: what’s the point of studying logic if it has so many loopholes and edge cases when applied to coding?

The Missing Ingredient – If and Only If

In our exploration of logical implications, we've focused primarily on the unidirectional relationship P⟹Q ("If P, then Q"). This statement tells us what happens if P is true, but it remains silent on whether Q only happens when P is true. It's like saying, "If it rains, the ground gets wet." This is true, but the ground can also get wet if a sprinkler is on, even if it's not raining.

But in many critical contexts, especially in rigorous scientific theories and robust software systems, we often seek a much stronger relationship: one where the truth of Q absolutely depends on the truth of P, and vice versa. This powerful bidirectional relationship is captured by the phrase "If and Only If" (P⟺Q).

What "If and Only If" Means: A Stronger Statement

When we assert "P⟺Q", we're making two distinct claims simultaneously:

1. If P, then Q (P⟹Q): P is a sufficient condition for Q. Whenever P is true, Q must also be true.

2. If Q, then P (Q⟹P): P is also a necessary condition for Q. Whenever Q is true, P must also be true. In other words, Q cannot be true without P being true.

Notice the significant increase in the strength of the statement. "If P, then Q" merely states a consequence. "P⟺Q" declares a definitive equivalence, where P and Q are inextricably linked. They rise and fall together – one cannot be true without the other being true, and one cannot be false without the other being false.

Bidirectional Truth Table: Unambiguous Relationships

Let's construct the truth table for P⟺Q to clearly see this strong relationship.

P⟺Q is logically equivalent to (P⟹Q)∧(Q⟹P).

Creating the Table (columns 4 and 5 are new):

• Q⟹P (Column 4): We apply the standard implication rules, but with Q as our "if" and P as our "then." For instance, in Row 3, Q is True and P is False, so Q⟹P is False.

• P⟺Q (Column 5): This is the logical AND of the P⟹Q and Q⟹P columns. For P⟺Q to be True, both component implications must be True, which explains why you see less Trues in the bidirectional implication compared to any of the unidirectional implications.

Implications for the Two Common Fallacies

The clarity provided by "If and Only If" is particularly powerful in preventing the very logical fallacies we discussed earlier: Affirming the Consequent and Denying the Antecedent. These fallacies arise from the incorrect assumption that an "if-then" statement implies an "if and only if" relationship.

Let's revisit them with the lens of P⟺Q If and Only If you provided invalid data (P), then the code will show an error (Q):

Affirming the Consequent: No More Ambiguity

• The Fallacy (assuming unidirectional P⟹Q):

  • If the code showed an error (Q), then you provided invalid data (P).

  • Previously, when P⟹Q was True and Q was True, P could be True (Row 1) or False (Row 3). This ambiguity led to the fallacy.

• With P⟺Q:

  • Now, look at the P⟺Q column in the table. When P⟺Q is True and Q is True (Row 1), P is unambiguously True. The confusion from Row 3 is gone because if Q were True while P was False, P⟺Q would be False (as Q⟹P would be False), thus making that row irrelevant for valid modus ponens inference under the P⟺Q premise.

  • In a system designed with P⟺Q in mind, knowing that Q is True (observing an error) would force the conclusion that P is True (invalid data is the cause), assuming the "if and only if" relationship holds true for that specific system design.

Denying the Antecedent: Unmistakable Consequences

• The Fallacy (assuming unidirectional P⟹Q):

  • You provided valid data (¬P), so you have no error (¬Q).

  • Previously, when P⟹Q was True and P was False, Q could be True (Row 3) or False (Row 4). This ambiguity led to the fallacy.

• With P⟺Q:

  • Now, when P⟺Q is True and P is False (Row 4), Q is unambiguously False. The problematic scenario from Row 3 (where P was False but Q was True) is irrelevant here because P⟺Q would be False in that case (specifically, Q⟹P would be False).

  • If your system genuinely adheres to "P⟺Q", then knowing that P is False (valid data provided) guarantees that Q is False (no error messages).

Practical Mitigation in Coding

The insights from "If and Only If" are more than just theoretical. Practically, both fallacies (Affirming the Consequent and Denying the Antecedent) can be mitigated by striving for conditions that approximate an "if and only if" relationship in your code and tests.

Focused Unit Tests

Design unit tests that are so granular and isolated that they effectively aim to establish an "if and only if" scenario for a tiny piece of logic. By thoroughly mocking or controlling all external dependencies and environmental factors, you reduce the impact of "other causes."

If your test for a specific input passes, you want to be as confident as possible that it passed only because the code handled that specific input correctly, and not due to some irrelevant side effect. Similarly, if it fails, you want to be sure that the failure points directly to the intended logical path.

Exception Handling and Specificity

Instead of catching broad Exception types, catch and handle specific exceptions. This helps differentiate between various "causes" (P1​,P2​,…) that might lead to a generic "error" (Q). The more precise your error handling, the closer you get to a scenario where "If X error, then Y specific cause," moving towards a bidirectional understanding of error conditions.

Test-Driven Development (TDD) and Mutation Testing

These methodologies inherently push towards P⟺Q thinking. TDD encourages writing a failing test first (¬Q), which then necessitates a specific code change (P) to make it pass.

Mutation testing, which we'll explore further, takes this a step further by ensuring that your tests are robust enough to fail when code is subtly altered (that is, proving that ¬P leads to ¬Q, and thus, that the original P was indeed necessary for Q).

By consciously aiming for "if and only if" relationships in your code's design and your testing strategies, you can build systems that are not only predictable but also much easier to debug and reason about, moving beyond mere correlation to a deeper understanding of cause and effect.

Callback to Mutation Testing

In the earlier section on Assigning Real-World Meanings to Logic, we discussed:

When testing the happy path, we are verifying that the implication P⟹Q (If input is good, then no error) holds true.

When testing the unhappy path (mutation testing), we are verifying that ¬P⟹¬Q (If input is not good, then an error occurs) holds true.

This dual view is key to understanding how mutation testing contributes to software correctness.

Mutation Testing: Testing the Tests

Mutation testing deliberately introduces small faults (mutations) in the code and checks whether the test suite detects them by failing. This process assesses not the code, but the tests themselves.

In a robust test suite, we strive for two ideal conditions:

• All correct implementations should pass the tests.

• All incorrect implementations should fail the tests.

If a mutated (wrong) version of the code is introduced and causes no test failures, that defeats the fundamental purpose of testing. It means your tests aren't sensitive enough to catch a deviation from correctness. Mutations reveal hidden assumptions or gaps in your test coverage, acting as a sensitivity probe for your test suite.

Example code mutations:

• Changing an arithmetic operator (+ to -, > to >=).

• Flipping a boolean condition (true to false).

• Deleting or duplicating a statement.

• Modifying a constant value.

Common Python mutation testing tools:

• mutmut uses Python’s built-in ast module.

• cosmic-ray uses parso, which provides a more complete AST.

These tools rely on abstract syntax trees to surgically mutate code.

You can even swap out underlying AST libraries for different precision or completeness: https://github.com/boxed/mutmut/issues/281

Logic Behind Mutation Testing

Let's formalize the logical mapping of mutation testing, recalling our definitions:

• Let P: Code is correct.

• Let Q: Tests pass.

Standard happy path testing primarily checks that P⟹Q – "if the code is correct, then tests pass."

Mutation testing focuses on the other side of the coin: we intentionally make ¬P true (by introducing a fault), and then we expect ¬Q (the tests should fail). This process rigorously checks whether the implication ¬P⟹¬Q ("if the code is not correct, then the tests fail") holds true for your test suite.

But there's a deeper, more powerful logical implication here:

As we learned earlier, the statement ¬P⟹¬Q is logically equivalent to its contrapositive, Q⟹P.

So, by successfully verifying that introducing a fault (¬P) leads to a test failure (¬Q), we are simultaneously validating the contrapositive: if tests pass (Q), then the code must be correct (P).

This is incredibly significant! It moves us much closer to establishing a bidirectional guarantee between our code and our tests: P⟺Q (code correctness is tightly coupled with test success). Mutation testing helps us confidently eliminate false positives in the test suite – situations where Q is true (the test passes) but P is false (the code is actually incorrect).

In a world where LLMs help us write and refactor code quickly, having this "if and only if" confidence in our test suite is invaluable for ensuring the generated or refactored code truly meets expectations.

Clarifying the Kinds of Failures

In software, we typically categorize errors into three main types:

• Syntax errors: Violations of the language's grammatical rules (for example, missing colon, invalid keyword). These prevent the code from running at all.

• Runtime errors: Errors that occur during program execution, often due to unexpected conditions (for example, TypeError, AttributeError, ZeroDivisionError).

• Logic errors: The program runs without crashing, but it produces an incorrect result or behaves in a way that doesn't match the intended specification (for example, wrong algorithm, wrong return value).

Mutation testing focuses on logic errors – failures where the program runs, but produces incorrect results. These are usually caught via AssertionError in the "Assert" phase of the Arrange–Act–Assert (AAA) testing pattern.

You could argue pedantically that AssertionError is a runtime error, but in testing, we treat it as a signal for logical failure:

"The function ran, but the output didn’t match the expected behavior."

Mutation testing assumes that syntax and runtime errors are already handled. Its purpose is to validate whether the test suite reliably catches logical misbehavior.

A Deeper Falsification Perspective

Now, let's connect mutation testing back to Karl Popper's principle of falsification, which we introduced earlier in the context of scientific reasoning. Recall that Popper argued scientific theories gain strength not by being "proven," but by surviving rigorous attempts to disprove them. The core idea of falsification logic is that to disprove an implication like P⟹Q, you only need to find one instance where P is True and Q is False.

Mutation testing applies this same powerful principle, but to our test suite's effectiveness:

Instead of trying to prove directly that our tests are perfect, mutation testing takes a falsification approach to the implication ¬P⟹¬Q ("If the code is incorrect, then the tests fail"). It actively tries to falsify this crucial relationship.

If we introduce a mutation (making ¬P true, that is, the code is now incorrect) but the existing test suite still passes (meaning Q is true), then we have found an instance where:

1. ¬P is True (the code is incorrect due to the mutation).

2. Q is True (the test still passes).

In this scenario, the implication ¬P⟹¬Q is falsified because we have a True antecedent (¬P) leading to a False consequent (¬Q is false, because Q is true).

And, critically, if ¬P⟹¬Q is falsified, then its logically equivalent contrapositive, Q⟹P ("If the tests pass, then the code is correct"), is also falsified. This means we can no longer trust that a passing test suite reliably indicates correct code. Our desired P⟺Q relationship is broken – the test suite is no longer fully effective at guaranteeing correctness.

By pushing for zero surviving mutants, mutation testing forces us to minimize the surface area of these "hidden assumptions" in our test suite. It demands highly sensitive and specific tests that can pinpoint even subtle logical flaws, thereby moving us closer to building truly resilient systems.

Comparing TDD (Red Phase) and Mutation Testing

Both methodologies, albeit through different means and at different stages of the development cycle, aim to establish confidence in the ¬P ⟹ ¬Q relationship.

Key Differences Summarized:

Toward If-and-Only-If Confidence

Ultimately, the goal in software development is to establish if-and-only-if relationships whenever possible, both in the code implementation and especially in the sensitivity of the test suite to the code under test.

This means if a certain condition (P) is true, then a specific outcome (Q) must occur, and if Q occurs, then P must have been the cause. Achieving this level of clarity comes from:

• A deep understanding of the problem.

• Aligned expectations during requirements gathering.

• Logical analysis and interpretation of well-designed experiments.

• Adherence to Single Responsibility Principle in SOLID

• Rigorous tests with meaningful coverage.

This allows us to understand how control flow and data flow work with greater depth and confidence, leading to better inferences throughout the entire software development lifecycle.

Real-World Challenges

While striving for perfect "if-and-only-if" relationships provides a powerful logical ideal, the messy reality of modern software development presents significant hurdles. The very characteristics that make large systems powerful and scalable – their intricate interconnections and inherent dynamism – simultaneously obscure clear cause-and-effect relationships, making precise logical reasoning and debugging an ongoing battle.

A Web of Complexity

Fan-In, Fan-Out: The Nature of Modern Systems

Any reasonably large software system rarely operates through purely linear control and data flows. Fan-out and fan-in patterns – where many components are called and then their results merged – are inevitable.

For example:

• In ETL pipelines, data may be ingested from multiple sources (external APIs, CSVs) and logged to multiple destinations (files, databases).

• In concurrent programming, Python’s ProcessPoolExecutor splits data into chunks processed in parallel, then recombines the results.

SRP Meets Real-World Boundaries

Just as functional programming must eventually perform I/O, the Single Responsibility Principle (SRP) runs into real-world boundaries, whether conceptual or infrastructural. At some point, something must glue these isolated units together.

Orchestration logic might live in a single function, span multiple files, or even distribute across microservices and machines communicating over networks. While this decomposition enhances modularity, it also increases surface area for bugs involving:

• Side effects: Unintended changes to system state outside a component's explicit outputs.

• Circular dependencies: Components relying on each other in a loop, leading to difficult-to-trace behavior.

• Interface drift: Changes in one component's input/output expectations not being correctly reflected elsewhere.

• Race conditions: Timing-dependent bugs in concurrent operations.

• Serialization issues: Problems translating data between different formats or systems.

• Network unreliability: Unpredictable latency, packet loss, or disconnections in distributed systems.

The Double-Edged Sword of Abstraction

This web of dependencies is the price of progress, made manageable only through better tooling and abstractions.

• If boundaries are well-designed, observable, and testable, they enable asynchronous collaboration, improve long-term maintainability, and increase developer confidence. (See GitHub Playbook in References)

• If systems lack architectural coherence or fall behind evolving needs, they calcify into technical debt that demoralizes even the most motivated teams.

Clean Code Is Contextual

While abstractions and orchestration help manage complexity, overusing design patterns or creating unnecessary class layers can introduce needless indirection. This is a common counterargument to architectural purism.

Ultimately, what counts as "clean code" is context-dependent. It varies with programmer skill, the tooling at hand (linters, tests, Copilot), and whether the project is a throwaway script or a multi-year infrastructure investment. Architectural practices like SRP should evolve alongside those constraints.

The Butterfly Effect of Bugs

From SRP to Reasoning Chains

Previously, we focused on simple, direct cause-effect logic (P ⟹ Q), but real-world systems are messier.

The more we adhere to SRP through small, focused functions, the more we create longer chains of logic. This improves separation of concerns but also extends the reasoning required to debug behavior.

Debugging in a Causal Fog

A seemingly minor trigger (O) can cascade through a chain like O⟹P⟹Q⟹R, which we may not fully understand due to knowledge silos, evolving requirements, or runtime dynamism.

Even when we understand the components, precisely identifying “P” is hard, much like how redefining a research question shifts the statistical population being studied. In complex systems with feedback loops (recommender engines), there might not be a single "root cause" at all.

Short-Term Triage vs. Long-Term Insight

Finding the true origin of a bug often demands experimentation, telemetry, and broad system insight. These investigations produce robust, future-proof fixes but take time.

In on-call scenarios, however, urgency reshapes priorities. Fast mitigations and clear communication often take precedence over deep diagnosis.

Masked by Design and Debt

As systems scale, failure stops looking like a crash. Instead, it shows up as a retry spike, a slow metric drift, or silent fallback behavior.

Modern fault-tolerant systems, built with retries, failovers, circuit breakers, and autoscaling, are designed to recover quickly. This resilience often masks deeper problems, delaying detection for weeks and making root cause analysis harder.

Operating in non-deterministic environments with flaky networks, race conditions, or dynamic routing adds further ambiguity. Small symptoms become harder to link back to specific causes.

Compounding this, technical debt driven by weak technical leadership, shifting priorities or time pressure weakens the system’s observability and test coverage. Teams inherit brittle, poorly understood code, making it hard to draw clean lines between cause and effect.

Even the best engineers struggle in such conditions. When a system resists clarity, it doesn’t just block debugging. It erodes trust, slows learning, and fuels long-term burnout.

Glimmers of Hope: Tools and Practices for Clarity

Despite these challenges, several strategies and practices offer a path toward more robust and understandable software.

Leveraging Design Patterns

Design patterns offer a shared vocabulary and time-tested strategies for structuring systems. When applied well, they tame complexity, reduce technical debt, and make behavior more predictable.

They also tend to concentrate similar failure modes. The same bug might appear across companies or industries, creating a wealth of prior art and solution playbooks. Familiarity with patterns can accelerate debugging and deepen shared understanding across teams.

Nurturing Expert Mentorship

Promoting mentors based on real technical impact instead of tenure builds stronger teams and avoids the Peter Principle (people in a hierarchy tend to rise to a level of respective incompetence).

Great mentors teach more than skills – they model falsifiability, independent thinking, and an ability to reason under uncertainty.

They help others challenge assumptions, navigate tradeoffs, and grow both technically and interpersonally. In systems where root causes are murky, this kind of leadership is essential.

One of the most powerful techniques that scales from mentorship to code is falsification: the disciplined search for counterexamples. Whether applied in design reviews, debugging sessions, or automated tests, this mindset anchors reasoning in reality.

The Power of Falsification in Testing

The deliberate search for counterexamples is core to building reliable systems.

• In algorithm design, testing edge cases is just falsification in disguise: finding where your logic breaks.

• In code, fuzz testing (Atheris) throws diverse inputs at functions to expose falsifying examples.

• Property-based testing (Hypothesis) goes further by generating inputs that satisfy certain rules, then shrinks failures to their minimal form. This greatly improves reproducibility and helps stress-test concurrency issues.

The more rigorously we attempt to falsify our assumptions, the more confidently we can reason about behavior using tools like Modus Ponens and Modus Tollens.

Assumptions are always present in software to simplify complexity. The question is whether they're explicitly codified in tests or left hidden and fragile.

Of course, no test is ever bulletproof: our assumptions could be mistaken, or the world could change. That’s why critical thinking, discerning "what should be" versus "what is", remains essential as newer generations increasingly rely on AI tools like Large Language Models.

This deliberate, falsification-driven approach is paramount for building reliable software. It underpins sophisticated testing techniques designed to expose hidden assumptions and break our logical chains.

While testing helps us uncover where our reasoning might falter, some domains demand an even higher degree of certainty. For those critical systems, we turn to the ultimate tools for logical rigor: Proof Assistants.

Proof Assistants

While traditional testing and fuzzing are powerful for finding bugs, they fundamentally cannot guarantee correctness for all possible inputs or scenarios. They can only prove the presence of bugs, not their absence.

To achieve formal, mathematically verified proofs of program behavior – providing the strongest possible guarantees – we turn to proof assistants. These tools allow us to build step-by-step logical proofs, ensuring that a program or system design adheres to its specification with absolute rigor.

Prolog

Prolog offers a relatively straightforward entry point into the world of logic programming and theorem proving. SWI-Prolog is a common interpreter (a REPL, or Read-Eval-Print Loop) for Prolog.

You interact with Prolog by providing it with a knowledge base composed of facts and rules (which are a type of logical clause called Horn clauses). You then pose queries.

Installing SWI-Prolog

You can download SWI-Prolog from its official website: https://www.swi-prolog.org/download/stable
Follow the instructions for your operating system (Windows, macOS, or Linux).

On Ubuntu/Debian, you can usually install it via:

sudo apt update
sudo apt install swi-prolog

Using Prolog: REPL vs. File

• REPL (swipl) is best for: Quick, interactive tests of single facts or rules, and posing queries to an already loaded knowledge base.

• A File (.pl extension) is best for: Defining your entire knowledge base (multiple facts and rules) and storing your program for reusability. This is the standard way to work with Prolog for anything beyond a few lines.

Example: A Simple Knowledge Base

Let's define a knowledge base to represent who has a job and who is a coding instructor.

1. Create a file named knowledge.pl with the following content:

% knowledge.pl
% This file defines a small knowledge base in Prolog.
% In Prolog, all statements (facts and rules) about the same predicate
% (identified by its name AND number of arguments, e.g., 'has_job' with 1 argument is 'has_job/1')
% must be written consecutively without other predicate definitions in between.

% --- Definitions for the 'has_job' predicate (takes 1 argument) ---

% Fact: Alice has a job.
has_job(alice).

% Fact: Bob has a job.
has_job(bob).

% Rule: Anyone (represented by variable X) has a job IF they are a coding instructor.
% ':-' means 'if'. 'X' is a variable (starts with uppercase).
has_job(X) :- is_coding_instructor(X).

% --- Definitions for the 'is_coding_instructor' predicate (takes 1 argument) ---

% Fact: Alice is a coding instructor.
is_coding_instructor(alice).

What each line does:

• Lines starting with %: These are comments for human readability, ignored by Prolog. They explain the file's purpose and key rules like predicate grouping.

• has_job(alice). / has_job(bob).: These are facts. They assert simple truths, like "Alice has a job." The . at the end is mandatory for every statement.

• has_job(X) :- is_coding_instructor(X).: This is a rule. It states a conditional truth: "For any X, X has a job if X is a coding instructor." X is a variable (always starts with an uppercase letter), and :- means "if." This rule allows Prolog to deduce new information.

• is_coding_instructor(alice).: Another fact, asserting "Alice is a coding instructor." It's placed after all has_job/1 clauses to satisfy Prolog's grouping rule.

2. Load and Query in the REPL:

Open your terminal and type swipl. Once at the ?- prompt, load the file and then pose your queries:

$ swipl
?- [knowledge].   % Load the 'knowledge.pl' file (omit .pl, use square brackets and a period)
% Press Enter. Prolog will confirm it loaded the file, e.g., '% knowledge.pl compiled...'
True.

?- has_job(alice). % Query: Does Alice have a job?
% Press Enter. Prolog gives you a solution, then waits.
True.              % Output: Yes, because it's a fact.
% After 'True.', you'll see the '?- ' prompt again, indicating Prolog is ready for your next query.
% If there were multiple ways to prove 'True.', Prolog would present the first 'True.' then wait for you to press ';' for alternatives, then Enter to confirm the final 'True.' or 'False.'.

?- has_job(carol). % Query: Does Carol have a job?
% Press Enter.
False.             % Output: No, Prolog cannot prove it from its knowledge.

?- has_job(X).     % Query: Who has a job? (Find values for X)
% Press Enter
X = alice ;        % Prolog finds Alice as the first solution. Type ';' and press Enter to ask for the next solution.
X = bob ;          % It finds Bob. Type ';' and press Enter for the next solution.
X = alice          % It finds Alice again (this time deduced via the rule and is_coding_instructor(alice)).
% Press Enter. This accepts the current set of solutions and stops searching for more.
False.             % Output: Indicates no more solutions found after the last 'Enter' (or if you explicitly chose not to search further).

?- halt.           % Type 'halt.' to exit the Prolog REPL cleanly.
% Alternatively, you can often use Ctrl+D (press and hold Ctrl, then D) to exit most REPLs.

The Prolog example clearly demonstrates:

• "Is P(X) true for a specific X?": Shown by ?- has_job(alice). (returns True.) and ?- has_job(carol). (returns False.).

• "Is there an X for which P(X) is true?": Shown by ?- has_job(X). (provides solutions like X = alice, X = bob).

Prolog Limitations

Prolog's limitations become evident when attempting to reason about falsity or non-existence. You cannot directly ask "Is there any X for which P(X) is false?"

Instead, Prolog operates on the principle of negation as failure. This means that if Prolog cannot prove a statement, it considers that statement false.

For example, if you ask ?- \+ has_job(carol). (meaning "Is it not true that Carol has a job?"), Prolog will say True, because it simply cannot find any proof that Carol has a job in its knowledge base.

This is a significant distinction: it doesn't mean Carol definitely doesn't have a job, nor does Prolog provide a formal counterexample. It merely reflects a lack of provable information.

This fundamental constraint means Prolog, while powerful for logic programming, falls short of being a full-fledged proof assistant for comprehensive formal verification.

Coq

After experimenting with Prolog and seeing its limitations, you can move on to a more powerful proof assistant like Coq. Coq is employed in safety-critical domains where absolute mathematical certainty is paramount. coqtop is the standard REPL for Coq.

A fundamental difference from Prolog is Coq's lack of a Closed World Assumption. In Coq, anything not explicitly proven is simply unknown, not automatically false.

Unlike Prolog, Coq's primary purpose isn't solving computational problems by searching a knowledge base. Its true power lies in its ability to construct and verify formal mathematical proofs and programs with absolute rigor. Its interaction involves managing a proof state (your remaining goals) and applying tactics (logical inference steps) until the proof is complete.

Installing Coq

Coq can be installed in several ways, often via package managers or a tool called opam (the OCaml package manager, as Coq is written in OCaml).

• Official Downloads: Visit the Coq website for detailed instructions for your OS: https://coq.inria.fr/download

• Using a system package manager (for example, Ubuntu/Debian): Bash

    sudo apt update
    sudo apt install coq
  

Using Coq: REPL vs. File

• REPL (coqtop) is best for: Trying out single tactics, inspecting the current proof state, or learning basic syntax for very short commands.

• A File (.v extension) is best for: Almost all Coq development and proof construction. This is how complex proofs and verified programs are structured and managed.

Coq's Comprehensive Question Answering

Unlike Prolog, Coq can directly address all three types of logical questions we've discussed, providing robust answers backed by formal proof:

• "Is P(X) true for a specific X?": Coq allows you to define a precise statement (a theorem) like "Alice has a job." You then build a step-by-step logical proof that formally confirms whether this statement is true based on your definitions. If the proof succeeds, Coq formally verifies it: if it fails, Coq clearly shows where your logic breaks down.

• "Is there an X for which P(X) is true?": Coq handles questions of existence. If you ask, "Does someone have a job?", you can construct a proof by explicitly providing an example (like "Alice") and then proving that your chosen example indeed satisfies the condition ("Alice has a job").

• "Is there any X for which P(X) is false?": This is a key capability where Coq excels over Prolog. Coq allows you to formally prove that a statement is false, or that a counterexample exists. For instance, you could prove "Carol does not have a job" by showing it contradicts the definition, or prove "there exists someone who doesn't have a job" by explicitly identifying such a person and proving that they indeed lack a job. This direct ability to reason about negation and provide formal counterexamples (or prove their non-existence) is what makes Coq a full-fledged proof assistant.

While Coq's core doesn't automatically generate counterexamples when a proof fails, plugins like QuickChick can be integrated for property-based testing to find falsifying examples.

It's a Coq library that allows you to specify properties about your Coq definitions and then randomly generate inputs to try and find a counterexample that falsifies your property.

This is a powerful way to find bugs early in your formalization before you invest a lot of time trying to prove a false theorem.

TLA+, Isabelle, and Lean: A Spectrum of Formal Verification

Beyond Prolog and Coq, other powerful proof assistants and formal specification languages cater to different needs and paradigms:

• TLA+: This is a formal specification language developed by Leslie Lamport. It focuses on modeling and verifying system designs (especially concurrent and distributed ones) using temporal logic, rather than proving low-level code. It helps ensure critical properties like safety (nothing bad ever happens) and liveness (something good eventually happens). Its practicality and accessibility make it popular in industry, notably at Amazon and Microsoft for robust system design.

• Isabelle and Lean: These are modern, highly advanced proof assistants.

  • Isabelle, grounded in higher-order logic, is widely used by researchers and institutions (for example, in projects like the seL4 verified microkernel) for formal theorem proving and software verification in academic and safety-critical domains demanding extreme rigor.

  • Lean, based on dependent type theory, is favored by mathematicians for formalizing proofs in pure mathematics (for example, number theory, algebra). It's known for its powerful automation and active community.

These tools represent the pinnacle of applying formal logic to ensure the correctness and reliability of both mathematical theories and complex software systems.

Now that you have a good lay of the land in both theory and practice, here are some thought experiments to enrich your education.

Food for Thought

The journey into formal logic and its intersection with practical domains like software and science offers many avenues for deeper exploration.

Hypothesis Testing in Science and the Implication Truth Table

Statistical hypothesis testing uses a probabilistic form of Modus Tollens. We start with a null hypothesis (H0​): "If H0​ is true, then observing this data (or more extreme data) is likely." We then observe data that is highly unlikely/unexpected if H0​ were true (that is, a small p-value). This serves as our probabilistic "not Q." Therefore, we conclude that H0​ is likely not true (we reject H0​). This is our probabilistic "∴¬P."

Here, the "truthiness" of P⟹Q is being tested, rather than simply assumed to be true for developing arguments, as in Modus Ponens or Modus Tollens. There's no absolute truth or anything to "prove" definitively.

Inferences are drawn from prior experiments (which inform the test data distribution) and context-specific experiment setups (which determine the significance level α), together defining the threshold (critical value) for what is considered an unlikely observation of Q.

The experiment's result is a rejection (or lack thereof) of H0​, not a definitive proof that H0​ is true.

Inductive Reasoning's Relationship to Deductive Arguments

• Induction generates general rules (for example, "P is always followed by Q") from specific observations or cases.

• Deduction then tests or applies those general rules in new situations.

If deduction leads to wrong predictions (that is, a rule is falsified), induction may need to revise the original rule, which forms a continuous feedback loop that refines our understanding.

Necessity and Sufficiency in Implication

The implication P⟹Q ("If you crossed the border, you must have had a passport") unpacks into two fundamental logical concepts:

• P is sufficient for Q: Crossing the border guarantees you had a passport. (P alone is enough for Q.)

• Q is necessary for P: If you didn't have a passport (¬Q), you couldn't have crossed (¬P). (Q is required for P to happen.)

Q.E.D.: The Enduring Power of Logic in an Uncertain World

Throughout this handbook, we’ve journeyed from the foundational concepts of propositional logic and truth tables to the powerful argument forms of Modus Ponens and Modus Tollens. We explored how these tools enable valid deductions and identified common logical fallacies like Affirming the Consequent and Denying the Antecedent, understanding why they lead to incorrect inferences when an "if-then" relationship isn't a strict "if and only if." We learned the profound importance of falsifiability – the ability for a statement or hypothesis to be disproven – a cornerstone of both scientific inquiry and robust software testing.

We then delved into the practical application of these logical principles in software development, mapping code correctness to test outcomes. We discovered how a failing test, when trusted, becomes a powerful application of Modus Tollens, pinpointing defects. We also confronted the "illusion of correctness" that arises from the affirming the consequent fallacy when tests pass for the wrong reasons, especially when using test doubles.

Crucially, we introduced the "If and Only If" (P⟺Q) relationship, highlighting its unparalleled power in establishing unambiguous connections between cause and effect. This bidirectional guarantee is the ideal we strive for in test suite quality, moving beyond mere correlation to a deeper understanding of causality. We saw how mutation testing rigorously pushes us towards this "if and only if" confidence by actively trying to falsify the assumption that "incorrect code leads to failing tests," thereby strengthening the inverse: "passing tests guarantee correct code."

We also acknowledged the "messy reality" of modern software. Large systems are webs of complexity, with fan-in/fan-out patterns, side effects, and unforeseen interactions that can obscure clear logical chains. Technical debt and the double-edged sword of abstraction often mask the true origins of bugs, turning debugging into a "causal fog."

Logic as Your Compass

Despite these formidable challenges, the logical principles we've explored remain your most vital tools. They provide the mental framework to navigate uncertainty.

When confronted with a bug, your ability to reason logically allows you to formulate hypotheses, design focused experiments (your tests), and interpret their outcomes with precision. Whether you're debugging a complex microservice or reasoning about a simple function, applying Modus Tollens to a failing test or designing tests that aim for P⟺Q clarity helps you cut through the noise.

We also touched upon advanced tools like Proof Assistants (Prolog, Coq, TLA+, Isabelle, Lean), which represent the pinnacle of applying formal logic to guarantee system correctness – a testament to the enduring power of logical rigor in critical domains.

In the intricate dance between theory and practice, the principles of logic stand as an unshakeable foundation. They are the "rocks" upon which you can meticulously build your understanding and your systems. The more consistently you apply this critical thinking, driven by curiosity and a commitment to rigorous validation, the clearer your path becomes.

This clarity is not just about fixing today’s bugs, it’s about continually refining your mental models, fostering trust in your codebase, and equipping yourself to build increasingly robust and predictable systems in an ever-evolving technological landscape.

If you love problem solving, critical thinking, or have experiences on how you fixed an issue that looked different from how it initially seemed, feel free to connect with me at https://linkedin.com/in/hanqi91.

Resources

1. Article that motivated this handbook: Classical Reasoning and Debugging

2. 3 Formal proofs of modus tollens: https://en.wikipedia.org/wiki/Modus_tollens

3. Table of 24 syllogisms: https://en.wikipedia.org/wiki/Syllogism

4. Challenging Assumptions: Falsehoods software teams believe about user feedback

5. How assumptions and software evolve beyond your control: https://www.tdda.info/why-code-rusts

6. Relationship to Hypothesis Testing: https://sites.google.com/view/reasonedwriting/home/FRAMEWORK_FOR_SCIENTIFIC_PAPERS/HYPOTHESES/HOW_TO_TEST_HYPOTHESES/MODUS_TOLLENS

7. The Troubleshooting Mindset: https://www.autodidacts.io/troubleshooting/

8. Causal Diagrams from The Effect Book: https://theeffectbook.net/ch-CausalDiagrams.html

9. A systematic guide to the mindsets and practices of debugging: https://www.amazon.sg/Debug-Find-Repair-Prevent-Bugs/dp/193435628X

10. Constructing P in a way to ensure software correctness: https://www.hillelwayne.com/post/constructive/

11. Fail Fast by explicitly representing assumptions as assertions: https://www.martinfowler.com/ieeeSoftware/failFast.pdf

12. Deterministic Simulation Testing to tackle complex systems: https://pierrezemb.fr/posts/learn-about-dst/

13. GitHub’s Engineering System Success Playbook (ESSP) - Quality, Velocity, Developer Happiness on Business Outcomes: https://assets.ctfassets.net/wfutmusr1t3h/us6AUuwawrtNGTlwlT9Ac/f0fce86712054fc87f10db28b20f303b/GitHub-ESSP.pdf

14. Closed-world assumption: https://en.wikipedia.org/wiki/Closed-world_assumption

Glossary

• Axiom: A fundamental truth or rule accepted as a starting point for a logical or mathematical system, without requiring proof.

• Contrapositive: A logically equivalent form of an "if-then" statement (P⟹Q), which is ¬Q⟹¬P ("If not Q, then not P").

• Deductive Reasoning: A type of logical reasoning where a conclusion is necessarily true if its premises are true.

• Falsification: The principle, especially in science (from Karl Popper), that a hypothesis or theory must be capable of being proven false by empirical observation or experiment.

• Formal Logic: The study of abstract systems of reasoning and arguments based on their structure, independent of content.

• Hypothesis Testing: A statistical method for making inferences about a population based on sample data, typically by testing a null hypothesis (e.g., "P has no effect on Q") against an alternative hypothesis.

• Logical Fallacy: A flaw in the structure or content of an argument that makes it unsound or invalid, even if its conclusion might seem plausible.

  • Affirming the Consequent (Fallacy): An invalid argument form that mistakenly assumes if P⟹Q is true, and Q is true, then P must be true.

  • Denying the Antecedent (Fallacy): An invalid argument form that mistakenly assumes if P⟹Q is true, and P is false, then Q must be false.

• Modus Ponens: A valid argument form: If P⟹Q is true and P is true, then Q must be true.

• Modus Tollens: A valid argument form: If P⟹Q is true and ¬Q is true, then ¬P must be true.

• Mutation Testing: A software testing technique that involves deliberately introducing small, single-point faults (mutations) into code to assess the effectiveness and coverage of a test suite.

• Propositional Logic: A branch of logic that deals with propositions and their relationships using logical operators.

• Test-Driven Development (TDD): A software development methodology where tests are written before the code, guiding the development process and ensuring correctness.

• Truth Table: A table that systematically lists all possible truth values for a set of propositions and shows the resulting truth value of a complex logical statement.

• Vacuously True: Describes an implication (P⟹Q) that is considered true simply because its antecedent (P) is false.

One of the foundational elements of JavaScript programming is the application of logical operations to make decisions and control program flow.

In this guide, we'll delve into the basics of logical operations in JavaScript. I'll provide simple explanations and ample code snippets to make these concepts easier to understand.

Understanding Logical Operators

Logical operators in JavaScript let developers perform operations on values or expressions, playing a crucial role in effective decision-making within code.

The primary logical operators are && (AND), || (OR), and ! (NOT). Let's look at each one now.

1. AND (&&) Operator

The AND (&&) operator in JavaScript is a logical operator that combines two or more conditions. It returns true only if all the conditions being evaluated are true. If any of the conditions is false, the entire expression evaluates to false.

Example:

let isSunny = true;
let isWarm = true;

if (isSunny && isWarm) {
  console.log("Perfect weather for outdoor activities!");
} else {
  console.log("Maybe another day.");
}

In this example, the isSunny && isWarm condition must be true for the message about perfect weather to be displayed. If either isSunny or isWarm is false, the else block is executed.

Let's look at some scenarios when the AND operator is particularly useful.

When combining conditions: Use && when you want an action to be taken only when multiple conditions are met simultaneously.

if (userIsLoggedIn && userHasPermission) {
  // Perform a privileged action.
} else {
  // Display an error message or redirect to login.
}

In guard clauses: Use && in guard clauses to ensure that certain conditions are met before proceeding with further code execution.

function performAction(user) {
  if (!user || !user.isLoggedIn) {
    return; // Exit early if the user is not logged in.
  }

  // Continue with the action for logged-in users.
}

For form validation: In scenarios like form validation, you might use && to check multiple conditions before allowing form submission.

if (isUsernameValid && isPasswordValid && isEmailValid) {
  // Submit the form.
} else {
  // Display an error message.
}

The AND operator is useful when you want to ensure that all specified conditions are true before proceeding with a particular action or decision in your code. It's a fundamental tool for creating more nuanced and context-specific logic in your JavaScript programs.

2. OR (||) Operator

The OR (||) operator in JavaScript is a logical operator that returns true if at least one of the conditions it connects is true. It is often used when you want an action to occur if any one of multiple conditions is met.

Here's a basic example to illustrate the OR operator:

let hasCoffee = true;
let hasTea = false;

if (hasCoffee || hasTea) {
  console.log("You can enjoy a hot beverage!");
} else {
  console.log("No hot beverage available.");
}

In this example, the hasCoffee || hasTea condition is true because hasCoffee is true. As a result, the message "You can enjoy a hot beverage!" will be logged.

Here are some scenarios where you might want to use the OR operator:

Fallback Values:

let userInput = ""; // User didn't provide a value
let username = userInput || "Guest";
console.log("Welcome, " + username);

In this case, if the user didn't provide a username (userInput is an empty string), the OR operator assigns a default value of "Guest" to username. This is a common pattern for providing fallback or default values.

Checking for Multiple Conditions:

let isWeekend = false;
let isHoliday = true;

if (isWeekend || isHoliday) {
  console.log("It's time for a break!");
} else {
  console.log("Back to work.");
}

This example uses the OR operator to check if it's either the weekend or a holiday, indicating that it's time for a break.

Form Validation:

let username = "john_doe";
let password = "";

if (username && password) {
  console.log("Form submitted successfully!");
} else {
  console.log("Please fill in both username and password.");
}

Here, the OR operator can be used to check if either the username or password is missing. If either condition is true, it prompts the user to fill in both fields.

The OR operator is useful when you want an action to occur if at least one of the specified conditions is true. It's commonly employed in scenarios involving fallback values, checking multiple conditions, or form validation where any of several fields need to be filled.

3. NOT (!) Operator

The NOT (!) operator in JavaScript is a unary operator that negates the truthiness of a value. It's used to invert a boolean value or a truthy/falsy expression. In simpler terms, it turns true into false and false into true. Here's how it works:

let isSunny = true;

// Using NOT operator to invert the value
let isNotSunny = !isSunny;

console.log(isNotSunny); // Output: false

Now, let's discuss when you might want to use the NOT operator:

Checking for Negation: The most straightforward use of the NOT operator is when you want to check for the negation of a condition. For example:

let isRaining = false;

if (!isRaining) {
  console.log("It's not raining. Enjoy the day!");
} else {
  console.log("Don't forget your umbrella!");
}

In this case, the !isRaining condition is true when it's not raining. It provides a concise way of expressing the idea that it's a good day when it's not raining.

Checking for Falsy Values: The NOT operator is often used to check if a value is falsy. Remember that in JavaScript, certain values are considered falsy, such as false, 0, null, undefined, NaN, and an empty string "". The NOT operator can be handy for checking whether a variable holds a falsy value:

let userRole = null;

if (!userRole) {
  console.log("User role is not defined. Assigning a default role.");
  userRole = "Guest";
}

In this example, if userRole is null (a falsy value), the condition !userRole evaluates to true, and a default role is assigned.

Creating Clearer Conditions: The NOT operator can also be used to make conditions more explicit or readable. For instance:

let isLoggedIn = false;

if (!isLoggedIn) {
  console.log("User is not logged in. Redirect to login page.");
}

This condition checks if the user is not logged in and takes action accordingly.

The NOT operator is useful when you need to negate a boolean value or check for falsy values, providing a concise and readable way to express conditions in your JavaScript code.

How to Combine Logical Operators

You can combine logical operators to create more complex conditions, introducing parentheses to control the order of evaluation.

Let's consider an example where we want to determine if a person is eligible to enter a club based on their age and whether they have a valid ID. The conditions for entry are as follows:

• The person must be at least 18 years old.
• If the person is between 16 and 18 years old, they can enter only if they have a valid ID.
• If the person is under 16, entry is not allowed.

Here's the JavaScript code for this scenario:

let age = 17;
let hasValidID = false;

if ((age >= 18) || (age >= 16 && hasValidID)) {
    console.log("Welcome to the club!");
} else {
    console.log("Entry not allowed.");
}

In this code:

• age is set to 17, indicating that the person is 17 years old.
• hasValidID is set to false, indicating that the person does not have a valid ID.

Now, let's evaluate the condition within the if statement:

1. (age >= 18) evaluates to false because the person is not 18 or older.
2. (age >= 16 && hasValidID) evaluates to true && false, which is false. This is because the person is 17, which satisfies the first part of the condition, but they don't have a valid ID.

Since both parts of the condition are false, the code block inside the else statement is executed, resulting in the output:

Entry not allowed.

This example demonstrates how logical operators can be combined to create complex conditions, allowing you to control the flow of your program based on various factors.

Conditional Statements

Logical operators are frequently employed in conditional statements (if, else if, and else) to dictate program flow based on specific conditions.

1. if Statement:

The if statement in JavaScript is used to execute a block of code if a specified condition is true. Logical operators often play a crucial role in defining these conditions.

let isHungry = true;
let hasFood = true;

if (isHungry && hasFood) {
  console.log("Let's have a meal!");
} else {
  console.log("No need for a meal right now.");
}

In this example, the && (AND) operator combines two conditions (isHungry and hasFood). The block of code inside the if statement will execute only if both conditions are true. If either isHungry or hasFood is false, the code inside the else block will run.

2. else Statement:

The else statement is paired with the if statement to execute a block of code when the specified condition is false.

let isNight = true;

if (isNight) {
  console.log("It's nighttime. Sleep tight!");
} else {
  console.log("It's daytime. Enjoy your day!");
}

Here, the if statement checks if isNight is true. If it is, the corresponding message is printed. If isNight is false, the else block is executed, providing an alternative message for daytime.

3. else if Statement:

The else if statement accommodates multiple conditions, allowing for more complex decision-making.

let timeOfDay = "morning";

if (timeOfDay === "morning") {
  console.log("Good morning!");
} else if (timeOfDay === "afternoon") {
  console.log("Good afternoon!");
} else {
  console.log("Good evening!");
}

In this case, the code greets users differently based on the value of timeOfDay. The === operator is used for strict equality comparison, and logical operators like && or || can be incorporated to form more intricate conditions.

These examples illustrate how logical operators are employed within if, else, and else if statements to control the flow of a JavaScript program based on specific conditions.

Ternary Operator

The ternary operator, often denoted by ? :, provides a concise way to express conditional statements. It's a shorthand version of an if-else statement. The basic syntax is:

condition ? expression_if_true : expression_if_false;

Here's a breakdown of the components:

• condition: a boolean expression that is evaluated. If it is true, the expression before the : is executed – otherwise, the expression after the : is executed.
• expression_if_true: the value or expression returned if the condition is true.
• expression_if_false: the value or expression returned if the condition is false.

Now, let's take a closer look at the example provided:

const weather = isSunny ? "Enjoy the sunshine!" : "Grab an umbrella!";

In this example:

• isSunny is the condition being checked. If isSunny is true, the value of the entire expression becomes "Enjoy the sunshine!". If isSunny is false, the value becomes "Grab an umbrella!".
• The ? is like asking a question: "Is it sunny?" If the answer is yes, then "Enjoy the sunshine!" is the response (before the :). If the answer is no, then "Grab an umbrella!" is the response (after the :).

This can be seen as a shorthand way of writing an if-else statement. The equivalent if-else statement for the example would be:

let weather;
if (isSunny) {
  weather = "Enjoy the sunshine!";
} else {
  weather = "Grab an umbrella!";
}

Both the ternary operator and the if-else statement achieve the same result, but the ternary operator is more concise and is often used for simple conditional assignments.

It's important to note that using the ternary operator excessively or in complex scenarios can reduce code readability, so it's best used for straightforward conditions.

Switch Statement

The switch statement handles multiple conditions efficiently, particularly when there are several possible values for a variable. Extending our day-of-week example:

let dayOfWeek = "Wednesday";

switch (dayOfWeek) {
  case "Monday":
    console.log("It's the beginning of the week.");
    break;
  case "Wednesday":
    console.log("It's the middle of the week.");
    break;
  case "Friday":
    console.log("It's the end of the week.");
    break;
  default:
    console.log("It's an ordinary day.");
}

Here, the switch statement triggers the appropriate message based on the day of the week.

Short-Circuit Evaluation

JavaScript leverages short-circuit evaluation with logical operators, optimizing performance by halting evaluation once the result is determined.

Example 1: Short-Circuit with && Operator

let isTrue = false;
let result = isTrue && someFunction();

console.log(result); // `someFunction()` is not called if `isTrue` is false

In this example, someFunction() is only called if isTrue is true, showcasing the efficiency of short-circuit evaluation.

Example 2: Short-Circuit with || Operator

let isLoggedIn = false;
let username = isLoggedIn || "Guest";

console.log("Welcome, " + username); // If not logged in, the default username is "Guest"

Here, username is assigned the default value "Guest" only if the user is not logged in, thanks to short-circuit evaluation.

Truthy and Falsy Values

In JavaScript, logical operators can be used with non-boolean values. Understanding truthy and falsy values is crucial in such scenarios.

Truthy and Falsy Values Overview

Every value in JavaScript has inherent truthiness or falsiness. Falsy values include false, 0, null, undefined, NaN, and an empty string (""). Truthy values encompass all values not explicitly falsy.

Example: Truthy and Falsy Values

let userRole = ""; // An empty string is falsy

let roleMessage = userRole || "User";

console.log("You are a " + roleMessage); // If `userRole` is falsy, default to "User"

Here, the default value "User" is assigned to roleMessage only if userRole is falsy.

Summary Table

Let's provide a quick reference for the different logical operators:

Practical Applications

Logical operators play a crucial role in real-world JavaScript applications. Here are some practical examples:

Form Validation

let username = "JohnDoe";
let password = "secretp@ss";

if (username && password) {
  console.log("Form submitted successfully.");
} else {
  console.log("Please enter both username and password.");
}

In this scenario, the form submission is validated by ensuring both the username and password are provided.

Responsive UI

let screenWidth = 800;

if (screenWidth > 600 && screenWidth <= 1024) {
  console.log("Displaying a tablet-friendly layout.");
} else if (screenWidth > 1024) {
  console.log("Displaying a desktop layout.");
} else {
  console.log("Displaying a mobile-friendly layout.");
}

Logical operators are often used to determine the layout based on the screen width, creating a responsive user interface.

Access Control

let userRole = "admin";
let isLoggedIn = true;

if (userRole === "admin" && isLoggedIn) {
  console.log("Access granted to admin dashboard.");
} else {
  console.log("Access denied.");
}

Logical operators help control access by verifying both the user role and login status.

Conclusion

Mastering logical operators is integral to writing effective and meaningful JavaScript code. Whether you're creating conditions, making decisions, or controlling program flow, logical operators are essential tools.

By exploring these concepts through numerous examples, you're well-equipped to apply them in your projects. Additionally, understanding truthy and falsy values enhances your ability to work with non-boolean contexts.

Use this guide as a foundation for writing clear and concise JavaScript, and you'll be on your way to building robust and responsive web applications. Happy coding!

In the first term of college, I was introduced to a subject called Logic. In the "I think, therefore I am" fashion, you might think this would be an easy subject. After all, we are all taught how to think throughout school and, since all of us "think", there would be nothing unfamiliar in the subject that could trick the less-than-alert mind.

Shockingly enough, in the same way people have a hard time with Math in college, Logic was the subject back then where students failed the most.

Why is Propositional Logic Hard?

What could be the reason for that? The only thing, in theory, that might prove troublesome was the amount of unfamiliar terminology involved in propositional logic.

The professors used Latin expressions like "modus ponens" and "modus tollens" to define some sort of processes of inferring a result, and these often caused people to complain about the "esoteric nature" of the subject.

We can call this metalanguage. In this case, it can be roughly translated as "fancy language to talk about a topic that makes it harder for the students to understand what the thing really is". And it has its charm in the sense of categorizing things.

Intense practice with examples, however, can help students learn much more quickly than filling up their hard drive with vocabulary they'll probably only use to pass the tests and then never use again – except in those word game puzzles.

This is the point where I get in. Having had good results in Logic back then, I was shocked with how my classmates talked about Logic on social media (sentences like "this is not a topic for first term – it's too hard", or "why do they expect me to learn Latin? This is the 21^st century!" were common).

Fortunately for me, instead of focusing on the naming of each inference rule I heard of, I decided to focus on understanding what each one led to – which probably made me worry less about the topic than my peers.

Ergo… 😋 just kidding. SO, let me try to show you in this article some of these rules of propositional logic.

I will try to avoid the fancy metalanguage and present you with a couple of examples to help show you that you already think the way the Logic subject presents to you.

You just skip the part of using a fancy name and giving a complicated explanation for the process itself.

Modus Ponens, Modus Tollens, Hocus Pocus, Abracadabra...

Let's begin with the really tough ancient Latin names: Modus Ponens and Modus Tollens. Modus ponens is defined in Wikipedia as follows:

In propositional logic, modus ponens (/ˈmoʊdəs ˈpoʊnɛnz/; MP), also known as modus ponendo ponens (Latin for "method of putting by placing") or implication elimination or affirming the antecedent, is a deductive argument form and rule of inference. It can be summarized as "P implies Q. P is true. Therefore, Q must also be true."

Now I don't know about you, but when I see phonetic symbols and words that I have no idea what they mean – but someone is telling me I should – my heart skips a beat.

In fact, we could go straight to the last two sentences here to get to the point. The first long and haunting sentence basically serves to tell you "heroes, there is a dark and menacing-looking forest ahead of you. Leave behind all hope, ye who enter."

The bottom line, though, is "when the first thing is true, the second is, too. Since we know that the first is true, what do you make of the second?"

See? After beating the Latin words and hacking and slashing through 'propositional', 'implication', 'antecedent', 'deductive', and 'inference', you just come to the conclusion something is true because another one is true as well. Great! Now moving on.

Example of modus ponens

As I mentioned before, I believe examples work better than fancy words, so let's come up with a simple example:

I'm from a country where there is no snow at all, ever. When I'm in the US during the winter, I love making snow angels. It's winter, and I'm in the US. What do you think I'll do when it snows?

If what you thought was "you'll make snow angels, duh", congratulations! You have just gone through the propositional logic we talked about earlier. And you did not have to say a prayer in Latin, use magic words, cast a spell, or anything else. 😊

Peas and Queues

Now you may ask, "ok, but what about the P and Q thing in the last two sentences of the definition you shamelessly CTRL-C-ed and CTRL-V-ed from Wiki?"

Good catch! These are representations of what we call propositions (that's why this is called "propositional logic", by the way).

A proposition is nothing more than a sentence. They could have said "sentence A" and "sentence B" instead. But someone in the past chose P and Q, just like in Math you'd go with X and Y.

Using the example above, being in the US in the winter (proposition P), to me, means (implies) that I must get to the ground and wave my arms and legs frantically to make what looks like the shape of an angel.

Now, you know I'm in the US in winter and it snows (I told you that "P" is true). Here is the moment where we conclude that I'll do what I say I do whenever the first sentence is true – I'll act according to the second proposition ("Q") and make it true as well.

Now that you know how silly the author of this article is and understand the first rule better, let's move on to the next rule, avara kedavra… I mean, modus tollens.

Here, Wikipedia "helps" us once again with a beautiful, wordy definition:

In propositional logic, modus tollens (/ˈmoʊdəs ˈtɒlɛnz/) (MT), also known as modus tollendo tollens (Latin for "method of removing by taking away") and denying the consequent, is a deductive argument form and a rule of inference.

Modus tollens takes the form of "If P, then Q. Not Q. Therefore, not P." It is an application of the general truth that if a statement is true, then so is its contrapositive. The form shows that inference from P implies Q to the negation of Q implies the negation of P is a valid argument.

If you did not love going through 'denying the consequent' and 'so is its contrapositive', you are a heartless human being.

Example of modus tollens

Again, here comes Mighty Mouse to save the day and tell you to focus on "If P, then Q. Not Q. Therefore, not P."

What this rule is saying is actually a complement of what the first one says. If the second sentence is not true, then the first probably isn't, either. Thus, if I'm not making snow angels now, what would you make of it?

Since we have paired the idea of being in the US in the winter and making snow angels, at least some part of the first proposition can't be true: either I'm not in the US or it's not winter.

Anyways, since, for the first proposition to be true, these two parts have to be, we can assume that the first sentence is, somehow, false.

And just like that you realize you already know two propositional logic rules without even having to consult your dictionary! 😃

In summary

In this article, we saw that it is possible to know (and practice) logic without even studying it. We also learned that we already know more logic than we might imagine and that the author of this article loves playing in the snow.

As a bonus, we practiced two rules of propositional logic, whose fancy names might scare you from even looking at them: modus ponens and modus tollens.

There are others, though. If you liked the way they were explained here and would like to see more logical rules explained in a form you will definitely understand – and possibly realize you already make use of – send your feedback to yours truly on Twitter. I'd love to walk you through the other rules as well – and maybe share more of my silliness through examples.

Happy coding! 😉

There are a few different incarnations of it – some have slightly different wording, different names, or change the items in the riddle slightly. But they are all the exact same core problem.

The riddle itself is used as a benchmark in the evaluation of constraint satisfaction problems for computer algorithms.

What is the Einstein Riddle?

Even the origin of it the riddle is a little unclear. It's famously known as the Einstein Riddle because it was supposedly created by Einstein as a young man for fun. Others say it was used by Einstein to only select the smartest PhD students he would supervise.

But there are some claims online that it actually was invented by the author of Alice's Adventures in Wonderland, Lewis Carrol.

It's highly unlikely that it was written by Einstein, but that doesn't really matter. What's important is that, with a basic understanding of truth tables (and a bit of patience), you can solve it, too.

How to Solve Einstein's Riddle

I'm now going to give you a list of clues, and then you will need to answer a question at the end of the clues.

Just to be absolutely clear, all the clues are enough for you to solve it. You don't need any extra hints, and there aren't any assumptions I expect you to know.

There are 5 houses painted five different colors.
In each house lives a person with a different nationality.
These five owners drink a certain type of beverage, smoke a certain brand of cigar, and keep a certain pet.
No owners have the same pet, smoke the same brand of cigar, or drink the same beverage.

• The Brit lives in the red house
• The Swede keeps dogs as pets
• The Dane drinks tea
• The green house is on the left of the white house
• The person who smokes Pall Malls rears birds
• The owner of the yellow house smokes Dunhill
• The green house’s owner drinks coffee
• The man living in the center house drinks milk
• The Norwegian lives in the first (leftmost) house
• The man who smokes Blends lives next to the one who keeps cats
• The man who keeps horses lives next to the man who smokes Dunhill
• The owner who smokes BlueMaster drinks beer
• The German smokes Princes
• The Norwegian lives next to the blue house
• The man who smokes Blends has a neighbor who drinks water

Now to solve, tell me who owns the fish?

I solved it, but it did take me a couple attempts and a bit of scribbling on paper.

How I Approached the Problem

To solve the problem, the first thing I did was to try and group together the clues. There are two references to the green house in the clues, so I tried to "solve" and consider those two clues together when I was able to.

I then also filled out the center house's beverage as one clue immediately tells you, and I was also able to immediately fill out the leftmost house's nationality.

I essentially drew a really basic grid and eliminated and filled in possibilities based initially just on the clues. Then as I filled in more, I was able to fill in more details on other houses.

I don't want to keep going with the hints if you want to solve this for yourself, but that's a starting point.

A screenshot of part of a 5x5 table with every different possibility of Nationality, Color, Beverage, Pet and Smoking Cigar that can be removed on click.

To try and make it easier for anyone who wants to solve it or check their answer, I have made a basic site you can find here: http://einsteins-riddle.com/ – the screenshot from above is a part of the grid on the site.

On that site, you'll find a table with all the options laid out as clickable buttons. The grid is initially filled out with all the possibilities, and as you learn more you can remove possibilities until eventually there is only one option left.

At the bottom is a "Check Answer" button that will evaluate what you have left on your grid.

Try and solve it and see how you get on! If you prefer to do it via paper please do so.

I wish you luck 😊

If it stumps you, and you want to know how to solve it, you can find the solution here.

Why are Truth Tables Helpful?

I enjoy trying to work through these truth table problems, as it helps improve my clarity of thought.

Sometimes when I'm coding and need to carefully consider some complex Boolean states in my code (not this, and not that OR this and that (and not those)) I think that these puzzles help me reason more clearly to simplify my code.

They also help me technically plan out my approach to a problem, from the very beginning to the eventual solution.

I start from a basic set of requirements and no idea how all they fit together. But as I move along, I can go through a process of fact finding, checking edge cases, verifying/testing my logic against the requirements and finally submitting my work. All of these steps translate exactly to software development.

Whenever you have a complicated set of states you are confused by, draw a basic truth table. Or however you want to represent the problem. Breaking it down into smaller and smaller problems will allow you to solve almost anything.

Conclusion

I hope this has been an enjoyable brain teaser, and that you solved as much or as little as was fun for you.

I share my writing on Twitter if you enjoyed this article and want to see more.

And that's great – but you should be careful that you don't end up using a logical fallacy to help you make your point.

What is a Logical Fallacy?

A logical fallacy is an error in reasoning that makes your argument less effective and convincing. And you want to be able to spot these fallacies in other people's arguments (and your own) so you can call them out or fix your own strategy.

There are two major types of logical fallacies, formal and informal.

In formal fallacies, there's a problem with how you structure your argument, and how you're making your points. You might be speaking the truth, but the logic breaks down because of the way you're putting your arguments together.

In informal fallacies, there's a problem with what you're saying, and the information might be incorrect or misleading.

In this article, we'll focus on these informal fallacies as they can be pretty common in everyday debate. And keep in mind that we're not talking about the effectiveness or persuasiveness of your argument, here – after all, fallacious arguments can be very persuasive.

Instead, it's all about giving you the tools to identify these weak arguments so you don't make these mistakes in your reasoning.

List of Logical Fallacies with Examples

In this article, we'll look at the most common informal fallacies so you can learn to identify them and avoid them.

The Sunk Cost Fallacy – Definition and Example

Have you ever finished a task (that you really didn't want to complete) simply because you'd put so much time and effort in already? You probably felt like you didn't want all that hard work to go to waste, or to be for nothing.

You were likely falling prey to the sunk cost fallacy. It states that it's actually better to abandon a project that's going nowhere (at any point) rather than waste any more time, energy, and resources trying to finish it for the sole purpose of finishing it.

The reason for this might seem counterintuitive, but think about it: rather than spend another minute of your precious time doing something that isn't going anywhere, it's better to switch gears ASAP (before you spend any more time) and start putting your energy into something productive.

Example of a Sunk Cost Fallacy

Let's say that you've decided to write a book. You spend hours and hours doing research, making an outline, and writing the first 10 chapters. You've put months if not years of your life into writing this book.

But then perhaps your interests change, or you no longer wish to be an author. You might think you should finish the book because you're so close or because you've already spent so much time and energy on it.

Instead, though, you should leave that project behind and focus on what's ahead. Maybe you're trying to get a new job, or learn a new skill, or move to a new city. Any of these current and relevant initiatives would suffer if you continued to work on your unsuccessful book project.

So how do you distinguish between this sunk cost fallacy and persevering until you finish something difficult? Well, it helps to think about whether the experience will benefit you in the long run – in which case, it would be helpful to see it through.

For example, let's say you've done three years of a four year degree program at a college or university. But your interests have changed, and you want to pursue something that doesn't require that degree.

Still, it might make sense to finish the program, as a college degree typically only helps you in future career moves – not to mention the life experience you'll gain in the process.

The Ad Hominem Fallacy – Definition and Example

Ad hominem means "against the person" in Latin. So the ad hominem fallacy happens when you attack a person's character, appearance, personality, or other irrelevant aspects in an argument instead of attacking what they're saying.

These types of attacks are fallacious because they're not relevant to the argument, and so they distract from the point at hand. It doesn't really matter if you think your mom is being a jerk – she's still right that you shouldn't speed while driving.

Example of an Ad Hominem Fallacy

Many people associate ad hominem fallacies with political debates. Unfortunately, some candidates don't seem to be able to help themselves.

What if Candidate A said that you shouldn't trust Candidate B because Candidate B doesn't dress well? There's no established link (that I know of!) connecting a "good dresser" with trustworthiness or good political decision-making, so this would be an ad hominem fallacy.

Or what about when Candidate A insults Candidate B for being too nerdy, or not cool enough? These qualities, first of all, are subjective, and second, they shouldn't affect Candidate B's ability to govern effectively.

On the other hand, sometimes people just deliver insults that aren't actually logical fallacies because they aren't part of the argument. For example, if you were to say that all New Yorkers are rude and unfriendly (but you aren't trying to make a point), that's just an (untrue) insult and not a fallacy.

So when you're debating someone, leave their personal characteristics out of it unless they're relevant to your point.

The Straw Man Fallacy – Definition and Example

When you hear the term "straw man", what comes to mind? Probably a figure of a person made of straw, like a scarecrow, or something else insubstantial. That straw figure isn't too solid, and you could just knock it over with a little push or a strong gust of wind.

The same holds true for straw man fallacies – they represent weaker arguments that are oversimplified or that distract from the main point the debater is trying to make.

So instead of responding to someone with a well-reasoned, to-the-point counterargument, someone using a straw man might reframe that person's argument in a vastly oversimplified way, or might latch on to an irrelevant point that's tangentially related and go after that. Basically, they create a "straw man" in place of a real argument.

Example of a Straw Man Fallacy

Perhaps you're discussing education with someone who believes that for-profit colleges are harmful to the broader educational system because they take advantage of their students, don't provide them high-quality education, and waste students' money.

Instead of responding with appropriate counterpoints (such as concrete examples of for-profit colleges who benefit their students), you try to undermine the person's argument by saying "See, they're against higher education and don't think people should go to college!"

In fact, the person has a much more nuanced claim, but you've ignored it and constructed a vague straw man fallacy in response.

Or maybe you're trying to figure out a solution to the number of people living without homes in your area. You might suggest setting up temporary (or permanent) tiny homes for houseless individuals, allocating resources for trash cleanup, and providing medical care during the pandemic.

Your opponent, however, might misconstrue your argument and insist that you're trying to welcome the homeless community to your area by providing so many benefits for them.

The False Dilemma Fallacy (AKA The False Dichotomy Fallacy) – Definition and Example

Have you ever argued with someone and they only give you two options when you feel like there are many more? Chances are they were falling into the trap of the false dichotomy.

Using a false dichotomy or false dilemma in an argument means that you oversimplify your argument or only focus on two outcomes when in fact there are other reasonable possibilities.

This strategy tries to hide important facts and considerations and tries to trick your opponent into thinking the argument is more cut and dry or simpler than it really is.

Example of a False Dilemma Fallacy

Let's say that you're still working on finding homes for houseless people in your community. You might suggest a range of housing options, such as tiny houses, community living, repurposing empty apartment buildings, and so on.

You could also offer to relocate people who wished to leave your area, or you could help them find jobs so they could afford their own home eventually.

Someone opposed to your efforts might say that houseless people either need to get a job so they can afford their own place or leave town. And they wouldn't offer any of the other options you explored.

To someone uninformed about the crisis of homelessness in your area, those two options might sound reasonable. But to someone who had studied the issue extensively, it would be clear that those extremes weren't the only options.

How about another example?

Maybe you're at a political debate and one of the candidates asserts that you're either a Democrat or you're a Republican in an effort to make some point.

In reality, though, this likely wouldn't be the case. Certain people in attendance could be Libertarians, for example – but the politician didn't include that as an option.

So keep in mind, when you're making an argument, that there are likely many nuances that relate to your point. Don't ignore them – simply take them into account and build them into your argument.

Do keep in mind, though, that some arguments really only do have two viable options – so they wouldn't represent false dichotomies. For example, if a General says "Either you're with us or you're against us" during a war, those are the two main options.

The Slippery Slope Fallacy – Definition and Example

The slippery slope fallacy refers to arguments that get increasingly dramatic and out of hand very quickly. Especially when the ever-more-dramatic conclusions aren't realistic or likely to happen.

These types of arguments are often made when someone wants to emphasize how drastically bad an outcome would be.

Perhaps a better name for this fallacy, though, would be the Domino Effect – one thing might lead to another which might lead to another which might...and so on. The problem with these assumptions is that they're all hypothetical, which makes your overall claim very weak.

Example of a Slippery Slope Fallacy

Perhaps your teenager wants to buy themselves a truck. They've been saving up, and they have the money. But you don't want them to drive a truck, for any number of reasons – perhaps you're worried about gas mileage, or parking in a city, or that they'll take it off-roading and get hurt.

Now, these are all fairly reasonable arguments as to why you wouldn't want your kid driving a truck, and they could easily result from that purchase.

But what if, instead of these sensible arguments, you let your emotions get away with you and instead said "You can't get a truck because then all your friends will want trucks and their whole families will then get trucks which they'll start driving all over the place and over-polluting the earth!"

You can see how that escalated quickly, right? And even though the arguer has a point about emissions in general here, it's probably not a realistic outcome of this situation (and it's probably not an effective argument to use to convince your teen not to buy a truck).

The Circular Reasoning Fallacy – Definition and Example

Have you ever noticed someone arguing in a way that they seem to go around in a circle? It might seem like they're making an argument, but they'll use their conclusion to justify their argument, and their argument to justify their conclusion.

If this sounds confusing, that's because it is. When someone says something like "This tee-shirt is wet because it's covered in water," they're making a fallacious argument. In fact, the tee-shirt is wet because you fell in a lake, for example.

In this case, someone saying something's wet because it's covered in water is just stating the obvious. They're not offering an explanation for why it's that way.

You can often recognize a circular argument when the conclusion – the thing the person is arguing in favor of (or against) – is also one of the premises (or arguments) they're using to justify their assertion (it's wet because of water, which is wet). In other words, if this is true because that is true, that is true because this is true.

Example of a Circular Reasoning Fallacy

So here's another example: you say that your friend Jessie lies all the time, and you know this because they never tell the truth. But your argument (that Jessie lies all the time) and your premise (because they never tell the truth) are the same thing. That means that this is a circular argument.

Here's another way to think about it: if your argument's premises assume that your conclusion is true right from the beginning, rather than proving or finding that it's true, you're arguing in a circle. Just remember: if your argument is defined in terms of itself, it is probably fallacious.

And if you want to know why it's sometimes called "Begging the Question," you can read all about it here. (Hint: it's a mistranslation of 16th century Latin that was actually a mistranslation of the ancient Greek phrase...fascinating.)

The Equivocation Fallacy – Definition and Example

Equivocation means that you're taking a word or phrase and changing its meaning slightly so that it means something else. Or you're using one word or phrase instead of another to hide the true meaning of what you're saying.

In other words, you're being ambiguous with your language. If something is ambiguous, it means that you can interpret it in more than one way or that it has two meanings. This is exactly what happens in an equivocation fallacy.

The word "equivocation" comes from the Latin for "equal voice" – meaning that it appears that what you're saying means one thing but it really means or can also mean something else.

The important thing to remember about equivocation fallacies is that they attempt to deceive in some way.

You might jokingly use ambiguity in a story, play, or playful conversation – but you're not really trying to convince your listener of something serious (or it's clear that you're being tricky or silly).

But when you use equivocation in a serious debate, political campaign, advertisement, or something similar, that's when it's more malicious and fallacious.

Example of an Equivocation Fallacy

So how do you tell the difference? Be mindful of the setting in which you use ambiguous language, or you see it being used.

Here's a simple example: "Nine out of ten dentists recommend Colgate toothpaste." First of all, what does "recommend" mean here? This could be misleading – do they really specifically recommend Colgate, or do they just recommend that you brush your teeth in general?

How about another example? What if you break up with someone, and they ask you never to drive by their house again. So you walk by – but you justify it by saying that you didn't drive by. You walked.

Clearly your ex meant that they didn't want you going by their house in any way, but you used the ambiguity of the situation to tweak their words and do it anyway.

The Post Hoc Fallacy – Definition and Example

You might have heard the phrase "post hoc ergo propter hoc" before, even if you've never studied Latin.

This Latin phrase translates to "After this, therefore because of this." Now that might sound like a jumble of conjunctions and such, but it basically means that if event B happened after event A, that must mean that event A caused event B.

Post hoc ergo propter hoc → (B is) After this (A), therefore (B is) because of this (A).

This fallacy says that because one thing happened after another, it means that the first thing caused the second thing happen. The argument is a fallacy when someone asserts something based purely on the order that things happened. This means they're not taking into account other factors that affected or caused the event to happen.

If this sounds a bit familiar to you, it means you might have thought about correlation vs causation before. The post hoc fallacy is related, but is more focused on the order of events (and their relationship).

Example of a Post Hoc Fallacy

Let's look at an example to help decipher what's going on in this type of fallacious argument.

Maybe there was an earthquake during which a building fell down. That's a pretty clear example of causality – the earthquake (event A) caused the building to fall down (event B).

But what if, after that same earthquake, a lot of people moved away from the city? Now, some of them might have moved because the earthquake was the last straw. But many might have fled because of rising housing costs, pollution, over-crowding, poor infrastructure, poor schools, or a bunch of other factors.

In other words, the earthquake likely wasn't the only direct cause of people moving away.

So anyone who argued "Look, people are moving out of the city because of the earthquake!" and didn't account for all these other likely causes was making a fallacious argument.

Here's another example: perhaps you're searching for a job, and you're not having any luck. But then someone gives you a good luck charm, and after a few more applications, you get a job.

You might be tempted to think that the good luck charm got you the job. But what's more probable is that you put a lot of effort into your applications, you studied really hard for your interviews, and you found your perfect company fit.

The Appeal to Authority Fallacy (AKA Argumentum ad Verecundium Fallacy) – Definition and Example

When you're gathering evidence to support your conclusion, you'll likely want to cite some experts. They've done research on the subject and know a lot about it, so it makes sense to use their knowledge and opinions to support your own arguments.

But be careful – if you don't use those expert's information correctly, or if you assume they're always right because they're experts, you could be falling prey to the appeal to authority fallacy.

An appeal to authority fallacy is easy to commit, but can be hard to recognize. This is because of the weight we all give to "authorities" in various subjects.

When you're engaging in an appeal to authority fallacy, you're likely either misusing someone's authority, citing an irrelevant authority, or citing a poor authority.

Let's see what these look like with some examples.

Example of an Appeal to Authority Fallacy

Let's say your mom's a lawyer and you seek her advice about a particular legal problem you have. If she practices that type of law and has experience with the problem you're having, you can likely cite her authoritative opinion with confidence.

But if you're arguing with your mom about the best way to save the sea turtles, and she asserts that she knows best because she's an intelligent person, she's using her own authority in a fallacious way (and with little to no justification).

Here's another example. Perhaps you watch a lot of Greenbay Packers football, and Aaron Rogers is your favorite quarterback. You happen to see a State Farm insurance commercial where Aaron endorses State Farm's services. You might think, "Well, I like Aaron Rogers, and he recommends State Farm, so it must be great insurance!"

While State Farm might be great insurance, Aaron Rogers doesn't have the authority to say so. He's an authority on being a great quarterback, but not on the quality or efficacy of insurance. So this is an example of an irrelevant appeal to authority.

So, when you're searching for evidence to back your claim, just remember – authorities aren't the only sources you should cite.

And you shouldn't just expect people to trust what those experts say with no evidence. After all, even the experts can be wrong, and just because they know a lot about one thing doesn't mean they know a lot about everything.

The Appeal to Ignorance Fallacy – Definition and Example

No one knows everything – it's just a fact of being human. We're all still learning, and while some might know more than others, we'll all be ignorant about certain things.

With that in mind, it's pretty easy to see why the appeal to ignorance fallacy is so common and so useless.

When you say something like "Well, no one's ever seen Nessie (the Loch Ness Monster) before, so they can't prove that she's real", you're making an appeal to ignorance. Why? Because no one knows whether she exists or not – because they've never seen her!

But the clearest way you can tell this is an appeal to ignorance fallacy is that you can turn it right around, and it still seems to make sense: "Well, no one's ever seen Nessie before, so they can't prove that she's not real!"

Either way, in both these claims, you're making an assertion based on something no one knows (the ignorance bit). Because no one knows it, you shouldn't use it in an argument.

Example of an Appeal to Ignorance Fallacy

Let's look at another example of an appeal to ignorance fallacy in action.

Perhaps you're an archaeologist who's studying an ancient civilization that lived around 2000 years ago. You study any remaining stone structures, pottery, tools, jewelry, and anything else they left behind.

You try to piece together what life would've looked like for these people based on their artifacts, where they lived, nearby societies, and so on. But you have no written evidence that tells you anything more. No one has found any inscriptions, written documents, or anything else with writing on it.

It would be tempting to assert that, since no one has ever found any evidence of writing, this society didn't have a written language. "We've never found documents or inscriptions, so they must not have written their language down."

But you could also assert that, even though no one has found those documents yet, they still might be out there and just haven't been excavated and discovered yet.

This argument is an appeal to ignorance, because you don't know something/haven't seen any evidence of something, but you're using it to support your argument (that the society doesn't have a written language) all the same.

The Appeal to Popular Opinion Fallacy (AKA Bandwagon Fallacy or Ad Populum Fallacy) – Definition and Example

Have you ever heard the expression "jumping on the bandwagon"? It refers to someone changing their opinion or developing an opinion just because a bunch of people hold that same opinion.

There's not necessarily good evidence for that opinion, but people hold it anyway – maybe because it's been believed for a long time, or just because of the sheer number of people who believe it. But even though many people believe this thing, it may be factually incorrect or misleading.

This is a form of the appeal to popular opinion fallacy. You argue that something is true, good, or right just because a large number of people (or some popular or influential person or people) are doing it or believe it.

What's wrong with that? If everybody's doing it, it must be good – right? Well, not necessarily. People aren't always completely rational and don't always think things through. Think of the term "mob mentality". What does that conjure up? Probably a bunch of people causing chaos – in other words, not a good thing.

So before you say something like "Well everyone believes this, so it must be true", think again. Because this isn't a case of "strength in numbers" – an ad populum fallacy results from a lot of people believing incorrect or misleading information.

Example of an Appeal to Popular Opinion Fallacy

What if your young teenager comes to you and wants to get a tattoo. They argue that all their high school friends are doing it because some celebrity just got this new tattoo.

Now, whatever your feelings about tattoos, this is a logical fallacy. Just because everyone's getting this tattoo doesn't mean it's the right choice for your kid. Maybe they haven't thought it through, or maybe they can't handle serious pain/needles, or maybe they will change their mind in a few years and regret such a permanent choice.

Also, everyone has different reasons for getting tattoos. Some do it to commemorate someone or something, some do it for the beauty of the art, some do it while intoxicated on vacation, and so on. But if a group of young teenagers is getting a tattoo on a whim to copy a celebrity, perhaps that's something you want your kid to think about more carefully.

So your kid arguing that "all my friends are doing it, so it's cool" doesn't take that into account. They'd need to think about getting a tattoo for their own reasons, and justify it to you that way.

Here's another example: you're FaceTiming with your family, and it's an election year. Most of your family belongs to one political party, but you belong to another.

Your mom starts trying to convince you to vote like they do – "The whole family votes this way! And we've been voting this way forever! Come on, you should be like your family and support the same candidate/things we do."

While it's understandable that your mom would want your political beliefs to align with hers, she's making a fallacious argument here. Just because they've always voted that way doesn't make it right.

She shouldn't say you should vote like she does because "that's what the family's always done/it's what they all do now". She should point out the benefits of her candidate, how they could help you out, why their policies are fair, and so on – and then let you decide for yourself.

The Hasty Generalization Fallacy – Definition and Example

People make generalizations all the time (that, right there, was a generalization!). And sometimes this is ok. If you're just stating something that's generally true, like "I like to cook" or "Puppies are cute", there's typically no harm in that.

The problem arises, though, when someone uses a generalization a bit too zealously in an argument without sufficient evidence. These types of "hasty" generalizations can fall into stereotyping, racism, falsehood, exaggeration, and more.

Often someone makes such a generalization when they're basing their opinion or argument off of the behavior or characteristics of just a few members of a group. This often means they're not taking the behavior of the whole group into consideration.

So why are these generalizations bad? Aside from lacking evidence and being based on problematic premises, people often assert hasty generalizations as if they were 100% true all the time. Which, of course, very few likely are.

If you want to avoid making hasty generalizations, you can use certain qualifiers when you make a generalization – like "Sometimes", "Often", "We often see", or "It may be the case that...". Those types of words and phrases let your listener know that you're not arguing that this thing is true across the board for everyone. It's just a general trend you've noticed.

Example of a Hasty Generalization Fallacy

Hasty generalizations are quite common, as people use generalizations all the time in regular conversation. And again, many generalizations don't hurt anyone. But let's look at some examples of bad generalizations.

If you say "People in the southern part of the US are so conservative and close-minded. I really can't stand how all they care about is football and BBQ", you're using a hasty generalization (a couple, actually).

While it's true that some people in the south have these characteristics, it's not true for everyone living in that region. And by making those assertions, you're perpetuating stereotypes that are likely overblown and miss a lot of nuance about southern American's characters and beliefs.

Here's another example: let's say you're having a fight with your significant other and you say, "You always pick fights with me!", you're likely exaggerating and making a hasty generalization. Unless it's literally true that they are always the one to start the fight, you're probably getting carried away in the heat of the moment.

One way to save yourself from making a hasty generalization in this case would be to say something like "You pick fights with me a lot" or "You often pick fights with me."

The Tu Quoque Fallacy (AKA Appeal to Hypocrisy Fallacy) – Definition and Example

Tu quoque in Latin means "You, too". And when you attempt to distract from your own guilt by calling out someone else's similar guilt, you're committing this fallacy.

The name makes sense – it's like you're saying "Well I may have done this, but you did it, too!" Now, think about that. Just because someone else did something similar to (or the same as) what you did, it doesn't make you any less guilty. You've still committed whatever crime or done whatever bad thing you've done.

This is also called an "appeal to hypocrisy" fallacy, because the person making the argument (let's call them Person A) often calls out the fact that someone else (Person B) did something similar to what they did. Person A argues that they may have messed up, but Person B did the same thing so should be punished. Person A is being a hypocrite because they're trying to escape the blame they'd like to assign to Person B.

It's tempting to use this type of argument, because people are always looking to shift the blame from themselves to others. It's especially enticing when that other person is not blameless and therefore seems to deserve some share of the guilt.

But this isn't an effective argument strategy because, while distracting, a tu quoque argument doesn't actually prove you innocent. It just draws attention (falsely) away from the issue at hand, which is your misdeed.

One thing to remember about tu quoque fallacies is that the information the person making the argument cites is typically irrelevant to the case at hand. Just because Person B is guilty also, doesn't mean Person A is any less guilty. So that accusation that Person A makes is irrelevant to their case.

Example of a Tu Quoque Fallacy

Let's go back to our teenager. Perhaps they've been caught skipping school, and their parents want to ground them for a week. The teenager might argue, "Yeah I skipped third and fourth periods, but Marta did, too!"

While it's not great that Marta skipped class as well, it doesn't really make that teen any less guilty of skipping school. They just knew someone who did the same thing, and are trying to justify what they did by bringing up Marta's transgression as well. But it doesn't mean that they skipped any less school.

Here's another example: perhaps your friend caught you cheating on a test, and threatened to turn you into the teacher. But you saw them cheat in another class last year, so you say "I may have cheated today, but you cheated on that math test last year, too!"

Again, their cheating a year ago doesn't make you any less guilty right now. While it might feel good to say, "You did that, too, so how could you think I should be punished for it!", it's not really a strong or relevant argument to make.

Instead of resorting to this type of argument, make sure you take responsibility for your actions and keep your points relevant to the issue at hand. Don't think you can get away with something just by calling out someone else's hypocrisy. It's likely not going to help your case.

The Loaded Question Fallacy – Example and Definition

When you ask a question that intends to reinforce your position and undermine someone else's, you could be asking a loaded question. These questions are helpful to you but harmful to the person you're asking, and may skew the opinion of anyone listening in your favor, perhaps unfairly.

Instead of asking a straightforward question that attempts to get more or new information, a loaded question often includes an accusation (or a confirmation of an accusation) – an oft-quoted example is "Are you still beating your wife?"

In this question, you're referencing an accusation – that the person beat their wife – without directly accusing them of doing it currently. But by including it in the question, you're turning listeners' minds to the fact that this person did, at one point, beat their wife. So either way, they'll appear guilty.

Example of a Loaded Question Fallacy

Let's look at some more examples of loaded questions, and why they're fallacies.

Perhaps you're at a rally in support of clean energy, and a rep from Exxon is there. If you're not old enough to remember, Exxon had a horrific oil spill in Alaska in 1989 that devastated 1300 miles of coastline and released over 10 million gallons of oil into the ocean.

You might call out that rep and loudly ask them if their company is still polluting the world's pristine oceans and killing millions of sea creatures.

Whatever your feelings about Exxon or environmental justice, it's not fair to set the company up like that for those listening. Your question is heavily loaded, and doesn't give them a shot at convincing others of their current position, whatever it might be. You're making your argument by essentially biasing the crowd against them from the start.

Here's another example: what if a company hires formerly incarcerated people, and you find out that one of them was a bank robber. If you asked their employer "You're really gonna let a thief handle your products?" you're creating a negative bias against them.

It's not necessary to refer to them as a thief or allude to their past as a bank robber. By doing so, you're only creating prejudicial feelings against them that may not be relevant or meaningful at this point in time.

So just remember – when you're asking questions to try to prove your point, keep them relevant, unbiased, and focused on the issue at hand.

The Red Herring Fallacy – Definition and Example

You might wonder where the term "red herring" comes from. It's a bit of an odd name for a fallacy, don't you think?

Well, there has been some debate about this in the past but most sources agree that a red herring signifies a distraction or something meant to mislead someone.

Fun fact before we continue: there's not actually a species of herring called a red herring. A "red herring" refers to a herring that's been brined and smoked until it becomes extremely pungent and turns a bright red color.

So these red herrings were used as training aids for animals because of their strong smell (to attempt to lead them in a certain direction).

Anyway, back to our fallacy: if you make an argument with the intention of distracting from the real issue at hand, it might be a red herring. Also, if you drop some seemingly related bit of info into a conversation or debate that leads your listener down the wrong path, that's also a red herring.

Ultimately, a red herring argument distracts or leads your listener away from the crux of the issue so that they get off course or off topic.

Example of a Red Herring Fallacy

Remember, a red herring basically a diversionary tactic in an argument. It's meant to lead the listener away from the main point of the conversation.

Suppose you're arguing with someone who is in favor of a dam that's being constructed in a beautiful river. You bring up the environmental impact that said dam will have, and how devastating it'll be to the surrounding natural habitat.

Your opponent might say something like "Yes it will destroy the habitat for many fish and other river animals, but if we don't build the dam it'll take jobs away from so many people who would've worked on it."

Now, this person has just used a red herring fallacy to try to distract from the environmental impact of such a dam. Instead of arguing for the benefits of the dam itself, and arguing against the environmental impact, they're dropping in a red herring – the potential impact on the workers who would've been hired to build the dam.

While that itself is a whole separate issue, it doesn't deal with or respond to the issue at hand, which is what happens to the natural environment when the dam goes in.

How to Avoid Logical Fallacies in Your Arguments

We've just discussed a whole bunch of logical fallacies, and you might be thinking – how can I make any arguments at all without saying something fallacious?

It's not always easy, as some of these fallacies are very tempting and easy to fall into. But as long as you stick to the point, don't try to deceive your listener, cite relevant evidence from relevant sources, and avoid any derogatory or misleading language, you should be ok.

Good luck, and happy debating!

In this article, we've collected a few famous logic puzzles and their solutions. Can you solve them without peeking at the answer?

Knights and Knaves

For this logic puzzle, imagine there are two types of people, knights and knaves. Knights only tell the truth, while Knaves only tell lies.

There are many variations of this puzzle, but most involve asking a question to figure out who is the knight and who is the knave.

Red and Blue

There are two people standing in front of you, Red and Blue. Blue says, "We are both knaves." Who is really the knight and who is the knave?

Solution
It's impossible for Blue to be the knight. If Blue was a knight, the statement, "We are both knaves," would actually be a lie. Therefore, Blue is a knave as his statement is a lie, and Red must be a knight.

Two Paths

You arrive at a fork in the road and need to choose the correct path that leads to your destination. There are two people standing at the fork, and you know that one must be a knight and the other must be a knave.

What single question could you ask to one of the people to determine the correct path, A or B?

Solution
The question you can ask either person is, "What path would the other person tell me is the correct one?" The answer will always be the wrong path to take, and you can safely take the other path.

Imagine the correct path is A.

If you ask directly, "Which is the correct path?" the knave will say B is correct while the knight will say A.

However, when asked which path the other person would say is correct, the knave will lie and say that the knight would tell you path B is correct. Meanwhile, the knight will tell the truth about the knave's answer, and say that the knave will tell you that path B is the correct one.

In both cases you know that then answer, path B, is actually a lie, so you should take the other path.

The Monty Hall Problem

The Monty Hall Problem is a riddle on probability named after the host of the 70’s game show it’s based on, Let’s Make a Deal. This particular problem is a veridical paradox, which means that there is a solution that seems counter-intuitive, yet proven to be true.

Imagine you are on a game show and there are 3 doors, each with a different prize behind them. Behind one of the three doors is a car. Behind the other two doors there are goats.

You must choose one of the 3 doors to select as your prize.

Say you decide to open Door 1. The host, who knows where the car is, opens a different door, Door 2, which reveals a goat. He then asks if you would like to open Door 3 instead.

Should you choose Door 3 over your original choice? Does it even matter?

Solution
It turns out that your choice really does matter, and it is actually to your benefit to choose Door 3 instead of Door 1. Here's why.

When you chose Door 1 from the 3 closed doors, you had a 1 out of 3 chance that you picked the right one. Both Door 2 and Door 3 also have a 1 out of the 3 chance of having a car behind it.

Another way to think about it is that Doors 2 and 3 have a 2 out of 3 chance of having a car behind it combined.

But when the host opens Door 2 and reveals the goat, you suddenly have more information about the problem.

Remember that Doors 2 and 3 have a combined probability hiding the car 2/3rds of the time. When Door 2 was opened you know that there was no car behind it.

But this reveal does not change the combined probability of the two doors. That’s the key takeaway here!

Since you know that Door 2 has a 0/3 chance of hiding the car, you can now say that there's a 2/3 chance that the car is behind Door 3. Door 1 remains unchanged – there's only a 1/3 the car is behind it.

So if you decide to switch, you go from roughly a 33.33% chance to a 66.67% chance of finding the car. In other words, you are doubling your chances of success by opening Door 3 instead!

Yes, it is possible that Door 1 was hiding all along and host tricked you. That doesn’t matter. You are gambling by taking the deal, but you’re gambling smart. You should make the best decision with the information you’re given and let the dice roll.

In the long run, you'd perform better by switching than a contestant who decides to go with their first choice. Though it's not immediately obvious, the host is actually doing you a favor by offering you a better deal.

The Dining Philosophers Problem

The dining philosophers problem is a classic example in computer science to illustrate issues with synchronization. It was originally created by Edsger Dijkstra in 1965, who presented it to his students as a handful of computers competing for access to shared tape drives.

Imagine five silent philosophers sitting around a table, each with a bowl of spaghetti. There are forks on the table between each pair of adjacent philosophers.

Image courtesy of adit.io.

Each philosopher can only do one thing at a time: think and eat. However, a philosopher can only eat spaghetti when they have both the left and right forks. A fork can only be held by one philosopher at a time.

After a philosopher finishes eating, they need to put down both the left and right forks so they're available to the others. A philosopher can take a fork as soon as it's available, but can only start eating once they have both forks.

The philosophers are famous for their appetites – they can all eat endlessly and never get full. On top of that, the bowls of spaghetti magically replenish no matter how much is eaten.

The problem is, how can can you ensure that no philosopher will starve, and that they can continue eating and thinking forever?

Synchronization and Deadlock

In simple terms, the dining philosophers problem is an illustration of how synchronized access to a shared resource can result in creation of a deadlock situation.

Synchronization is used to control concurrent access to a shared resource. This is necessary in any situation where multiple independent actors may be competing for the use of one resource like the forks. Since there is only one resource available, we use synchronization to prevent confusion and chaos.

A Deadlock is a system state where no progress is possible. This situation can occur when synchronization is enforced, and many processes end up waiting for a shared resource which is being held by some other process. Like with the philosophers who are either stuck eating or thinking, the processes just keep waiting and execute no further.

Solutions

At first glance it appears like it would not be possible for a deadlock where all philosophers are stuck either eating or thinking. For example, pattern for each philosopher to follow might be:

1: think until the left fork is available; when it is, pick it up;

2: think until the right fork is available; when it is, pick it up;

3: when both forks are held, eat for a fixed amount of time;

4: then, put the right fork down;

5: then, put the left fork down;

6: repeat from the beginning.

Source: Wikipedia

There are many solutions possible to prevent deadlock. If we look closely, one problem in the algorithm above is that all philosophers have equal chance (have the same priority) of acquiring one fork. This prevents anyone from acquiring two forks and the whole system grinds to a halt.

Here are some possible solutions:

1. Priority: Some philosophers are assigned higher priority, so that the chance of acquiring both forks is increased.
2. Preemption (Politeness): Philosophers relinquish the acquired fork without eating, in case the other fork is not available.
3. Arbitration: A mediator allocates forks ensuring that two forks are given to one person, instead of one to many.

Now that you know how to solve these logic puzzles, treat yourself to an endless bowl of spaghetti. You earned it.