Mostly harmless, conspicuously useful

The Hitchhiker's Guide to Becoming a Full-Stack Engineer

A full-stack engineer builds both ends of the system and the gap between them, which is a perfectly reasonable arrangement until the deploy breaks one end and fixes the other, and the customer is left holding the gap. You translate "ship the feature" into markup, styles, scripts, services, databases, contracts, pipelines, and the quiet assumption that the frontend and backend agree on what a customer is, a position they hold only between meetings and never during them. You learn that an API is a promise the frontend believes today and the backend will litigate tomorrow, that a database will preserve a typo for twenty years with the diligence of an archivist, and that a deploy that fixed the form and broke the API is two features and one urgent conversation. The work travels from one function that returns the right answer to a whole application that returns an answer that is eventually, approximately, and defensibly correct across a browser, a server, and a database that hold different opinions about what just happened. This guide moves from writing one screen and one endpoint to setting application architecture across teams, with practical stops at contracts, data, partial failure, testing, security, delivery, and the recurring discovery that the bug was always in the seam; it was merely waiting for a deploy to make it official. The grand objective is a working feature across the stack at a defensible cost; the daily evidence is usually a deploy that does not require a rollback on either end, a migration that does not require a meeting, and a transaction whose commit survived a colleague's enthusiasm for "just one more column on the form."

Level 1 · Novice

Read the form before trusting the endpoint to remember what a customer is

You inspect screens, handlers, schemas, and queries without shipping to production, learning how a polite form can persist a customer into the wrong table before the submit button finishes agreeing with itself.

You begin with read-only artifacts: a page's markup, a request handler, a database schema, sample queries, and a recent log. Frontend development builds the accessible browser interface the user sees and operates; backend development builds the server-side logic and data access the interface calls. A request handler is the function the backend offers the frontend; a form is the function the frontend offers the user, and the gap between them is the contract the team forgot to write down. You review these with developers, a database-aware reviewer, and an experienced engineer so everyone can trace how a screen becomes a row before anyone ships a feature whose correction will outlast their employment.

Suppose a team wants to add a "save profile" feature. In a sandbox with no production access, you read the form, follow the submit into the handler, inspect the schema's nullability and unique constraints, and note that the form sends an email the database has no uniqueness constraint for but the product assumes it does. You record the gap, the query plan, and the single field the backend will silently coerce into the shape the frontend expected. One brisk walkthrough is a sighting, not a design; but it prevents the team from launching a feature that registers the same customer twice with the serene confidence of a system that was never asked to disagree.

Words from the spaceship manual, translated

Form: The interface element that collects user input and submits it. It is the frontend's promise about shape, and the backend's job to refuse what the frontend did not promise to prevent.
Request handler: A function that receives an incoming request, performs work, and returns a response. It is the backend's doorway, and like most doorways it will admit anything it is not explicitly taught to refuse.
Schema: The description of a database's tables, columns, types, and constraints. A schema is a contract the database enforces; the absence of a constraint is a constraint the database enforces just as firmly, in the direction of chaos.
Validation: The discipline of checking input on both ends — in the form for the user's benefit and in the handler for the system's. Validating on one end only is a trust exercise, and the other end has not signed up.