Who Saw the Connection? #04 — Railways × Human Factors × Software If you spend enough time on a railway platform in Japan, you may notice something that looks oddly theatrical. A conductor checks the platform, points down it, says something aloud, looks toward another reference point, and repeats the process. Inside the driver's cab, the same pattern appears around signals, instruments and track conditions. At first glance, it can look ceremonial. Maybe it's part of the formality people associate with Japanese railways. Maybe the employee is communicating with somebody farther down the platform. The real explanation is more interesting. They're performing a safety technique called shisa kanko, usually translated as pointing and calling. Instead of merely looking at an important signal or instrument, the worker points toward it and says its status aloud. The practice has existed in Japanese railways in some form for more than a century. Calling out signal information appeared in railway instruction manuals by the 1910s; pointing was added later, during the late 1920s, and Japanese National Railways formally required pointing while calling signals in its regulations in 1970. (Nippon) That history is interesting on its own. What makes it worth writing about is why the ritual survived. Because apparently looking at something and actually noticing it are not the same operation. A Railway Problem That Was Really a Human Problem Railways are full of repetitive decisions. Signals are checked again and again. Instruments are read again and again. Doors are opened and closed hundreds of times. Routes become familiar. Stations become familiar. Procedures become familiar. That familiarity is useful because humans would be painfully inefficient if every routine action demanded our full concentration. Unfortunately, the same automaticity that makes experienced people fast also creates a peculiar failure mode: sometimes the brain becomes very good at seeing what it expects to see. Most signals behave exactly as expected. Until one doesn't. Most gauges remain within their normal range. Until one doesn't. A person can therefore perform the physical act of looking without necessarily performing the cognitive act of registering what changed. Railway operators discovered that simply telling people to “pay attention” was not a particularly sophisticated safety system. Pointing and calling forces the check out of the worker's head. The operator looks at the target, points at it, identifies it verbally and hears their own confirmation. Instead of allowing the brain to glide over a familiar object, the procedure turns observation into a small physical event. It feels almost comically simple. That simplicity turns out to be important. Researchers Eventually Tested It In 1996, researchers from Japan's Railway Technical Research Institute published a laboratory experiment designed to measure whether pointing and calling genuinely reduced errors rather than merely looking reassuring. Participants performed a choice-reaction task under four conditions: no special confirmation, pointing only, calling only, and pointing while calling. The reported error rates were: Confirmation method Error rate No pointing or calling 2.38% Pointing only 1.00% Calling only 0.75% Pointing and calling 0.38% The combined technique reduced mistakes in that experiment to roughly one-sixth of the baseline rate. (J-STAGE) There is an important caveat here. That does not mean Japanese train drivers have 84% fewer accidents because they point at signals. The study was a controlled cognitive experiment, not a railway-wide accident trial. But it does establish something more useful: forcing a person to externalize a confirmation can materially change how reliably they perform that confirmation. That is a surprisingly deep result hiding inside what looks like a man pointing at a light. The Finger Is Not the Important Part It would be easy to turn this into a quirky piece of advice: Software engineers should point at production servers. I would prefer not to be responsible for that management initiative. The gesture itself is not the transferable idea. The interesting mechanism is that an important internal assumption is converted into an observable action before something consequential happens. Imagine a train driver approaching a signal. A purely mental workflow might be: I saw it. Green. Continue. Pointing and calling adds another step between perception and action. The driver has to identify the actual object, direct attention toward it, verbalize what it says, and only then continue. That is essentially a tiny piece of human-factors engineering inserted between “I think I know” and “execute.” Software systems desperately need more thinking in that space. Your Terminal Has the Same Problem Consider a production database migration. You have already tested it in development. Then staging. The pull request is reviewed, the change ticket is approved, and everything looks routine. You have also done this sort of thing hundreds of times. That sounds reassuring until you realize familiarity is precisely what makes the situation dangerous. Beginners tend to move slowly around dangerous systems. Experienced engineers become comfortable around them. Usually that is what expertise is supposed to achieve. Then one day somebody runs a perfectly valid command against the perfectly wrong database. Nothing crashes because of a software defect. Authentication works. DNS works. The database receives the command and performs it faithfully. From the database's perspective, this is excellent service. The human definition of success tends to differ. A surprising number of operational interfaces ask humans to distinguish dangerous contexts using extremely weak visual cues. Perhaps the shell prompt contains prod instead of preprod. Perhaps one browser tab belongs to a different AWS account. Perhaps the Kubernetes context differs by three characters. Then an engineer is expected to notice the distinction during an incident at two in the morning. When they don't, the postmortem eventually contains the phrase human error, as though we have discovered an exotic new failure mode. What Software Can Steal From the Railway A better system doesn't merely ask the engineer whether they checked the environment. It makes the environment itself part of the confirmation. Suppose a migration tool displays this immediately before executing: TARGET ENVIRONMENT : PRODUCTION ACCOUNT : 847291 REGION : eu-west-1 DATABASE : payments-primary Type the database name to continue: That is quite different from: Are you sure? [y/N] Anyone who has used computers for more than a few years has developed world-class muscle memory for defeating “Are you sure?” dialogs. The first version requires the engineer to inspect something that exists in the actual execution context and feed that information back into the action. It is a software equivalent of pointing at the signal and calling its state. This idea already appears in good operational tooling. Destructive interfaces sometimes require users to type the resource name. Production deployment systems prominently display environment, commit and target information immediately before promotion. Safety-critical workflows may require a second operator to independently verify an action. The common principle is simple: don't merely ask whether someone checked; design the workflow so the check leaves evidence. That is much stronger than another sentence in a runbook. We Keep Trying to Solve Human Error With Documentation A familiar incident-response pattern goes like this. Something goes wrong. The team fixes the immediate problem, conducts a postmortem and eventually adds a new instruction: Engineers must verify that the production environment is selected before running migrations. There. Safety has been upgraded. Until somebody selects the wrong environment again. The problem is not that the instruction is incorrect. Obviously the engineer should verify the environment. The problem is that the instruction does nothing to change the circumstances under which the previous person failed to verify it. Japanese railway workers did not spend decades developing pointing and calling because nobody had previously realized signals were important. They developed it because knowing that something should be checked and reliably performing that check are different engineering problems. Software organizations confuse those two surprisingly often. We write documentation describing ideal human behavior and then treat deviations as individual mistakes. Sometimes they are. But sometimes the interface itself quietly assumes humans will remain perfectly attentive while performing repetitive work under time pressure. That is an optimistic architecture. Friction Is Not Always the Enemy Modern product engineering has spent years removing friction. Fewer clicks. Faster flows. Automatic defaults. Remember the previous value. Skip the confirmation. Infer the next step. For routine actions, that is usually excellent design. Nobody wants a three-person approval ceremony to change a CSS variable. But we've become so accustomed to treating friction as inherently bad that we occasionally remove it from places where friction was doing useful work. A railway driver pointing at a signal takes slightly longer than glancing at it. That extra moment is not inefficiency accidentally left in the process. It is part of the process. The same distinction matters in software. A confirmation step that appears only before deleting a production database is not the same thing as an unnecessary modal appearing every time somebody saves a preference. One is bureaucracy. The other is a cognitive speed bump placed where moving too quickly is expensive. Good engineering is not about removing all friction. It is about knowing where friction costs more than it protects, and where a small inconvenience is extraordinarily cheap insurance. There Is a Catch: Humans Can Automate the Ritual Too Pointing and calling has its own uncomfortable failure mode. Any procedure repeated often enough can become automatic. A worker can eventually point, say the required words and continue while giving the confirmation very little thought. Japanese railway safety work has therefore also examined how to keep the practice from becoming an empty ritual and how to demonstrate its actual error-prevention effect during training. (Nippon) Software engineers will recognize this immediately. We are exceptionally good at turning meaningful safeguards into ceremonial checkboxes. Did you review the logs? Yes. Rollback tested? Yes. Security impact considered? Yes. Did anybody meaningfully perform those checks? That question tends not to fit inside the form. This is why the strongest confirmations interact with evidence rather than merely requesting agreement. Don't ask: Is this the correct database? Show: payments-primary and require the operator to act on that identity. Don't ask: Are you sure this is production? Make the production account visually and operationally different enough that the person has to acknowledge the actual context. And wherever a machine can verify something reliably, let the machine verify it. Pointing and calling is not an excuse for poor automation. It is useful precisely where human judgment remains unavoidable. Automation Makes the Remaining Human Actions Stranger, Not Safer There is another reason this idea matters more as systems become increasingly automated. Automation removes routine human intervention. That is good. But it means the actions humans still perform tend to happen when something unusual has occurred. Think about an automated deployment platform that works perfectly 99.9% of the time. The operator no longer manually performs dozens of steps every day. They intervene only when the automation cannot determine what to do. So the human is now performing a rarely practised task during an abnormal situation, probably while somebody is asking for an ETA in Teams. That is exactly when memory and attention are least deserving of architectural faith. The more sophisticated our automation becomes, the more carefully we should design the remaining moments where a human must make an irreversible decision. “An experienced engineer will notice” is not a control mechanism. It is hope wearing an access badge. The Practice Escaped the Railway Pointing and calling did not remain confined to train operations. It spread into Japanese factories, construction sites and other industries where repetitive work and human error can combine badly. (Nippon) That spread makes sense because the underlying problem was never really about trains. Railways simply happened to encounter it early and frequently. Any environment containing repetitive operations, dangerous exceptions and humans working under time pressure eventually faces the same question: How do you make sure somebody notices the one thing that changed? Different industries answer differently. Checklists. Two-person verification. Physical interlocks. Audible alarms. Typed confirmations. Pointing and calling. The implementations differ, but the systems thinking underneath them is remarkably similar. You do not solve human fallibility by demanding less fallible humans. You redesign the interaction around the human you actually have. Maybe the Pointing Isn't the Strange Part Once you understand what Japanese railway workers are doing, the pointing stops looking particularly strange. What starts looking strange is how many software systems rely on much weaker safeguards. We put staging and production behind nearly identical screens. We distinguish destructive commands from harmless ones with a flag. We hide critical context inside terminal prompts that experienced engineers barely consciously read anymore. Then somebody misses something and we add another paragraph to the runbook. Railway workers arrived at a more practical conclusion more than a century ago: if a particular observation matters enough, don't leave it entirely inside somebody's head. Make them identify it. Make them interact with it. Make the confirmation part of the operation itself. The laboratory evidence suggests that this apparently simple change can substantially reduce mistakes during confirmation tasks. (J-STAGE) And there is something wonderfully unglamorous about that. No artificial intelligence. No predictive analytics. No billion-dollar control system. Just a small piece of behavior designed around an inconvenient fact about humans. Sometimes we look directly at things and don't really see them. Who Saw the Connection? This series keeps pulling me toward engineering decisions that are sitting in public view while almost everyone walks past them. A UPS truck avoids a left turn and most of us see traffic. A railway worker points at a signal and most of us see a strange gesture. But underneath both behaviors is deliberate engineering: somebody studied a mundane action closely enough to discover that changing it could make an entire system behave better. That is the part I find fascinating. Software engineers tend to search for solutions inside software. We look for a new framework, architecture pattern, database or protocol because our vocabulary makes our problems feel unusually technical. But reliability problems existed long before Kubernetes decided to give them YAML. Railway operators have spent more than a century dealing with repetitive work, incomplete attention, dangerous exceptions and humans who occasionally make mistakes while doing something they have successfully done thousands of times. Their solution to one part of that problem looks almost absurdly simple. Point at the thing. Say what the thing actually is. Then act. Perhaps the next time a production procedure depends on somebody “just checking carefully,” we should ask a slightly different question: What would make the check impossible to perform without actually noticing what you're checking? Japanese railway workers have been answering that question with one finger for generations. Most passengers never realize why. And that's exactly what makes the story worth noticing. Sources & Further Reading For the history and modern use of pointing and calling, Nippon.com provides a useful overview covering its development from early call-and-response railway practices, the addition of pointing in the late 1920s, formalization by Japanese National Railways and adoption beyond railways. (Nippon) The experimental evidence comes from Shigeru Haga, Hajime Akatsuka and Hiroaki Shiroto's 1996 laboratory study, Laboratory experiment for verifying the effectiveness of “finger-pointing and call” as a practical tool of human error prevention. (J-STAGE) The older origin story around locomotive engineer Yasoichi Hori is widely repeated, but contemporary reporting notes that the exact historical origin remains uncertain, which is why I have not treated that anecdote as established fact here. (The Japan Times) About the Person Who Somehow Ended Up Pointing at Production Servers I'm Amrishkhan Sheik Abdullah, a Technical Lead and software architect based in Dubai. I build backend systems, microservices and distributed architectures for a living — which mostly means trying to design systems where humans don't have to remember twelve critically important things at exactly the worst possible moment. I write about software architecture, distributed systems, engineering decisions, AI developer tooling and, increasingly, ordinary-looking things that turn out to have surprisingly serious engineering hiding underneath them. Who Saw the Connection? is my series about exactly that: true stories where everyday behaviors, objects or decisions reveal an engineering idea worth stealing. Read More of My Writing I publish longer engineering articles, architecture deep-dives and the occasional story that starts with a train driver pointing at a green light and somehow ends up inside a production deployment pipeline. Writing: amrishkhan.dev/blog Elsewhere on the Internet Portfolio: amrishkhan.dev GitHub: github.com/amrishkhan05 DEV Community: dev.to/amrishkhan05 LinkedIn: linkedin.com/in/amrishkhan If you enjoyed this one, stick around. Apparently my current research strategy is to stare suspiciously at ordinary things until they confess why they were designed that way.