Tag: dev-terms

  • What Is a Schema — Why Databases and Your Brain Use the Same Word

    Summary — the conclusion first

    A schema is a frame that defines, in advance, what shape data should take. In databases it’s the table blueprint; in psychology it’s the structure of knowledge in your head.

    Sharing the word is no accident. Both rest on the same idea — the frame must exist first, so that new things have a place to land.

    In development, a schema blocks garbage data. In learning, a schema catches new knowledge.

    Think of a bank form

    A bank form has rules per field. Letters in the name field, eight digits for the birth date, signature required.

    That agreement — field types, formats, what’s required, decided up front — is a schema. It’s the frame, not the content. Whoever fills it in, the form stays the same.

    In development — a blueprint for data

    In dev, a schema declares “this data must have this shape.” The meaning holds everywhere it appears.

    Context What the schema defines
    DB schema which tables hold which columns (name, type, required)
    API schema which fields a request or response must carry
    Form/config schema what format an input must follow

    A schema’s power is that it filters at the door. Send “abc” into an age field and it’s rejected before it’s stored. Without a schema, bad data piles up quietly and detonates months later.

    In psychology — the frame of knowledge in your head

    In 1932, psychologist Frederic Bartlett ran a famous experiment. He had English students read an unfamiliar Native American folk tale, “The War of the Ghosts,” then retell it later.

    They couldn’t recall it as it was. They reshaped it to fit frames they already had. Unfamiliar canoes became familiar boats; a strange ritual became a hunt.

    That pre-existing frame of knowledge is psychology’s schema. We don’t store new information verbatim — we file it into existing frames. It’s like having a “restaurant schema”: you’ve never been to this place, yet you walk in, sit, order, pay, without a manual.

    Why the same word

    The root is the Greek skhēma (form, shape). The two fields picked the same word because they do the same job.

    DB schema Mental schema
    The frame tables, columns existing knowledge structure
    New data inserted as rows attached to existing frames
    When it doesn’t fit rejected (an error) quietly distorted or forgotten

    The last row is the scary one. A computer at least throws an error. The brain distorts or drops it silently. Bartlett’s students never noticed their memories had changed.

    In practice — for studying and for building

    The concept works on both sides of the desk.

    Studying: when something won’t stick, it’s often not your memory — it’s that there’s no frame to hang it on. Meet a new concept and first ask, “what do I already know that this resembles?” One analogy outlasts ten repetitions.

    Building: define the schema before accepting data. “Store it now, clean it later” almost always ends in a garbage pile. And changing a schema is surgery on everything stored on top of it — back up first.

    One line

    Schema = frame. The frame must exist first for new things to find their place — in a database, and in your head.

    Sources

    These are the experiments and terms cited above.

    • Frederic Bartlett, Remembering (1932) — “The War of the Ghosts,” the start of schema theory
    • Jean Piaget — children grow schemas through assimilation and accommodation
    • JSON Schema — a standard example of schemas in dev
  • Yak Shaving, Idempotency, Dogfooding, Dead Man’s Switch — 4 Dev Terms That Work Outside Code

    A lot of developer slang points at how you work, not at code. These four do — getting lured down side-quests, repeating an action safely, using your own thing before you ship it, and stopping safely when you stop. Worth knowing whether you collaborate or work alone.

    TL;DR

    • Yak shaving: starting your real task, then drowning in a chain of side-tasks far from the point
    • Idempotency: running the same action many times gives the same result as running it once (safe to retry)
    • Dogfooding: using your own product as a user before handing it to anyone else
    • Dead man’s switch: when you stop sending the “I’m alive” signal, the system stops itself, safely
    • What they share: they look like code terms, but they’re really attitudes — focus, safety, honesty, failsafe
    Term One line At work
    Yak shaving side-quests bury the goal focus
    Idempotency many times = same as once safe repetition
    Dogfooding use it yourself first honest verification
    Dead Man’s Switch you stop → system stops safely failsafe

    1. Yak Shaving

    You want to wax the car, but the hose is missing. To buy one you need your store card, which expired; to renew it you have to return the neighbor’s book… and somehow you end up at the zoo, shaving a yak. The car is still dirty.

    Yak shaving is exactly this — a side-task started for a real goal spawns another, then another, until you spend all your time somewhere that looks unrelated to the original work. The term is said to have come out of MIT.

    It’s common in dev: “just fix one bug” → “need to update a library” → “need to swap the build tool” → half a day in config. Daily life too — sitting down to write one post and ending up redesigning the blog theme.

    Getting out: ask once, “is this actually needed for what I set out to do?” If not, leave a note about the side-task and return to the main one.

    2. Idempotency

    Press the elevator button ten times and it still arrives the same as one press. That’s idempotencydoing the same action several times yields the same result as doing it once.

    It’s originally a math term (f(f(x)) = f(x)), but in dev it matters most for safe retries. You send a payment request, get no response, and send it again. If it isn’t idempotent, you get charged twice. If it is, the same request is processed once — distinguished by an “idempotency key.”

    Telling them apart is easy. “Delete” is idempotent (deleting an already-deleted thing leaves it deleted). “Add 1” is not (each press increments).

    Why it helps: anywhere retries and automation live (payments, notifications, sync), it’s the lens for “if this runs twice, does something break?”

    3. Dogfooding

    “Eat your own dog food.” It’s said to come from a dog-food company proving quality by feeding it to its own dogs, and Microsoft spread it in 1988 to mean “let’s use our own software first.”

    The idea is simple — use it yourself, as a user, before selling or shipping it to anyone. You only catch the bugs and feel the friction by actually using it.

    The core is honesty. It’s hard to recommend a tool you don’t use yourself. Conversely, a tool you use daily gets better fast — because you’re the first to hurt when it’s clunky.

    One more step — dogfooding goes as far as “I used it.” The next step is a stranger using it, and the real test starts there.

    4. Dead Man’s Switch

    What happens if a train driver collapses at the controls? Old trains had a pedal. The train runs only while the driver keeps the pedal pressed; lift your foot (collapse) and the train stops itself. That device is the dead man’s switch.

    The name is grim, but the idea is simple — when you stop, the system stops itself, safely. Normally you keep sending an “I’m alive” signal; when that signal drops, it assumes the worst and fails toward safety.

    Dev and automation use it the same way. If a trading bot stops responding, it closes positions automatically (otherwise a market swing catches you defenseless). If a server misses its periodic “heartbeat,” another server takes over.

    Why it helps: for anything that runs unattended (bots, cron jobs, automation), it’s the habit of planting “if this dies, how does it stop safely?” in advance. Designing for how it dies is real safety, more than turning it on.

    In One Line

    The four point at attitude, not code.

    • Yak shaving → don’t get lured by side-quests; focus on the point
    • Idempotency → design so repeats and retries are safe
    • Dogfoodinguse it yourself before shipping
    • Dead Man’s Switch → design for how it dies, not just how it runs

    Name them and you can point at where work leaks — in conversations with developers, and when you work alone.