Debugging as Computational Reasoning: How Errors Become Evidence

Last Updated June 17, 2026

Debugging is often treated as the practical work of finding and fixing errors in code. But debugging is also a form of computational reasoning. It requires a person to compare expected behavior with observed behavior, form hypotheses, inspect evidence, isolate causes, test explanations, revise assumptions, and confirm that a change actually improves the system.

A bug is not merely a broken line of code. It may be a mismatch between problem and representation, pseudocode and implementation, input and assumption, state and transition, model and reality, output and interpretation, test and requirement, or system behavior and user expectation. Debugging therefore belongs at the center of algorithmic thinking. It teaches that computational systems are reasoned through, not merely written.

Debugging also reveals how algorithms fail. A procedure can be logically incomplete, implemented incorrectly, tested weakly, applied outside its scope, fed invalid data, allowed to enter an impossible state, stopped too early, run too long, or interpreted beyond what its output supports. Debugging makes these failures visible. It turns error into evidence.

This article explains debugging as a disciplined reasoning process. It examines bugs as mismatches between intent and behavior, shows how errors can arise from inputs, outputs, states, control flow, data structures, assumptions, dependencies, concurrency, and interpretation, and describes a practical method for diagnosing failures. It also connects debugging to testing, reproducibility, observability, verification, documentation, model governance, and responsible computational practice.

Why Debugging Matters

Debugging matters because programs rarely fail only at the surface. An error message may point to one line, but the cause may be elsewhere: an invalid assumption, a missing input check, a misunderstood type, a poorly specified edge case, a dependency mismatch, a hidden state transition, a race condition, a stale data source, or an output used beyond its intended meaning.

In computational reasoning, debugging is a way of learning what a system actually does. It exposes the difference between what a person thought they built and how the system behaves under real conditions. This is why debugging can be frustrating, but also intellectually powerful. It forces specificity.

Debugging turns vague failure into structured inquiry. It teaches that errors are not interruptions to computational reasoning; they are part of it.

Back to top ↑

What Is Debugging?

Debugging is the process of identifying, explaining, correcting, and verifying failures in computational systems. A failure may appear as a crash, wrong answer, slow program, missing output, misleading visualization, unstable model, inconsistent result, security weakness, memory leak, data corruption, or user-facing confusion.

Debugging can happen at many levels:

• syntax errors, where code cannot be parsed or compiled;
• runtime errors, where a program fails during execution;
• logic errors, where a program runs but produces the wrong behavior;
• data errors, where inputs are missing, invalid, duplicated, biased, stale, or misformatted;
• state errors, where a system remembers, updates, or transitions incorrectly;
• interface errors, where components disagree about contracts;
• performance errors, where computation is too slow, costly, or resource-heavy;
• interpretation errors, where outputs are technically produced but misunderstood.

Debugging begins when something does not match a specification, expectation, or responsible use condition. The first task is to define that mismatch clearly.

Back to top ↑

Bugs as Mismatches Between Intent and Behavior

A bug can be understood as a mismatch between intended behavior and observed behavior. Sometimes the intended behavior is written in a formal specification. Sometimes it is expressed in pseudocode, tests, documentation, user expectations, domain rules, or institutional requirements. Sometimes it exists only as an assumption that must be made explicit during debugging.

This framing helps because it avoids reducing bugs to “mistakes in code.” A mismatch can arise from either side. The program may be wrong. The expectation may be wrong. The test may be incomplete. The input may be outside scope. The output may be interpreted incorrectly. The documentation may be ambiguous.

Debugging therefore requires asking what “correct” means. Without an expected behavior, there is no meaningful bug, only surprise.

Back to top ↑

Debugging as Hypothesis Testing

Debugging resembles hypothesis testing. A developer observes a failure, forms a possible explanation, designs a test or inspection to check that explanation, and revises the hypothesis based on evidence. The process is iterative.

A disciplined debugging loop looks like this:

OBSERVE failure
DEFINE expected behavior
REPRODUCE the problem
FORM hypothesis
INSPECT relevant evidence
TEST hypothesis with smallest useful case
FIX the cause
VERIFY the fix
ADD regression test
DOCUMENT the lesson

This loop matters because undisciplined debugging often becomes guessing. Guessing may work for small problems, but it does not scale to large software systems, data pipelines, simulations, machine-learning workflows, databases, or institutional automation.

The strongest debugging practice treats every fix as a claim that must be verified.

Back to top ↑

Inputs, States, and Traces

Debugging often depends on reconstructing the path from input to output. A trace records what happened during execution: what inputs entered, what branches were taken, what state changed, what functions were called, what values were computed, and where behavior diverged from expectation.

Inputs are especially important because many bugs only appear under particular conditions. A program may work for ordinary input and fail for empty input, missing values, duplicates, large inputs, unusual encodings, negative values, floating-point extremes, time-zone changes, or records from a different context.

State is equally important. Many bugs occur because a system updates, remembers, or forgets incorrectly. The code may appear correct when inspected locally, but the sequence of states reveals the problem.

A trace is a reasoning artifact. It turns execution into evidence.

Back to top ↑

Edge Cases and Failure Modes

Many bugs live at the edges of a problem. Edge cases are not rare distractions; they are where assumptions become visible. Empty input, one-item input, duplicate values, tied scores, missing records, negative numbers, extreme values, invalid encodings, circular dependencies, and no-solution cases all test whether a procedure has been specified completely.

Failure modes describe how a system can go wrong. A good debugging practice identifies failure modes before they appear in production. A good test suite preserves them as examples.

Edge cases help convert vague confidence into tested confidence. A system that only works for ideal cases is not yet well understood.

Back to top ↑

Testing, Observability, and Reproducibility

Testing, observability, and reproducibility are debugging supports. Testing checks whether behavior matches expectations. Observability makes internal system behavior visible through logs, traces, metrics, assertions, and reports. Reproducibility makes a failure repeatable so that a cause can be isolated and a fix can be verified.

Without reproducibility, debugging becomes memory and guesswork. Without observability, debugging becomes searching in the dark. Without tests, debugging has no stable way to prevent the same failure from returning.

Good debugging practice leaves evidence behind. It improves not only the current program, but the future ability to reason about the system.

Back to top ↑

Debugging Data, Models, and Systems

Debugging is not limited to traditional programming. Data pipelines, simulations, machine-learning systems, databases, dashboards, and institutional workflows all require debugging. In these contexts, the problem may not be a syntax error. It may be a data transformation, model assumption, parameter setting, aggregation choice, schema mismatch, stale dependency, hidden feedback loop, or visualization issue.

A machine-learning model may perform well on one dataset and poorly after deployment. A simulation may behave strangely because initial conditions were misunderstood. A dashboard may mislead because aggregation hides variation. A database workflow may fail because a schema changed. A public decision-support tool may produce inconsistent results because review states are not represented correctly.

Debugging these systems requires asking not only “why did the code fail?” but also “why did this representation, model, workflow, or institution produce this behavior?”

Back to top ↑

Debugging and Human Judgment

Debugging depends on human judgment because not all failures are technical in the narrow sense. A program can satisfy its tests and still be wrong for its purpose. A model can optimize a metric and still be inappropriate for a decision. A dashboard can compute correctly and still mislead. A workflow can automate consistently and still treat important exceptions poorly.

Human judgment enters when selecting what counts as expected behavior, which bugs matter most, what risks require immediate correction, which failures need escalation, and how to balance correctness, safety, performance, maintainability, interpretability, and fairness.

Debugging is therefore both technical and interpretive. It asks what happened, why it happened, what it means, and what should be changed.

Back to top ↑

Back to top ↑

Mathematics, Computation, and Modeling

Debugging can be represented as a relationship between expected behavior, observed behavior, hypotheses, evidence, and interventions.

A debugging hypothesis can be treated as an explanation for a mismatch:

Debugging quality can be evaluated by the strength of reproduction, isolation, evidence, correction, and verification:

A fix should reduce the mismatch while preserving other expected behavior:

This formal framing helps explain why debugging is not random trial and error. It is evidence-guided refinement.

Back to top ↑

Python Workflow: Debugging Reasoning Audit

The Python workflow below creates a simple synthetic audit for debugging cases. It scores reproducibility, expected-behavior clarity, trace quality, hypothesis strength, isolation quality, edge-case awareness, fix verification, regression testing, documentation, and governance readiness.

# debugging_reasoning_audit.py
# Dependency-light workflow for evaluating debugging as computational reasoning.

from __future__ import annotations

from dataclasses import asdict, dataclass
from pathlib import Path
import csv
import json
from statistics import mean

ARTICLE_ROOT = Path(__file__).resolve().parents[1]
TABLES = ARTICLE_ROOT / "outputs" / "tables"
JSON_DIR = ARTICLE_ROOT / "outputs" / "json"


@dataclass(frozen=True)
class DebugCase:
    case_name: str
    system_context: str
    failure_description: str
    expected_behavior: str
    observed_behavior: str
    reproducibility: float
    expected_behavior_clarity: float
    trace_quality: float
    hypothesis_strength: float
    isolation_quality: float
    edge_case_awareness: float
    fix_verification: float
    regression_testing: float
    documentation_quality: float
    governance_readiness: float


def clamp(value: float, low: float = 0.0, high: float = 100.0) -> float:
    return max(low, min(high, value))


def debugging_quality(case: DebugCase) -> float:
    return clamp(
        100.0 * (
            0.12 * case.reproducibility
            + 0.10 * case.expected_behavior_clarity
            + 0.10 * case.trace_quality
            + 0.10 * case.hypothesis_strength
            + 0.10 * case.isolation_quality
            + 0.10 * case.edge_case_awareness
            + 0.12 * case.fix_verification
            + 0.10 * case.regression_testing
            + 0.08 * case.documentation_quality
            + 0.08 * case.governance_readiness
        )
    )


def recurrence_risk(case: DebugCase) -> float:
    weak_points = [
        1.0 - case.reproducibility,
        1.0 - case.expected_behavior_clarity,
        1.0 - case.trace_quality,
        1.0 - case.isolation_quality,
        1.0 - case.edge_case_awareness,
        1.0 - case.fix_verification,
        1.0 - case.regression_testing,
        1.0 - case.documentation_quality,
    ]
    return clamp(100.0 * mean(weak_points))


def diagnose(quality: float, risk: float) -> str:
    if quality >= 80 and risk <= 25:
        return "strong debugging process with evidence, verification, and regression coverage"
    if quality >= 65 and risk <= 40:
        return "usable debugging process with review needs"
    if risk >= 55:
        return "high recurrence risk; failure may return or remain poorly understood"
    return "partial debugging process; improve reproduction, tracing, verification, or documentation"


def build_cases() -> list[DebugCase]:
    return [
        DebugCase(
            case_name="Graph traversal infinite loop",
            system_context="Recursive graph search with cycles.",
            failure_description="Search fails to terminate on cyclic graphs.",
            expected_behavior="Return a path when target exists or no-solution status when exhausted.",
            observed_behavior="Procedure repeatedly revisits nodes and does not halt.",
            reproducibility=0.88,
            expected_behavior_clarity=0.84,
            trace_quality=0.78,
            hypothesis_strength=0.82,
            isolation_quality=0.80,
            edge_case_awareness=0.76,
            fix_verification=0.82,
            regression_testing=0.78,
            documentation_quality=0.70,
            governance_readiness=0.62,
        ),
        DebugCase(
            case_name="Data pipeline missing-value bug",
            system_context="Synthetic data-cleaning workflow.",
            failure_description="Valid zero values are treated as missing.",
            expected_behavior="Missing values should be flagged while valid zeros remain valid.",
            observed_behavior="Records with zero values are removed from the dataset.",
            reproducibility=0.84,
            expected_behavior_clarity=0.78,
            trace_quality=0.74,
            hypothesis_strength=0.76,
            isolation_quality=0.72,
            edge_case_awareness=0.80,
            fix_verification=0.76,
            regression_testing=0.74,
            documentation_quality=0.68,
            governance_readiness=0.70,
        ),
        DebugCase(
            case_name="Simulation instability",
            system_context="Discrete-time numerical simulation.",
            failure_description="State values oscillate unrealistically.",
            expected_behavior="State trajectory should remain within plausible range under documented parameters.",
            observed_behavior="Large time step causes unstable updates.",
            reproducibility=0.80,
            expected_behavior_clarity=0.72,
            trace_quality=0.78,
            hypothesis_strength=0.74,
            isolation_quality=0.70,
            edge_case_awareness=0.72,
            fix_verification=0.74,
            regression_testing=0.66,
            documentation_quality=0.64,
            governance_readiness=0.68,
        ),
        DebugCase(
            case_name="Recommendation ranking tie bug",
            system_context="Ranking system with scored candidates.",
            failure_description="Tied candidates appear in unstable order.",
            expected_behavior="Ties should be resolved by documented secondary criteria.",
            observed_behavior="Rank order changes between runs.",
            reproducibility=0.76,
            expected_behavior_clarity=0.70,
            trace_quality=0.68,
            hypothesis_strength=0.72,
            isolation_quality=0.70,
            edge_case_awareness=0.74,
            fix_verification=0.72,
            regression_testing=0.70,
            documentation_quality=0.62,
            governance_readiness=0.58,
        ),
    ]


def run_audit() -> list[dict[str, object]]:
    rows: list[dict[str, object]] = []
    for case in build_cases():
        quality = debugging_quality(case)
        risk = recurrence_risk(case)
        rows.append({
            **asdict(case),
            "debugging_quality": round(quality, 3),
            "recurrence_risk": round(risk, 3),
            "diagnostic": diagnose(quality, risk),
        })
    return rows


def write_csv(path: Path, rows: list[dict[str, object]]) -> None:
    path.parent.mkdir(parents=True, exist_ok=True)
    with path.open("w", newline="", encoding="utf-8") as handle:
        writer = csv.DictWriter(handle, fieldnames=list(rows[0].keys()))
        writer.writeheader()
        writer.writerows(rows)


def write_json(path: Path, payload: object) -> None:
    path.parent.mkdir(parents=True, exist_ok=True)
    path.write_text(json.dumps(payload, indent=2, sort_keys=True), encoding="utf-8")


def summarize(rows: list[dict[str, object]]) -> dict[str, object]:
    return {
        "case_count": len(rows),
        "average_debugging_quality": round(mean(float(row["debugging_quality"]) for row in rows), 3),
        "average_recurrence_risk": round(mean(float(row["recurrence_risk"]) for row in rows), 3),
        "highest_quality_case": max(rows, key=lambda row: float(row["debugging_quality"]))["case_name"],
        "highest_risk_case": max(rows, key=lambda row: float(row["recurrence_risk"]))["case_name"],
        "interpretation": "Debugging quality depends on reproduction, expected-behavior clarity, traces, hypotheses, isolation, edge cases, fix verification, regression tests, documentation, and governance."
    }


def main() -> None:
    rows = run_audit()
    summary = summarize(rows)

    write_csv(TABLES / "debugging_reasoning_audit.csv", rows)
    write_csv(TABLES / "debugging_reasoning_audit_summary.csv", [summary])
    write_json(JSON_DIR / "debugging_reasoning_audit.json", rows)
    write_json(JSON_DIR / "debugging_reasoning_audit_summary.json", summary)

    print("Debugging reasoning audit complete.")
    print(TABLES / "debugging_reasoning_audit.csv")


if __name__ == "__main__":
    main()

This workflow treats debugging as a reviewable reasoning process rather than an informal repair habit. It asks whether the failure was reproduced, traced, explained, fixed, verified, tested, and documented.

Back to top ↑

R Workflow: Failure Pattern Summary and Visualization

The R workflow reads the Python-generated audit table and creates summary outputs and visualizations using base R. It compares debugging quality and recurrence risk across synthetic cases.

# debugging_reasoning_summary.R
# Base R workflow for summarizing debugging quality and recurrence risk.

args <- commandArgs(trailingOnly = FALSE)
file_arg <- grep("^--file=", args, value = TRUE)

if (length(file_arg) > 0) {
  script_path <- normalizePath(sub("^--file=", "", file_arg[1]), mustWork = TRUE)
  article_root <- normalizePath(file.path(dirname(script_path), ".."), mustWork = TRUE)
} else {
  article_root <- getwd()
}

setwd(article_root)

tables_dir <- file.path(article_root, "outputs", "tables")
figures_dir <- file.path(article_root, "outputs", "figures")

if (!dir.exists(tables_dir)) {
  dir.create(tables_dir, recursive = TRUE)
}

if (!dir.exists(figures_dir)) {
  dir.create(figures_dir, recursive = TRUE)
}

input_path <- file.path(tables_dir, "debugging_reasoning_audit.csv")

if (!file.exists(input_path)) {
  stop(paste("Missing", input_path, "Run the Python workflow first."))
}

data <- read.csv(input_path, stringsAsFactors = FALSE)

summary_table <- data.frame(
  case_count = nrow(data),
  average_debugging_quality = mean(data$debugging_quality),
  average_recurrence_risk = mean(data$recurrence_risk),
  highest_quality_case = data$case_name[which.max(data$debugging_quality)],
  highest_risk_case = data$case_name[which.max(data$recurrence_risk)]
)

write.csv(
  summary_table,
  file.path(tables_dir, "r_debugging_reasoning_summary.csv"),
  row.names = FALSE
)

comparison_matrix <- rbind(
  data$debugging_quality,
  data$recurrence_risk
)

colnames(comparison_matrix) <- data$case_name
rownames(comparison_matrix) <- c("Debugging quality", "Recurrence risk")

png(
  file.path(figures_dir, "debugging_quality_vs_recurrence_risk.png"),
  width = 1400,
  height = 800
)

barplot(
  comparison_matrix,
  beside = TRUE,
  las = 2,
  ylim = c(0, 100),
  ylab = "Score",
  main = "Debugging Quality vs. Recurrence Risk"
)

legend(
  "topleft",
  legend = rownames(comparison_matrix),
  pch = 15,
  bty = "n"
)

grid()
dev.off()

png(
  file.path(figures_dir, "debugging_reasoning_dimensions.png"),
  width = 1400,
  height = 800
)

dimension_means <- colMeans(data[, c(
  "reproducibility",
  "expected_behavior_clarity",
  "trace_quality",
  "hypothesis_strength",
  "isolation_quality",
  "edge_case_awareness",
  "fix_verification",
  "regression_testing",
  "documentation_quality",
  "governance_readiness"
)]) * 100

barplot(
  dimension_means,
  las = 2,
  ylim = c(0, 100),
  ylab = "Average score",
  main = "Average Debugging Reasoning Quality by Dimension"
)

grid()
dev.off()

print(summary_table)

This workflow supports debugging review by showing whether a failure was diagnosed with enough evidence to reduce recurrence risk.

Back to top ↑

GitHub Repository

The companion repository for this article will provide reproducible code, synthetic datasets, workflow documentation, generated outputs, and debugging-reasoning diagnostics that extend the article into executable examples.

articles/debugging-as-computational-reasoning/
├── python/
│   ├── debugging_reasoning_audit.py
│   ├── failure_trace_examples.py
│   ├── hypothesis_testing_debugger.py
│   ├── edge_case_regression_examples.py
│   ├── observability_and_logging_examples.py
│   ├── calculators/
│   │   ├── debugging_quality_calculator.py
│   │   └── recurrence_risk_calculator.py
│   └── tests/
├── r/
│   ├── debugging_reasoning_summary.R
│   ├── failure_pattern_visualization.R
│   └── recurrence_risk_report.R
├── julia/
│   ├── debugging_trace_simulation.jl
│   └── numerical_failure_examples.jl
├── sql/
│   ├── schema_debugging_cases.sql
│   ├── schema_failure_traces.sql
│   └── debugging_queries.sql
├── haskell/
│   ├── DebugTypes.hs
│   ├── FailureReasoning.hs
│   └── Main.hs
├── rust/
│   └── src/
├── go/
│   └── main.go
├── c/
│   └── debugging_reasoning_audit.c
├── cpp/
│   └── debugging_reasoning_audit.cpp
├── fortran/
│   └── debugging_quality_model.f90
├── java/
│   └── src/main/java/org/contentcatalyst/algorithms/
├── typescript/
│   └── src/
├── prolog/
│   └── debugging_rules.pl
├── racket/
│   └── debugging_interpreter.rkt
├── docs/
│   ├── methodology.md
│   ├── article-notes.md
│   ├── debugging-as-computational-reasoning.md
│   ├── governance-notes.md
│   └── responsible-use.md
├── data/
│   └── synthetic_debugging_reasoning_cases.csv
├── outputs/
│   ├── tables/
│   ├── figures/
│   ├── json/
│   ├── logs/
│   └── reports/
├── notebooks/
│   └── debugging_as_computational_reasoning_walkthrough.ipynb
├── canvas/
│   ├── canvas_manifest.json
│   ├── canvas_cards.json
│   └── canvas_index.md
└── shared/
    ├── schemas/
    ├── templates/
    ├── taxonomies/
    ├── benchmarks/
    └── governance/

Back to top ↑

A Practical Method for Debugging as Reasoning

A practical debugging method begins by refusing to guess too quickly. The goal is to turn failure into evidence, evidence into explanation, explanation into correction, and correction into verified improvement.

This method is not limited to software engineering. It applies to data workflows, simulations, dashboards, public decision systems, machine-learning pipelines, and knowledge systems.

Back to top ↑

Common Pitfalls

A common debugging pitfall is changing code before understanding the failure. This may hide the symptom without correcting the cause. It can also introduce new bugs. Another pitfall is trusting the first hypothesis too strongly. A plausible explanation is not evidence.

A third pitfall is failing to preserve the bug as a test. When a bug is fixed but not turned into a regression test, the system loses institutional memory. The same failure can return later under a different name.

Common pitfalls include:

• guessing before reproducing: changing code without a repeatable failure;
• fixing symptoms: suppressing an error message without correcting the underlying cause;
• ignoring inputs: debugging code while overlooking malformed, missing, stale, or out-of-scope data;
• ignoring state: focusing on one line while missing the sequence of state transitions;
• weak edge-case testing: checking only ordinary examples after a fix;
• silent failure handling: replacing errors with defaults that look valid;
• no regression test: fixing a bug without preserving it as a future check;
• overfitting the fix: making a patch that only works for one example;
• poor documentation: leaving the reason for the failure undocumented;
• blame-centered debugging: treating bugs as personal failure rather than system evidence.

Better debugging treats errors as information. The goal is not only to make the current error disappear. The goal is to understand the system better.

Back to top ↑

Why Debugging Is Computational Reasoning

Debugging is computational reasoning because it asks how a formal procedure behaves under real conditions. It compares expectation with observation, traces execution, tests hypotheses, isolates causes, revises assumptions, verifies fixes, and preserves lessons through tests and documentation.

This makes debugging one of the most important habits in algorithmic thinking. It teaches that programs are not simply written and then trusted. They are inspected, questioned, tested, revised, and governed. Debugging reveals hidden assumptions, weak specifications, unhandled edge cases, invalid states, misleading outputs, and fragile interfaces.

A mature computational practice does not treat bugs as embarrassments to hide. It treats them as evidence. Debugging turns failure into understanding, and understanding into better systems.

Back to top ↑

Related Articles

• What Is Algorithms & Computational Reasoning?
• Algorithmic Thinking vs. Computational Reasoning
• Problems, Procedures, and Formalization
• Decomposition and Stepwise Reasoning
• Abstraction in Computational Reasoning
• Inputs, Outputs, States, and Stopping Conditions
• Algorithmic Literacy for the Modern World
• From Pseudocode to Programs

Further Reading

• Agans, D.J. (2002) Debugging: The 9 Indispensable Rules for Finding Even the Most Elusive Software and Hardware Problems. New York: AMACOM. Publisher information available at: HarperCollins Leadership.
• Allen, E.B., Cartwright, R. and Stoler, B. (2002) ‘DrJava: A lightweight pedagogic environment for Java’, SIGCSE Bulletin, 34(1), pp. 137–141. Available at: ACM Digital Library.
• Andreas Zeller (2009) Why Programs Fail: A Guide to Systematic Debugging. 2nd edn. Burlington, MA: Morgan Kaufmann. Publisher information available at: Elsevier.
• Beck, K. (2002) Test Driven Development: By Example. Boston, MA: Addison-Wesley. Publisher information available at: Pearson.
• Brooks, F.P. Jr. (1975) The Mythical Man-Month: Essays on Software Engineering. Reading, MA: Addison-Wesley. Anniversary edition information available at: Pearson.
• Cormen, T.H., Leiserson, C.E., Rivest, R.L. and Stein, C. (2022) Introduction to Algorithms. 4th edn. Cambridge, MA: MIT Press. Available at: MIT Press.
• Dijkstra, E.W. (1972) ‘The humble programmer’, Communications of the ACM, 15(10), pp. 859–866. Available at: ACM Digital Library.
• Hailpern, B. and Santhanam, P. (2002) ‘Software debugging, testing, and verification’, IBM Systems Journal, 41(1), pp. 4–12. Available at: IEEE Xplore.
• Hunt, A. and Thomas, D. (2019) The Pragmatic Programmer: Your Journey to Mastery. 20th anniversary edn. Boston, MA: Addison-Wesley. Publisher information available at: Pearson.
• Lamport, L. (2002) Specifying Systems: The TLA+ Language and Tools for Hardware and Software Engineers. Boston, MA: Addison-Wesley. Available at: Leslie Lamport’s TLA+ page.
• McConnell, S. (2004) Code Complete: A Practical Handbook of Software Construction. 2nd edn. Redmond, WA: Microsoft Press. Publisher information available at: Pearson.
• Myers, G.J., Sandler, C. and Badgett, T. (2011) The Art of Software Testing. 3rd edn. Hoboken, NJ: Wiley. Publisher information available at: Wiley.
• Parnas, D.L. (1972) ‘On the criteria to be used in decomposing systems into modules’, Communications of the ACM, 15(12), pp. 1053–1058. Available at: ACM Digital Library.
• Perrow, C. (1999) Normal Accidents: Living with High-Risk Technologies. Princeton, NJ: Princeton University Press. Available at: Princeton University Press.
• Sedgewick, R. and Wayne, K. (2011) Algorithms. 4th edn. Boston, MA: Addison-Wesley. Companion materials available at: Princeton University.
• Weiser, M. (1984) ‘Program slicing’, IEEE Transactions on Software Engineering, SE-10(4), pp. 352–357. Available at: IEEE Xplore.
• Wing, J.M. (2006) ‘Computational thinking’, Communications of the ACM, 49(3), pp. 33–35. Available at: ACM Digital Library.

References

• Agans, D.J. (2002) Debugging: The 9 Indispensable Rules for Finding Even the Most Elusive Software and Hardware Problems. New York: AMACOM. Publisher information available at: https://www.harpercollinsleadership.com/9780814471687/debugging/.
• Allen, E.B., Cartwright, R. and Stoler, B. (2002) ‘DrJava: A lightweight pedagogic environment for Java’, SIGCSE Bulletin, 34(1), pp. 137–141. doi: 10.1145/563517.563373.
• Beck, K. (2002) Test Driven Development: By Example. Boston, MA: Addison-Wesley. Publisher information available at: https://www.pearson.com/en-us/subject-catalog/p/test-driven-development-by-example/P200000003216.
• Brooks, F.P. Jr. (1975) The Mythical Man-Month: Essays on Software Engineering. Reading, MA: Addison-Wesley. Anniversary edition information available at: https://www.pearson.com/en-us/subject-catalog/p/mythical-man-month-the-essays-on-software-engineering-anniversary-edition/P200000003020.
• Cormen, T.H., Leiserson, C.E., Rivest, R.L. and Stein, C. (2022) Introduction to Algorithms. 4th edn. Cambridge, MA: MIT Press. Available at: https://mitpress.mit.edu/9780262046305/introduction-to-algorithms/.
• Dijkstra, E.W. (1972) ‘The humble programmer’, Communications of the ACM, 15(10), pp. 859–866. doi: 10.1145/355604.361591.
• Hailpern, B. and Santhanam, P. (2002) ‘Software debugging, testing, and verification’, IBM Systems Journal, 41(1), pp. 4–12. Available at: https://ieeexplore.ieee.org/document/5386822.
• Hunt, A. and Thomas, D. (2019) The Pragmatic Programmer: Your Journey to Mastery. 20th anniversary edn. Boston, MA: Addison-Wesley. Publisher information available at: https://www.pearson.com/en-us/subject-catalog/p/pragmatic-programmer-the-your-journey-to-mastery/P200000000483.
• Lamport, L. (2002) Specifying Systems: The TLA+ Language and Tools for Hardware and Software Engineers. Boston, MA: Addison-Wesley. Available at: https://lamport.azurewebsites.net/tla/book.html.
• McConnell, S. (2004) Code Complete: A Practical Handbook of Software Construction. 2nd edn. Redmond, WA: Microsoft Press. Publisher information available at: https://www.pearson.com/en-us/subject-catalog/p/code-complete/P200000009031.
• Myers, G.J., Sandler, C. and Badgett, T. (2011) The Art of Software Testing. 3rd edn. Hoboken, NJ: Wiley. Publisher information available at: https://www.wiley.com/en-us/The+Art+of+Software+Testing%2C+3rd+Edition-p-9781118031964.
• Parnas, D.L. (1972) ‘On the criteria to be used in decomposing systems into modules’, Communications of the ACM, 15(12), pp. 1053–1058. doi: 10.1145/361598.361623.
• Perrow, C. (1999) Normal Accidents: Living with High-Risk Technologies. Princeton, NJ: Princeton University Press. Available at: https://press.princeton.edu/books/paperback/9780691004129/normal-accidents.
• Sedgewick, R. and Wayne, K. (2011) Algorithms. 4th edn. Boston, MA: Addison-Wesley. Companion materials available at: https://algs4.cs.princeton.edu/home/.
• Weiser, M. (1984) ‘Program slicing’, IEEE Transactions on Software Engineering, SE-10(4), pp. 352–357. Available at: https://ieeexplore.ieee.org/document/5010248.
• Wing, J.M. (2006) ‘Computational thinking’, Communications of the ACM, 49(3), pp. 33–35. doi: 10.1145/1118178.1118215.
• Zeller, A. (2009) Why Programs Fail: A Guide to Systematic Debugging. 2nd edn. Burlington, MA: Morgan Kaufmann. Publisher information available at: https://www.elsevier.com/books/why-programs-fail/zeller/978-0-12-374515-6.

Back to top ↑