--- title: "Software Engineering" description: "21 topics in Computing, in the order they build on each other." canonical: https://lightmysky.com/learn/computing/areas/software-engineering source: https://lightmysky.com/learn/computing/areas/software-engineering.md retrieved: 2026-09-02 --- > **Agent view.** This is the Markdown twin of the page, for tools and assistants. > When to use this site, and the call that answers each job: https://lightmysky.com/agent-instructions.md > API description (OpenAPI 3.1): https://lightmysky.com/openapi.json · Authentication: https://lightmysky.com/auth.md > Pricing: https://lightmysky.com/pricing.md · Catalog: https://lightmysky.com/llms.txt · Full catalog: https://lightmysky.com/llms-full.txt > Every machine-readable file on this domain: https://lightmysky.com/.well-known/ai-catalog.json > Ask for Markdown with `Accept: text/markdown`, a `.md` address, or `?mode=agent`. # Software Engineering 21 topics in Computing, in the order they build on each other. Page: https://lightmysky.com/learn/computing/areas/software-engineering - [Version Control as a Graph of Commits](https://lightmysky.com/learn/computing/version-control-as-a-graph-of-commits-mt_oKsDRKirMy): A repository is a graph: each commit is a snapshot that points at the one it came from, and a branch is a movable label on a node. Once the shape is clear, most version control commands stop being incantations and become moves on that graph. - [Branching, Merging and Resolving a Conflict](https://lightmysky.com/learn/computing/branching-merging-and-resolving-a-conflict-mt_l3vFbU7L3E): Two branches that changed different lines merge on their own; two that changed the same lines cannot, and a person has to decide. A rebase rewrites the history into a straight line instead, which reads better and throws away what actually happened. - [Code Review: Reading a Change You Did Not Write](https://lightmysky.com/learn/computing/code-review-reading-a-change-you-did-not-write-mt_Hhe1Ou709s): Review reads a diff and asks whether it does what was intended, whether it breaks anything nearby, and whether the next person will understand it. The skill is separating the change that has to happen from the taste that does not. - [Requirements: Turning a Wish into a Testable Statement](https://lightmysky.com/learn/computing/requirements-turning-a-wish-into-a-testable-statement-mt_TFb-YNpvT1): Someone asks for a system that is fast, or fair, or easy. A requirement rewrites that as something with a check attached, separating what the system must do from how well it must do it, and naming what is out of scope. - [Interfaces, Coupling and What a Module Promises](https://lightmysky.com/learn/computing/interfaces-coupling-and-what-a-module-promises-mt_EUZyD26WFk): A module's interface is the set of promises other code may rely on, and everything else is free to change. Coupling measures how much of a neighbour's insides a caller depends on, and it is the quantity that decides how expensive the next change will be. - [Design Patterns: Naming a Solution That Keeps Recurring](https://lightmysky.com/learn/computing/design-patterns-naming-a-solution-that-keeps-recurring-mt_bhUEk8PwBp): Some arrangements of objects appear again and again: swapping behaviour at runtime, telling listeners something happened, hiding the choice of which class to build. Naming them gives a team shared vocabulary, and the risk is reaching for a pattern where a plain function would do. - [Refactoring: Changing Structure Without Changing Behaviour](https://lightmysky.com/learn/computing/refactoring-changing-structure-without-changing-behaviour-mt_HHZufOyTg4): Refactoring is a sequence of small edits that each keep the program doing the same thing while moving it toward a shape that is easier to change. The discipline is in the size of the step and in running the tests between steps. - [Test Doubles and Testing at a Boundary](https://lightmysky.com/learn/computing/test-doubles-and-testing-at-a-boundary-mt_4ep3SiMYNM): To test code that talks to a database, a clock or a network, the test replaces that neighbour with a stand-in it controls. The choice of where to put the seam decides whether the test survives a refactoring or breaks on every change. - [Test Strategy: Unit, Integration and End to End](https://lightmysky.com/learn/computing/test-strategy-unit-integration-and-end-to-end-mt_fdAvx1MMFE): Tests trade speed against realism. Many small tests find faults fast and prove little about the assembled system; a few whole-system tests prove a lot and are slow and flaky. A strategy decides how many of each and what each level is responsible for. - [Property-Based Testing](https://lightmysky.com/learn/computing/property-based-testing-mt_QqCNKT06IY): Instead of listing examples, state a property that should hold for every input and let the machine generate inputs trying to break it. Good properties are relations that must survive, such as encoding then decoding returning the original. - [Continuous Integration and the Build Pipeline](https://lightmysky.com/learn/computing/continuous-integration-and-the-build-pipeline-mt_z__G4nfjwh): Every change is built and tested by a machine that does not have anyone's local setup, so a failure is the code's fault rather than a laptop's. The pipeline is the team's shared definition of ready, and its running time is a real constraint on how people work. - [Software Architecture: Layers, Services and Their Trade-offs](https://lightmysky.com/learn/computing/software-architecture-layers-services-and-their-trade-offs-mt_uz_OkFgysJ): Architecture is the set of decisions that are expensive to reverse: what is split from what, what talks to what, and where state lives. Splitting a system into services buys independent deployment and pays for it in network calls, partial failure and versioning. - [Technical Debt and the Cost of the Next Change](https://lightmysky.com/learn/computing/technical-debt-and-the-cost-of-the-next-change-mt_iA8-0Qg4ID): A shortcut taken today is borrowed time, and the interest is paid by everyone who touches that code afterwards. Some debt is worth taking deliberately; the failure is taking it without recording it or planning when it gets repaid. - [Working in a Team: Issues, Estimates and Iterations](https://lightmysky.com/learn/computing/working-in-a-team-issues-estimates-and-iterations-mt_HNNnVvADcF): A team splits work into pieces small enough to finish, agrees what done means for each, and looks at what actually happened before planning the next stretch. Estimates are a planning tool rather than a promise, and treating them as promises is what makes teams stop giving honest ones. - [Reading a Systems or Machine-Learning Paper](https://lightmysky.com/learn/computing/reading-a-systems-or-machine-learning-paper-mt_4LsuT0TdxT): A paper is a claim, a method and evidence, in that order of importance. Reading the evaluation before the method shows what is actually being demonstrated, and the related work shows what the authors compared against and what they left out. - [Specifying Correctness: Safety, Liveness and Invariants](https://lightmysky.com/learn/computing/specifying-correctness-safety-liveness-and-invariants-mt_4_KaoDSHZF): Before anything can be proved, the claim has to be written down. A safety property says nothing bad ever happens and is refuted by a finite trace; a liveness property says something good eventually does and is not. An invariant is the safety property a proof actually uses. - [Model Checking and the State-Space Explosion](https://lightmysky.com/learn/computing/model-checking-and-the-state-space-explosion-mt__pgZ0PzEZo): Given a finite model and a temporal property, a checker explores every reachable state or proves it need not. The states multiply with every component, so the whole craft is abstraction: shrink the model until the check finishes while the property still means what it did. - [Hoare Logic and Proving a Program Meets Its Specification](https://lightmysky.com/learn/computing/hoare-logic-and-proving-a-program-meets-its-specification-mt_bJZnbBrUIP): A triple states what holds before a fragment runs and what holds after. Rules compose triples along the structure of the program, loops need an invariant that a person supplies, and the leftover verification conditions are what a solver is handed. - [Reproducibility: Seeds, Environments and the Ablation](https://lightmysky.com/learn/computing/reproducibility-seeds-environments-and-the-ablation-mt_Rp__eJ-vjn): A result that cannot be rerun is a claim, not a finding. Fixing seeds, pinning the environment and recording the exact command make a run repeatable, and an ablation is what shows which part of a method the gain came from. - [Scoping and Writing a Thesis-Scale Project](https://lightmysky.com/learn/computing/scoping-and-writing-a-thesis-scale-project-mt_Y46uRENRVf): A year-long project fails on scope more often than on difficulty. A workable one has a question that can be answered either way, a result that stands even if the ambitious part does not land, and a written argument that survives a reader who was not there. - [Dependencies, Licences and the Supply Chain](https://lightmysky.com/learn/computing/dependencies-licences-and-the-supply-chain-mt_2kilqPb0aV): Most of a shipped program was written by strangers. Pulling in a library brings its bugs, its updates and its licence terms, so a team has to know what it depends on, what those terms allow, and what happens when a dependency stops being maintained.