Maintenance and Engineering Residency
Prerequisites: core capstone plus the relevant studios. Budget: 100-160 focused hours over at least 12-16 calendar weeks. Outcome: demonstrate reliable change, recovery, user feedback, and handover across time.
Entry diagnostic
Ask another person to run your project's setup instructions in a fresh environment. Record every undocumented assumption. If you must repair their environment by hand, improve the reproducibility packet before adding features. A consenting peer, study partner, or maintainer can provide feedback; no paid deployment or employer access is required.
Keep one system alive
Select a small project with an identifiable user task and bounded operating cost. Maintain it through two releases separated by actual use or a clearly labeled simulated workload. Each release must have a reason tied to a defect, observed friction, or measured constraint. Lines of code, commits, and feature count are activity measures; they are not automatically evidence of user value.
Write a weekly decision log: what changed, why, supporting evidence, risk accepted, next observation, and work intentionally deferred. Include time spent maintaining versus adding functionality. A sound decision may be to remove a feature or avoid a service boundary.
Worked example: migration outlives deployment
Version 1 stores full_name. Version 2 introduces display_name. Dropping full_name during the first deployment can break older instances still running or a rollback to version 1.
An expand/contract approach first adds compatible storage and code that tolerates both versions. Backfill with a resumable, checked operation. Switch reads after verifying completeness and behavior. Remove the old representation only after the compatibility window has ended and rollback implications are understood.
The exact write strategy depends on concurrent edits and source-of-truth rules. “Dual write both fields” is incomplete unless failures and divergence are handled. A rollback plan for binaries does not automatically reverse a data migration.
Residency milestones
| Period | Work | Evidence and acceptance |
|---|---|---|
| Weeks 1-2 | baseline and user task | reproducible setup; observed task; prioritized defects; explicit cost/time limit |
| Weeks 3-5 | first release and review | small changes; regression evidence; reviewer comments and resolutions; release notes |
| Weeks 6-8 | migration and dependency change | compatibility test across versions; resumable migration; dependency update with recorded behavior checks |
| Weeks 9-11 | failure and recovery | inject one safe failure in your own test environment; timed detection, restore, and verification; corrected runbook |
| Weeks 12-16 | second release and handover | compare user-task outcome; second person runs or modifies the system; remaining limitations and ownership plan |
These are checkpoints, not mandatory weekly throughput targets. Extend the calendar when feedback or remediation needs more time. Separate elapsed time from focused effort.
Guided assignment and acceptance
Carry out the milestones on the same system. Include one reviewed behavior change, one maintenance change, one migration, and one recovery exercise. Observe at least one complete user task before and after a change, using comparable conditions. For a local app, useful measures include task completion, error recovery, startup latency, and lost-work incidents; monthly cloud spend is unnecessary.
Acceptance: two reproducible releases; review comments with responses; migration interruption and restart evidence; restored data checked against a known fixture; a handover attempt; and a written decision that rejects unnecessary complexity. If the project is used only by you, label that limitation rather than inventing users.
An open-source contribution is an alternative venue, not a guaranteed outcome. Prepare a focused patch, tests, and rationale; follow project contribution rules. A maintainer's delayed response or rejection is not something to manipulate for a graduation metric. External review remains pending until it actually occurs.
Transfer and defense
Your budget is cut in half while the user task stays the same. What can you simplify, retire, or change without breaking essential guarantees? Check: use measured demand and explicit priorities; do not silently remove backups or correctness checks to make a cost chart look better.
Read operational examples from The Site Reliability Workbook and compare them with your smaller system. The local notes on Escaping the Build Trap, The Manager's Path, and An Elegant Puzzle are discussion aids; distinguish notes from complete books. Finish with the residency gate and disclose self-assessed versus externally reviewed evidence.