How to Teach Civilisation | Computational Literacy, Algorithms, Programming, Software and Debugging

2. Computational Thinking

Computational thinking expresses problems in forms that can be analysed systematically or automated.

Students should learn decomposition, pattern recognition, abstraction and algorithm design as transferable habits rather than as labels attached only to computer class.

3. Decomposition

Decomposition breaks a complex problem into smaller parts that can be understood and tested independently.

Students should identify interfaces among the parts so decomposition does not turn one system into disconnected fragments.

4. Pattern Recognition

Patterns reveal repeated structures that can support reuse or general rules.

Students should distinguish meaningful recurring structure from superficial similarity and should test whether a pattern survives new examples.

5. Abstraction

Abstraction removes detail that is irrelevant to the current problem while preserving what matters.

Students should understand that every abstraction hides information and should know when hidden detail must be restored.

6. Algorithms

An algorithm is a defined sequence or set of rules for solving a class of problems.

Students should write algorithms in ordinary language, diagrams and code and compare whether the same procedure works across multiple inputs.

7. Inputs

Inputs are values, events or data supplied to a computational process.

Students should state allowed input types and ranges so the system does not quietly assume ideal data.

8. Outputs

Outputs are results produced by computation.

Students should distinguish a computed output from a correct decision because interpretation and validation can still be required.

9. State

State records information a system needs to remember between actions.

Students can model counters, user sessions or game positions to see how identical inputs can produce different results when state differs.

10. Variables

Variables store values that may change during execution.

Students should name variables according to meaning and track type, scope and units where relevant.

11. Data Types

Data types define categories such as numbers, text, Boolean values or structured collections.

Students should understand that type affects valid operations and can prevent or cause errors.

12. Expressions

Expressions combine values and operators to produce new values.

Students should read expressions from inside outward and verify units or types rather than treat syntax as magical punctuation.

13. Assignment

Assignment stores a value in a variable or location.

Students should distinguish assignment from mathematical equality because a stored value can change later.

14. Sequence

Sequence executes operations in a defined order.

Students should recognise when changing order changes meaning, especially when later steps depend on earlier state.

15. Selection

Selection chooses among paths based on conditions.

Students should test both true and false branches and identify cases that fall between categories.

16. Conditions

Conditions evaluate whether specified logical statements are satisfied.

Students should make boundaries explicit so values exactly at thresholds behave intentionally.

17. Boolean Logic

Boolean logic combines true-or-false conditions with operations such as AND, OR and NOT.

Students should use truth tables and real rules to understand compound decisions without relying on intuition alone.

18. Iteration

Iteration repeats operations according to a condition or collection.

Students should identify what changes each cycle and what eventually stops the repetition.

19. Loops

Loops automate repeated work.

Students should compare counted loops, condition-based loops and iteration over collections and should test empty and single-item cases.

20. Infinite Loops

An infinite loop fails to reach a stopping condition.

Students should learn to identify missing updates or impossible exit conditions and to interrupt runaway programs safely in their learning environment.

21. Functions

Functions package reusable behaviour behind a name and interface.

Students should define inputs, output and side effects so functions can be understood without reading every internal step.

22. Parameters

Parameters allow functions or procedures to operate on different values.

Students should distinguish parameter definitions from arguments supplied during a particular call.

23. Return Values

A return value carries a result back to the caller.

Students should understand the difference between returning a value and merely printing or displaying it.

24. Scope

Scope determines where variables or names can be accessed.

Students should use local scope where practical to reduce unintended interactions between unrelated parts of a program.

25. Modularity

Modularity divides software into components with clear responsibilities.

Students should learn that modules improve understanding only when interfaces are explicit and responsibilities are not duplicated everywhere.

26. Interfaces

An interface defines how one component interacts with another.

Students should identify accepted inputs, outputs and errors so components can change internally without breaking every dependent part.

27. Libraries

Libraries provide reusable code or functionality created by others.

Students should read documentation, understand licences and avoid importing tools they cannot explain or verify at an appropriate level.

28. APIs Conceptually

An application programming interface defines how software components request data or actions from one another.

Students should see APIs as contracts between systems and should respect authentication, rate limits and data rules.

29. Data Structures

Data structures organise information for efficient use.

Students should compare lists, sets, maps and other structures according to access, ordering and uniqueness needs rather than memorise names.

30. Lists

Lists store ordered collections.

Students should practise indexing, traversal and modification while handling empty lists and boundary positions.

31. Sets

Sets represent collections without repeated members under the chosen equality rule.

Students should connect sets with membership testing and deduplication rather than use them as interchangeable lists.

32. Maps and Dictionaries

Maps associate keys with values.

Students should choose stable meaningful keys and understand what happens when a requested key is missing.

33. Stacks

Stacks use last-in-first-out ordering.

Students can connect them with undo operations, function calls and parsing while recognising that the abstraction hides implementation details.

34. Queues

Queues use first-in-first-out ordering in common forms.

Students can connect them with service systems, messaging and scheduling and compare them with priority-based queues.

35. Trees

Trees represent hierarchical relationships.

Students should explore file systems, menus or decision structures and understand parent-child relationships before advanced algorithms.

36. Graphs

Graphs represent nodes connected by edges.

Students can model roads, friendships or hyperlinks and see why network problems differ from simple linear sequences.

37. Searching

Search algorithms locate information in collections.

Students should compare simple linear search with strategies that exploit ordering and should understand the assumptions that make faster methods possible.

38. Sorting

Sorting arranges data according to a rule.

Students should compare algorithms by correctness, clarity and performance and should test duplicate and already-sorted inputs.

39. Algorithm Efficiency

Two correct algorithms can require very different time or memory as input grows.

Students should develop growth-rate intuition before formal complexity notation and should recognise when efficiency actually matters.

40. Big-O Conceptually

Big-O notation describes how resource use grows with input size under a model.

Students should treat it as a comparative abstraction rather than an exact stopwatch prediction.

41. Recursion Conceptually

Recursion solves a problem through smaller instances of the same problem.

Students should identify the base case and progress toward it so recursive definitions do not become endless self-reference.

42. Programming Languages

Programming languages provide formal syntax and semantics for expressing computation.

Students should see languages as tools with different ecosystems and trade-offs rather than rank intelligence by which syntax someone knows.

43. Syntax

Syntax defines how code must be written for a language to parse it.

Students should learn to interpret error messages and distinguish syntax mistakes from deeper logic errors.

44. Semantics

Semantics concerns what valid code means and does.

Students should be able to predict behaviour before execution instead of treating running the program as the only way to understand it.

45. Reading Code

Reading existing code is a core computing skill.

Students should trace variables, control flow and function calls and explain the program in plain language before modifying it.

46. Modifying Code

Students should make small controlled changes and predict their effects.

This builds understanding more reliably than copying a complete program and changing random lines until it appears to work.

47. Writing Code

Writing code translates an algorithm and data model into executable form.

Students should plan enough structure to preserve clarity while allowing feedback from tests to refine the implementation.

48. Comments

Comments explain intent, assumptions or non-obvious reasoning.

Students should avoid comments that merely restate obvious syntax and should update comments when code changes.

49. Naming

Good names communicate the meaning of variables, functions and components.

Students should prefer names that reveal purpose over cryptic abbreviations, especially in collaborative work.

50. Formatting

Consistent formatting helps humans read program structure.

Students should use language or team conventions and understand that readability supports debugging and maintenance.

51. Debugging

Debugging finds and corrects causes of incorrect program behaviour.

Students should reproduce the problem, isolate the relevant area, form hypotheses and test one change at a time.

52. Bugs

A bug is a defect in software behaviour or implementation.

Students should classify whether the problem comes from requirements, logic, data, interface, environment or code rather than blame programming in general.

53. Reproduction

A bug report is stronger when another person can reproduce the problem consistently.

Students should record input, steps, expected result, actual result and environment.

54. Minimal Examples

Reducing a problem to the smallest failing case removes irrelevant complexity.

Students should learn this as a general reasoning technique that helps debugging, mathematics and scientific investigation.

55. Logging

Logs record events or state useful for understanding program behaviour.

Students should log enough context to diagnose issues while avoiding unnecessary personal or sensitive information.

56. Breakpoints Conceptually

Debuggers can pause execution at selected points and inspect program state.

Students should use this to test their mental model of control flow rather than step through code without a hypothesis.

57. Assertions

Assertions express conditions expected to be true at a point in a program.

Students can use them to detect violations early and make hidden assumptions executable.

58. Testing

Testing checks whether software behaves as required under chosen cases.

Students should design tests before and after implementation and should include expected failures as well as successful paths.

59. Unit Tests

Unit tests verify small components in isolation.

Students should connect each test with a defined behaviour and avoid tests that merely mirror the implementation line by line.

60. Integration Tests

Integration tests check whether components work together.

Students should test interfaces, data formats and timing because independently correct modules can still fail when combined.

61. System Tests

System tests evaluate the complete software in realistic workflows.

Students should include user goals, external services and performance conditions appropriate to the project.

62. Regression Tests

Regression tests ensure previously working behaviour remains correct after change.

Students should add tests for important fixed bugs so the same failure is less likely to return unnoticed.

63. Test Cases

A test case specifies input, expected result and relevant setup.

Students should include normal, boundary, invalid and unusual inputs rather than test only the example used during development.

64. Boundary Cases

Boundary cases occur at limits such as zero, maximum length or exact thresholds.

Students should test just below, at and just above boundaries because many logical errors hide there.

65. Edge Cases

Edge cases are unusual but plausible situations outside the common path.

Students should prioritise them according to consequence and likelihood instead of trying to imagine every theoretical possibility.

66. Error Handling

Programs need deliberate behaviour when input, files or services fail.

Students should produce clear safe responses instead of allowing unexpected errors to crash silently or expose sensitive details.

67. Exceptions Conceptually

Exceptions represent abnormal conditions in many languages.

Students should catch only errors they can handle meaningfully and should not hide serious problems behind empty error blocks.

68. Input Validation

Programs should check whether input matches expected type, format and range.

Students should validate at boundaries between users or systems and should not assume interface restrictions make invalid input impossible.

69. Output Validation

Important computed outputs can also be checked for plausible range or consistency.

Students should connect this with measurement and risk literacy so impossible results are detected before use.

70. Version Control

Version control records code changes over time.

Students should commit coherent changes, write useful messages and understand how history supports collaboration and recovery.

71. Branches

Branches allow different lines of development to proceed without immediately changing the shared main version.

Students should understand merge and review as coordination mechanisms rather than treat branches as private copies without discipline.

72. Merges

Merging combines changes from different branches or contributors.

Students should resolve conflicts by understanding intended behaviour, not by choosing whichever text appears first.

73. Code Review

Code review lets peers inspect logic, readability, tests and risks before integration.

Students should critique the change rather than the person and should treat review as knowledge sharing as well as defect detection.

74. Documentation

Software documentation can describe installation, interfaces, architecture and usage.

Students should write for the future reader who does not share the original developer’s memory.

75. README Files

A README often provides the first explanation of what software does and how to use or develop it.

Students should include purpose, setup, important assumptions and where to find further documentation.

76. Software Architecture

Software architecture describes major components, responsibilities and relationships.

Students should understand architecture as a model that helps teams reason about change, scale and dependencies rather than as a decorative diagram.

77. Client and Server Conceptually

Many applications separate user-facing clients from remote services that provide data or computation.

Students should trace requests and responses and recognise which behaviour happens locally and which depends on a networked service.

78. Databases

Databases store organised data for reliable retrieval and update.

Students should distinguish structured records from unorganised files and understand that schema and constraints protect data quality.

79. Tables and Records

Relational databases organise data into tables with rows and columns.

Students should connect identifiers, relationships and data types with the questions the system needs to answer.

80. Queries

Queries request or transform stored data.

Students should understand filtering, selection and aggregation conceptually and should never use classroom database skills to access systems without authorisation.

81. Data Models

A data model defines entities, properties and relationships.

Students should design models around real meaning rather than copy the layout of a spreadsheet without considering consistency.

82. Data Validation

Stored data needs rules for allowed type, range and relationships.

Students should see database constraints as a way to prevent invalid states before downstream code has to repair them.

83. Files

Files persist data outside a running program.

Students should understand text, structured and binary formats conceptually and should handle paths and permissions safely in their learning environment.

84. Serialization

Serialization converts data structures into formats suitable for storage or transmission.

Students should understand that converting data does not automatically preserve every type or security property.

85. Networks

Computer networks connect devices so data and services can move between them.

Students should learn addresses, routes, protocols and reliability conceptually without operational intrusion techniques.

86. Packets

Network data is often divided into packets for transmission.

Students can model how packets carry payload plus addressing and control information and may take time to arrive.

87. Protocols

Protocols define shared rules for communication.

Students should connect protocols with the wider Civilisation idea that interoperability depends on agreed interfaces and standards.

88. IP Addresses Conceptually

IP addresses identify network interfaces for communication.

Students should understand the addressing role without using the concept to target or probe systems they do not own.

89. Domain Names

Domain names provide human-readable names that can resolve to network addresses.

Students should understand why domain verification matters for web navigation and phishing resistance.

90. DNS Conceptually

The Domain Name System helps translate domain names into network information.

Students should see DNS as shared infrastructure whose failure can make otherwise functioning services hard to reach.

91. HTTP Conceptually

HTTP defines request-response interactions used widely on the web.

Students should understand methods, status responses and headers at a conceptual level when building legitimate web applications.

92. Encryption Conceptually

Encryption transforms information so authorised parties with appropriate keys can recover it.

Students should understand confidentiality goals and key management without being taught to bypass protected systems.

93. Authentication

Authentication verifies identity or possession of credentials.

Students should distinguish authentication from authorisation and connect it with passwords, multifactor methods and account security.

94. Authorisation

Authorisation determines what an authenticated user is allowed to do.

Students should apply least-privilege thinking when designing school software and avoid granting broad permissions by default.

95. Cybersecurity

Cybersecurity protects systems, networks and data from unauthorised access, disruption or alteration.

Computational literacy should teach defensive design, updates, backups and safe coding while avoiding offensive misuse.

96. Threat Modelling Conceptually

Threat modelling asks what needs protection, from which kinds of misuse, and through which exposed surfaces.

Students should use it to design safer legitimate systems rather than to develop attack plans against real targets.

97. Secure Defaults

Systems should begin in safer states unless the user intentionally changes them.

Students should recognise the importance of minimal permissions, private-by-default data and explicit activation of risky features.

98. Updates

Software updates can fix defects, improve compatibility and close security vulnerabilities.

Students should understand why maintained software and supported dependencies matter to long-term reliability.

99. Dependencies

Programs rely on libraries, frameworks and services created by others.

Students should track dependency versions and understand that external code introduces maintenance, licence and security responsibilities.

100. Open Source

Open-source software makes source code available under defined licences.

Students should distinguish access to code from unrestricted ownership and should respect licence conditions and contributor communities.

101. Licences

Software licences define permissions and obligations for use, modification and distribution.

Students should read licence summaries and seek authoritative terms when reuse decisions matter.

102. Privacy in Software

Software can collect personal data through accounts, logs, sensors or analytics.

Students should minimise collection and connect software design with the Privacy Literacy owner rather than treating data capture as automatically harmless.

103. Data Minimisation

A system should collect only data needed for a legitimate purpose.

Students should challenge fields added because they might be useful someday and ask what harm unnecessary retention could create.

104. Logging and Privacy

Logs help diagnose software but can accidentally record sensitive information.

Students should design logs around operational need and avoid passwords, secret tokens or unnecessary personal content.

105. Backups

Backups preserve data when files are deleted, corrupted or systems fail.

Students should understand copy frequency, restore testing and independent storage locations as part of reliable computing.

106. Redundancy

Critical computing services may use multiple components or paths so one failure does not stop service.

Students should identify common dependencies so apparent redundancy is not defeated by one shared resource.

107. Availability

Availability measures whether a system is usable when needed.

Students should connect reliability, maintenance, capacity and recovery rather than assume availability is only a server property.

108. Latency

Latency is delay between initiating an action and receiving a response.

Students should understand how network distance, processing and queues can contribute and why low average latency can still hide occasional slow experiences.

109. Throughput

Computing throughput describes how much useful work or data a system processes over time.

Students should distinguish throughput from latency because a system can process high volume while individual requests remain slow.

110. Scalability

Scalability concerns how a system behaves as users, data or workload grows.

Students should test assumptions about bottlenecks rather than assume cloud infrastructure automatically scales every architecture.

111. Concurrency Conceptually

Concurrency allows multiple tasks to make progress during overlapping time.

Students should understand coordination and shared-state risks before advanced implementation.

112. Race Conditions Conceptually

A race condition occurs when outcome depends on timing among concurrent operations.

Students should learn the concept through safe simulations and understand why shared state requires deliberate coordination.

113. Automation

Automation lets software perform repeated or rule-based tasks.

Students should identify the trigger, rule, input, exception and accountable human owner before automating a process.

114. Scripts

Scripts automate sequences of operations in a computing environment.

Students should use them only on authorised files and systems and should preview destructive operations before execution.

115. Jobs and Schedulers

Computing systems can run automated tasks at specified times or conditions.

Students should understand idempotence, monitoring and failure handling so automation does not silently repeat harmful actions.

116. APIs and Automation

APIs allow legitimate software systems to exchange data or invoke functions programmatically.

Students should follow documented interfaces, authentication and usage limits and should not attempt undocumented access.

117. Computational Models

Models represent selected aspects of real systems in code.

Students should identify assumptions and validation evidence and recognise that model output is not reality itself.

118. Simulation

Simulation executes a model across time or scenarios.

Students should vary parameters and compare results with observed data before trusting predictions.

119. Randomness

Programs can use pseudo-random processes for games, simulation and sampling.

Students should understand seeds and reproducibility conceptually and distinguish pseudo-random generation from physical randomness.

120. Reproducibility

Computational work becomes more trustworthy when code, data and environment can reproduce results.

Students should record versions, parameters and transformations rather than share only the final chart.

121. Data Pipelines

Data pipelines move information through collection, cleaning, transformation and storage stages.

Students should trace provenance and validation at each step so downstream analysis can be audited.

122. ETL Conceptually

Extract-transform-load processes move and reshape data between systems.

Students should understand that transformations can change meaning and should preserve metadata and versioning.

123. Algorithms and Fairness

Algorithms can distribute opportunities or burdens according to the data and rules they use.

Students should inspect input variables, objectives and error patterns rather than assume a mathematical process is automatically neutral.

124. Algorithmic Transparency

People affected by automated decisions may need understandable information about how the system operates.

Students should distinguish transparent explanation from exposing sensitive security details.

125. Human Oversight

Automated systems still need accountable human review, especially when consequences are important.

Students should define when a person can override, pause or investigate the system rather than assume automation removes responsibility.

126. Artificial Intelligence

AI systems use data-driven or other computational methods to perform tasks such as prediction, generation or classification.

Students should connect AI with algorithms, data, evaluation and human responsibility instead of treating it as a separate magical technology.

127. Machine Learning Conceptually

Machine learning builds models whose behaviour is shaped by data and optimisation rather than only hand-written rules.

Students should understand training, validation and distribution shift conceptually before using advanced tools.

128. Training Data

Training data influence what patterns a model can learn.

Students should ask where data came from, who is represented and which errors or biases may be inherited.

129. Evaluation Data

Models need testing on data not used to fit them.

Students should understand why strong training performance does not prove reliable behaviour on new cases.

130. Overfitting

Overfitting occurs when a model matches training data too closely and generalises poorly.

Students can compare simple examples and connect the concept with memorisation versus transferable learning.

131. Metrics

Computational systems are evaluated using metrics suited to their task.

Students should identify what a metric rewards and what it ignores before declaring one model better.

132. False Positives and False Negatives

Classification errors can have different consequences.

Students should connect threshold choice with risk and avoid assuming one accuracy percentage captures every important outcome.

133. AI-Generated Code

AI tools can produce code quickly but may generate insecure, incorrect or misunderstood solutions.

Students should read, test and verify generated code and remain responsible for what they run or publish.

134. Responsible Automation

Automation should preserve human agency, privacy, safety and a route for correction.

Students should ask what happens when the automated rule is wrong and whether the affected person can understand or challenge the result.

135. Computational Creativity

Programming can create music, art, simulations, games and interactive stories.

Students should see computing as a creative medium as well as an engineering discipline.

136. Computational Science

Scientists use code to analyse data, simulate systems and reproduce results.

Scientific literacy helps students connect computational models with evidence and uncertainty.

137. Computational Mathematics

Algorithms make numerical methods, symbolic manipulation and visualisation possible.

Mathematical literacy helps students validate results and understand when numerical approximations are sufficient.

138. Computational Humanities

Text analysis, mapping and digital archives can support humanities questions.

Students should preserve context and avoid assuming quantitative patterns replace close reading or historical interpretation.

139. Computing and Business

Software coordinates transactions, logistics, customers and internal operations.

Business literacy helps students connect computational systems with organisational goals and incentives.

140. Computing and Public Services

Digital public services use identity, forms, records and workflows.

Public-service literacy helps students see why accessibility, privacy and reliability matter alongside functionality.

141. Computing and Engineering

Embedded software controls machines, vehicles and infrastructure.

Engineering literacy helps students connect code with physical safety, timing and failure modes.

142. Computing and Design

Human-centred design improves how people understand and control computational systems.

Design literacy helps students test interfaces and workflows rather than judge software only by technical correctness.

143. Team Software Projects

Software is often built collaboratively through shared repositories, issue tracking and review.

Students should practise handoffs and documentation so the project can survive changes in team membership.

144. Issue Tracking

Issue trackers record bugs, features and work items.

Students should write reproducible reports and avoid vague tickets such as app broken.

145. Technical Debt

Shortcuts can speed delivery while creating future maintenance cost.

Students should document debt and decide when to repay it rather than let temporary decisions become invisible permanent complexity.

146. Refactoring

Refactoring improves internal code structure without intentionally changing external behaviour.

Students should protect behaviour with tests so cleanup does not introduce hidden regression.

147. Maintenance

Software spends much of its life being fixed, updated and adapted.

Students should value readability, documentation and supported dependencies because launch is the beginning of a software lifecycle, not the end.

148. Deprecation

Features or interfaces can be retired gradually.

Students should communicate replacement paths and timing so dependent users or systems can migrate safely.

149. Backward Compatibility

New versions sometimes need to preserve older behaviour or formats.

Students should understand the trade-off between innovation and the cost of breaking existing users.

150. The Three-Student Computing Lab

Student A owns algorithm and data model. Student B owns implementation and tests. Student C audits usability, security and ethical impact.

Rotate roles so computation, software quality and human consequences stay connected.

151. A 60-Minute Computational Lesson

Minutes 0–8: define a process. Minutes 8–18: decompose and identify data. Minutes 18–30: write an algorithm.

Minutes 30–42: implement or simulate. Minutes 42–52: test and debug. Minutes 52–57: examine edge cases and impacts. Minutes 57–60: explain the next revision.

152. A 12-Week Progression

Weeks 1–2: decomposition and algorithms. Weeks 3–4: variables, control flow and functions. Weeks 5–6: data structures and debugging.

Weeks 7–8: software architecture, networks and databases. Weeks 9–10: security, automation and AI. Weeks 11–12: ethics, maintenance and a capstone system.

153. Assessment Should Measure Computational Reasoning

Give students an unfamiliar process with edge cases and a partially working program or pseudocode.

Score decomposition, algorithm correctness, data choices, debugging method, tests, security awareness and explanation rather than syntax speed alone.

154. Capstone: Build a Computational System File

Give each group a legitimate school or public-service problem that benefits from automation.

Students define requirements, algorithm, data model, prototype, tests, privacy safeguards, failure handling, documentation and maintenance plan.

155. Final Transfer Standard

Give students a computational problem in a language or context they have not rehearsed.

If they can decompose it, represent data, design an algorithm, read and modify code, test edge cases, debug systematically and explain security and ethical implications, computational literacy has transferred.

156. Extended Computational Diagnostic: Debug the Model, Not Just the Syntax

Give students a small program that runs without syntax errors but produces the wrong result for certain inputs. Require them to reproduce the failure, reduce it to a minimal example, trace state through the algorithm and identify whether the defect lies in data representation, boundary logic, control flow or an incorrect assumption about the problem itself. They should write a failing test before changing the code, make one targeted correction and then run both the new test and previous regression tests.

Then change the operating environment: the input becomes larger, one external service is unavailable or a field is missing. Students must decide whether the original algorithm remains suitable, whether error handling is adequate and which information should be logged without exposing personal data. This closes the loop between programming, software engineering, privacy and resilience. Computational literacy reaches the intended standard when students can explain not only what code does, but why it works, where it can fail and what evidence demonstrates that a change actually repaired the system.