What software engineering actually is
Writing code is the small part. The job is keeping a system understandable while it changes — for months, by people who aren't you.
- You can explain why "it works" is the beginning of the work, not the end.
- You can name the three forces that make software expensive, and the habit that addresses each.
Anyone can get a program to work once. You write it, you run it, it prints the right thing, and for that afternoon you are done. Then someone asks for a change, and the real work begins: you have to remember what you meant, find the line that decides the behavior, change it without breaking the other four things that depend on it, and prove you didn't.
That is the whole discipline in one sentence. Software engineering is the set of habits that makes changing code cheap. Everything else — patterns, tests, reviews, pipelines, documentation — is machinery in service of that one property.
1.1Three forces, three habits
| Force | What it feels like | Habit that answers it |
|---|---|---|
| Change | "This used to work" — every feature is a small renovation | Small commits and tests, so you can move one brick and know what fell |
| Other people | "Why is this like this?" — the author left in March | Names, READMEs, ADRs and commit messages that carry the reasoning |
| Time | The environment drifts, the dependency ages, the bug returns | Pinned versions, automation, and a regression test for every fixed bug |
Notice none of these are about typing speed or cleverness. They're about legibility: can the next person — often you in six months — see what this does, why it exists, and what would break if they changed it?
| Programming | Software engineering | |
|---|---|---|
| Success | It produces the right output today | It still does, after twenty changes and two new people |
| Audience | You, and the machine | You, the next developer, the operator, the user |
| Unit of work | A function, a script, an afternoon | A change: written, reviewed, tested, deployed, observed |
| Failure | Wrong output | Wrong output, silent data loss, an outage at 2am, a change nobody dares make |
1.2Three moments where it shows
Without habits: a customer reports wrong totals. You cannot reproduce it, the logs say nothing, and the code path is a 600-line function. You "fix" it by editing something plausible and hope.
With habits: the error log has a request ID and the exact input. A test reproduces it in four lines. You fix it in one place, add the test to the suite, deploy, and it never comes back.
THE DIFFERENCE: observability + a failing test before the fix.
Without habits: "add a discount code" turns into a week, because pricing logic is spread across checkout, invoices and a report. You change three files, break two, and miss the fourth.
With habits: pricing lives in one module with a clear entry point and tests that describe its rules. The change is one file plus a test. Review takes ten minutes.
THE DIFFERENCE: cohesive modules and tests that document intent.
Without habits: the new colleague spends a week installing things, asks which of the three ways to run the app is correct, and is afraid to commit.
With habits: a README with four commands, a failing-safe CI pipeline, and a test suite that answers "did I break it?" in ninety seconds.
THE DIFFERENCE: one command to run, one command to test.
Building only for the moment someone watches. It works beautifully in the meeting and costs a month in the maintenance. The tell: no tests, no README, and the only person who can run it is the person who wrote it. "It works" is a hypothesis; "it still works after a change" is the requirement.
Which change most reduces the cost of the next feature?
60-second recap
- Code is read and changed far more than it is written. Optimise for the reader, including future you.
- Three forces: change, other people, time. Each has a habit that answers it.
- Coupling is the real cost metric — how many places move when one thing changes.
- "It works" is a hypothesis. "It still works after the next change" is the job.