Start from zero: what engineering practice actually is
Engineering practice is the collection of team habits — commits, tests, CI, review, refactoring, and deploy cadence — that let you change code safely and repeatedly. This is the from-zero map and the eight words the rest of the track assumes you know.
Your app works on your laptop. You add a feature, push it, and two days later a bug report arrives: something that used to work is broken. A week after that, your teammate merges code that conflicts with yours and nobody noticed until the demo. A month in, the codebase has become a place nobody wants to touch. None of this is bad luck — it is the absence of habits. Engineering practice is the collection of habits a team builds so that changing code stays safe and fast no matter how many people are working or how long the project runs. This lesson is the map before the rest of the track.
The one problem engineering practice solves
Software that cannot be changed safely is software that is slowly dying. Every team eventually discovers this: the codebase becomes fragile, nobody dares refactor anything, and new features take three times as long as they should because every change requires a manual test tour of the entire system. Engineering practice exists to prevent that future. It is not bureaucracy — it is the minimum set of habits that keep a codebase healthy as it grows and as the team working on it changes.
When you look at a team that ships confidently — merging multiple times a day, rolling back cleanly, onboarding new engineers without fear — you are watching these habits in action, not raw talent. The habits are not invented arbitrarily. Each one exists to catch a specific class of failure before it reaches users, before it blocks a teammate, or before it makes the code harder to understand six months from now.
The eight words the rest of the track assumes
The senior units that follow drop these terms without stopping to define them. Here they are, one sentence each — what it is and why it exists.
| Word | What it is | Why it exists |
|---|---|---|
| Version control / commit | A saved snapshot of the codebase at a point in time, with a message explaining why. | So you can always go back to any past state and see who changed what and why. |
| Branch | A parallel copy of the codebase where you make changes without affecting the main copy. | So multiple people can work at the same time without overwriting each other’s work. |
| Test | Code that calls your code and checks that the result is what you expected. | So you know immediately — not six weeks later — when a change breaks something. |
| Automated test suite | A collection of tests that a computer can run without a human clicking anything. | So every change is checked consistently, not just the parts the reviewer happened to remember. |
| CI (continuous integration) | A service that automatically runs your test suite every time someone pushes a change. | So a broken change is caught before it merges, not after it reaches users. |
| Code review | A teammate reading your change and giving feedback before it merges. | So bugs and design mistakes get a second pair of eyes, and knowledge spreads across the team. |
| Refactor | Changing how code is structured without changing what it does. | So the codebase stays understandable as it grows, without breaking existing behaviour. |
| Regression | A bug where something that used to work stops working after a change. | Knowing the word lets you talk precisely about the failure mode tests and CI exist to prevent. |
| Deploy cadence | How often the team ships changes to production — daily, weekly, per-feature. | So releases are small and predictable, which makes them safer and easier to roll back. |
How they fit together
Read in order, the words tell one story: you write code on a branch and commit your progress to version control. Your automated test suite catches any regression the moment you push. CI runs those tests automatically on every push so nothing slips through. A teammate does a code review before the branch merges, catching mistakes a second pair of eyes finds easily. The change merges, and the team’s deploy cadence brings it to users in a predictable, low-risk release window. Between features you refactor freely — safe in the knowledge that the tests will tell you if you accidentally broke anything. That single paragraph is the entire track in miniature.
▸Why this works
Why not just write the code and ship it? Because without these habits, every change is a gamble. The first time you skip tests, it seems fine. The tenth time, you have a codebase nobody dares touch. The habits feel like overhead at the start — writing a test takes longer than just running the app. But the time you save on the first serious bug they catch pays for years of test-writing. Engineering practice is an investment that compounds.
What is a regression in software development?
Order the steps of a safe code change, from writing to users seeing it:
- 1 Write code on a branch and commit progress to version control
- 2 CI runs the automated test suite and catches regressions
- 3 A teammate does a code review before the branch merges
- 4 The change merges and ships in the next deploy cadence window
- 01In one breath, what problem does engineering practice solve and what is its core mechanism?
- 02What is the difference between a test, an automated test suite, and CI — and why does the distinction matter?
Engineering practice is one idea with a lot of habits hung off it: make code changes safe and repeatable for a team working together over time. The isolation half is version control — every change lives on a branch, every state is captured in a commit, and nothing is ever truly lost. The safety half is tests and CI — the automated test suite defines what the system is supposed to do, and CI runs it on every push so regressions are caught before they reach users or teammates. Code review adds a second pair of eyes and spreads knowledge. Deploy cadence keeps releases small and predictable. Refactoring keeps the codebase clean, and it is safe because the tests are watching. You do not need to hold all eight words at once — each gets its own unit ahead. Now when you see a team confidently changing a large codebase without chaos, you will recognise the habits underneath — and know exactly which one to reach for when something goes wrong.
Something unclear?
Ask a question about this lesson. Questions are anonymous and go straight to the author to make the lesson better.