The completion trap
Progress bars measure attendance, not capability. A track that reports ninety percent complete tells you nothing about whether the person can debug a failing deploy at 2am, read an unfamiliar service, or defend a schema choice to someone who disagrees.
DevCSE replaces the bar with an artefact. Every track ends in something running, with a URL, a repository and a written record of the decisions taken along the way.
What a brief contains
A brief is deliberately closer to a work ticket than to a lesson. It states the problem, the constraints, the deliverables and the criteria the work will be reviewed against.
- Problem statement written from the user's side, not the implementer's.
- Hard constraints: stack, data volume, latency budget, threat model.
- Deliverables: running system, repository, decision log, short write-up.
- Review criteria published before the work starts, never after.
Why deployment matters
Local correctness is cheap. The interesting failures — cold starts, connection limits, clock skew, retries that amplify load — only appear once something is exposed to a network and to real inputs.
Deploying early and repeatedly turns those failures into ordinary, survivable events instead of a final-week catastrophe.
Review as the closing loop
Work that no one reads teaches only the person who wrote it, and teaches them incompletely. Quarterly build reviews put a rotating panel in front of each finished project: architecture, trade-offs, failure modes.
The notes are published with the project so the reasoning stays available to whoever picks up the same problem next.