Software Engineering

Reviewing someone else's proposed code change before it lands — the most reliable practice for catching bugs and spreading knowledge in teams.

The dominant distributed version control system. Tracks snapshots of a project's files and supports lightweight branching.

Writing code that runs your code to check it does what it should — the safety net that lets teams change software without breaking it.

Tracking changes to code (and other files) over time, so teams can collaborate without trampling each other's work.

An automated pipeline that builds, tests, and ships code on every change — so the path from "git push" to "in production" is short, repeatable, and safe.

A named, reusable solution to a recurring design problem in code. A shared vocabulary that lets engineers describe structure without re-explaining it.

A family of iterative software development practices emphasising short cycles, working software, and adapting to change over upfront planning.

Improving the internal structure of code without changing its external behaviour — the way you keep a codebase from rotting.

A convention for version numbers — MAJOR.MINOR.PATCH — where each part signals the kind of change (breaking, feature, fix), so the people who depend on your software can update safely.

A metaphor for the long-term cost of cutting corners — small short-term wins that compound into a heavy maintenance burden.

A small, fast test that exercises one unit (function, class, module) in isolation — the foundation of the testing pyramid.

A switch in code that turns a feature on or off at runtime without a redeploy — used to roll out gradually, test in production, and decouple deploying code from releasing it to users.

A test that exercises several components together, often hitting a real database, network, or external service — slower but higher-signal than unit tests.

A single version-control repository that holds many projects or services together — sharing tooling, dependencies, and atomic cross-project changes — instead of splitting each into its own repo.

The systematic process of finding and fixing the root cause of a software defect — using debuggers, logging, binary search, and reasoning from evidence to isolate incorrect behaviour.

A practice where the entire team works together at a single workstation on one task at a time — an extreme form of pair programming scaled to the whole team, maximising knowledge sharing and collective code ownership.

A tool that automates downloading, installing, updating, and resolving dependencies of software packages — making it practical to build on a foundation of third-party libraries without manually managing files and versions.

A software design approach centred on modelling the business domain — using a shared language between engineers and domain experts, bounded contexts to isolate models, and aggregates to enforce invariants.

Four research-backed metrics — deployment frequency, lead time for changes, change failure rate, and mean time to restore — that predict software delivery performance and organisational outcomes.

A development practice where you write a failing test before writing any production code — driving design through tests and ensuring every feature is covered, with the red-green-refactor cycle as the rhythm of work.

Mathematical techniques for specifying, developing, and verifying software and hardware systems — using logic and proof to detect design flaws and guarantee correctness properties that testing cannot exhaustively check.