SHIFT 01 / FULL-STACK ENGINEERING
Build the smallest system that can tell the truth.
Hands-on Full-Stack sessions for engineers who want to connect runtime, data, interface and delivery through working evidence—not disconnected tutorials.
START WITH A SYSTEM
Engineering gets clearer when the parts must work together.
A session starts with one small system you can build, observe and explain. The course does not sell a tool stack as identity. It gives each tool a job inside a working boundary.
01Choose a visible system edge — something a person can run, observe and change.
02Connect one responsible path — request, decision, data and response.
03Keep a build receipt — a check another engineer can repeat.
BUILD PLANNER
Assemble a first shift, not a curriculum fantasy.
Pick a starting position, a system bay and the time you can protect. The planner returns one bounded build, proof and question.
Run one request through a visible local service.
Start a small route, log one input and return one clear response. Keep the boundary small enough to explain.
- Proof
- A repeatable request and one useful log line.
- Question
- What does this service own, and what should it refuse?
SYSTEM BAYS
Choose a part. Connect it to the rest.
Each bay holds a practical focus. Selecting one opens a full-width engineering plate with a required check rather than a vague topic list.
Make the request path observable before making it elegant.
Build a small service with one route, input boundary, response and log. Its job is to make responsibility visible.
- Set a clear input contract.
- Record one event you can inspect.
- Return an understandable failure.
A second engineer can run the request and understand the response.
SYSTEM COMPOSITION
Move the service blocks before you hide them in code.
Use a tangible system map to place responsibility, boundary and dependency in view. The point is not a beautiful diagram; it is a conversation that catches an unnecessary connection.
“Which part can change without asking three other parts for permission?”
INCIDENT DRILL
Debug the path, not the person.
Choose the condition you want to practice. The drill lays out a short response sequence, evidence to preserve and a question for the handoff.
Observe the boundary where the record disappears.
Follow one identifier from request to storage and back. Do not patch the screen before you know which boundary lost the value.
“What evidence tells us where this state was last valid?”
WORKING EVIDENCE
Show a system to someone who can ask a better question.
Build outcomes are reviewed through a short demonstration, a working check and one unresolved question. The aim is a system that can be inspected, not a theatrical demo.
Show the user path and the system boundary together.
A short demo includes the input, response and one place the system records or rejects a decision.
- Keep
- The smallest evidence another engineer can rerun.
- Avoid
- Calling a screen recording a system explanation.
BUILD RECEIPTS
Keep the checks where another engineer can find them.
Search the notes or open a receipt. These describe the engineering habits used in Shipyard Sessions.
No receipt matches that phrase. Clear the search or use a broader system term.
ENGINEERING ENQUIRY
Choose a bay. Finish one working receipt.
Share the system area, current context and the evidence you want to produce. An enquiry starts a scoping conversation; it is not a job, certification or outcome guarantee.
BAY 04 / DELIVERY
Keep a runbook beside the build.
A visible delivery path makes a working system possible to verify, repeat and recover.