Software Engineering Practices

1. Branches, commits and pull requests

Version control is not a backup mechanism you invoke occasionally — it is the shared memory of a team: a record of what changed, when, by whom and *why*, that lets people work in parallel without destroying each other's work. This lesson covers the object model underneath Git, how to write commits that review well, branching and merge strategies, pull requests as a review unit, conflict resolution as a routine rather than an emergency, and the hygiene habits that keep history useful six months later. The repository's log is the project's primary documentation of its own evolution — treat it that way.

2. Code review that helps

Code review is the highest-leverage ritual in software: it spreads knowledge, catches design problems no test would, and sets the standard a codebase is held to — or it is a theatre of nitpicks that everybody learns to resent. This lesson covers what review is actually for, how to submit something reviewable, how to review with a checklist ordered by severity, how to comment so people improve instead of bristle, the limits of review (and what to do instead), and the metrics that tell you whether yours is working. The goal is not approval; it is shared ownership of code that lasts.

3. Naming and structure that survives

Code is read far more often than it is written — by other people, by future teams, and by you in six months with none of today's context. This lesson covers naming (what to name, what never to name, the rules that make a name true), function and module design, the smells that signal structure gone wrong, comments and documentation written for the reader who disagrees, formatting as a solved problem, and the refactoring discipline that lets structure improve while the tests keep passing. Readability is not decoration; it is the maintenance cost of the entire codebase, written down.

1. Tests that earn their keep

A test suite is only worth what it prevents: tests that catch real regressions, run fast, and stay trustworthy are the cheapest insurance in software; tests that are flaky, tautological or ceremonial cost more than they save. This lesson covers what to test (the behaviour, not the implementation), naming and structuring tests so failures explain themselves, boundaries and edge cases as first-class targets, test doubles and when they lie, fixture design, coverage as a floor rather than a goal, and the debugging loop a good suite makes possible. The goal is not a number — it is confidence that changes are safe.

2. A pipeline on every push

Continuous integration is a practice before it is a tool: every change is integrated with the main branch frequently, and every integration is verified by an automated pipeline that everyone trusts. This lesson covers the pipeline's stages and what belongs in each, the feedback loop as the unit that makes or breaks CI, caching and speed, handling failures without training people to ignore them, environments and secrets, and the deployment stages that extend the same idea to shipping. A green pipeline is the team's shared belief that today's change did not break yesterday's — and that belief is only worth what the pipeline honestly checks.

3. Issues, scope and shipping small

Most projects fail in planning, not programming: work arrives too vague to start, too large to finish, or too entangled to ship. This lesson covers writing issues that can be picked up cold, slicing features vertically into deliverable increments, estimating and prioritising with honesty about uncertainty, tracking work so it reduces confusion instead of creating ceremony, and the rituals that keep a team aligned without drowning in meetings. Shipping small is not timidity — it is the only proven way to make progress visible and risk bounded.