What software engineering adds beyond 'writing code'

Writing a script that correctly does a task once, on your own machine, is a real and valuable skill — but it's a lower bar than what most real jobs actually need. Software engineering is the set of practices that make code survive contact with reality: other people reading and changing it, running for years instead of once, breaking in ways nobody anticipated, and needing to be understood by someone who wasn't there when it was written.

Every practice this domain covers reduces to managing one of two forces that a one-off script never has to face:

A function that produces the correct output for the cases you tried is not automatically well-engineered — it might be untested against edge cases, unreadable to anyone else, tightly coupled to code it shouldn't depend on, or built on an assumption that will quietly break the moment real-world data looks slightly different than expected. None of this shows up by just running it once and seeing the right answer — it shows up months later, when someone (possibly you) needs to change it and discovers how fragile it actually was.

Nearly every other domain in this app teaches something specific — a language's syntax, a framework's conventions, a particular tool. This domain is deliberately different: every lesson ahead applies regardless of what language or framework you're using, because they're about the process of engineering software, not about any particular technology. Reading unfamiliar code, debugging systematically, managing technical debt, and writing down why a decision was made are exactly as relevant in Python as in JavaScript, in a five-line script as in a million-line system.

This isn't a replacement for the Agile & Project Management domain (which covers team process — sprints, estimation ceremonies, stories) or the OOP & Design Patterns domain (which covers how to structure code itself). This domain sits underneath both: the individual engineering discipline — how you personally read, debug, decide, and communicate about code — that makes any process or code structure actually work in practice.