惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

奇客Solidot–传递最新科技情报
奇客Solidot–传递最新科技情报
Jina AI
Jina AI
博客园 - Franky
Apple Machine Learning Research
Apple Machine Learning Research
酷 壳 – CoolShell
酷 壳 – CoolShell
阮一峰的网络日志
阮一峰的网络日志
量子位
雷峰网
雷峰网
宝玉的分享
宝玉的分享
V
Visual Studio Blog
博客园_首页
小众软件
小众软件
The Cloudflare Blog
让小产品的独立变现更简单 - ezindie.com
让小产品的独立变现更简单 - ezindie.com
大猫的无限游戏
大猫的无限游戏
博客园 - 聂微东
S
SegmentFault 最新的问题
博客园 - 【当耐特】
OSCHINA 社区最新新闻
OSCHINA 社区最新新闻
博客园 - 叶小钗
月光博客
月光博客
博客园 - 三生石上(FineUI控件)
人人都是产品经理
人人都是产品经理
WordPress大学
WordPress大学

Pierce Freeman

A browser for agents | Pierce Freeman The grey market of podcast appearances The way I travel | Pierce Freeman Fixing slow AWS uploads | Pierce Freeman Local tools should still use vaults We solved scratch content first Starting a podcast in 2025 Being late but still being early Automating our home video imports Adding my parents to tailscale A deep dive on agent sandboxes Language servers for AI | Pierce Freeman My simple home podcast studio We need centralized infrastructure | Pierce Freeman Coercing agents to follow conventions using AST validation My unified theory of social selling My personal backup strategy | Pierce Freeman July updates to the homelab How the KV Cache works httpx is the right way to do web requests in Python Reputation is becoming everything | Pierce Freeman Building a (kind of) invisible mac app Updated knowledge in language models Making an ascii animation | Pierce Freeman How speculative decoding works | Pierce Freeman Under the hood of Claude Code Doing things because they're easy, not hard Speeding up sideeffects with JIT in mountaineer Firehot for hot reloading in Python Misadventures in Python hot reloading
The power of status updates
2022-10-19 · via Pierce Freeman

When I was leaving Paris by train out of Gare du Nord, we showed up twenty minutes before our scheduled departure. Typically that's more than enough time to grab a bite, find your cabin, and settle in before you roll out of the station. We checked the schedule board and saw our train wasn't yet assigned a platform. No problem. We got some food and came back around. Still no official gate.

As the clock ticked closer to departure, people started frantically running around. "Do you know which gate is ours?" "Is that our train?" With every minute that went by a larger crowd assembled around the status board. When one person caught wind of a rumor, there was a manic movement of people to a new platform to try and board that train. Everyone was turning to their neighbors and asking if they had any idea what is going on.

We had pieced together which track our train was on and that it was delayed by an unknown period. We told one group what we knew. Then another. Before we knew it we were performing crowd control for a sea of people, telling them they needn't worry and that we would all get on a train.

When people don't have any update, they start to question reality. Are they missing something; is it their fault; will the problem ever get addressed? It puts the onus of information gathering up to them and that onus leads to stress.

People are understanding of setbacks when they happen but only when they know what's happening. That was the key issue in the mayhem at du Nord. There was no official communication or even acknowledgement of the delay. This vacuum pushed an annoying situation over the edge. A delayed train is one thing. The concern that you might miss it entirely is far worse.

Software is the same way. That's the power of outage dashboards. When people can confirm there's a known issue and there's an acknowledgment that people are working on it, it's comforting. They give the impression that you're equally updated to the issue as internal employees. An unacknowledged outage results in the same blame game that a physical situation would.

There's a reason why dashboards have become increasingly common over the last decade (and why Atlassian bought StatusPage). Hearing from people with more context can immediately dissolve fears. The outage playbooks that we ran at Globality had a sub 15min reporting window so we could update affected clients. Even if the update only featured an acknowledgement that it's still under investigation - or technical details that many won't understand - they still went a long way. If you're stuck between under sharing and over sharing, over share. It shows that all hands (or at least some hands) are on deck.

I remember one outage at Abstract with the login system. Some SSO accounts became delinked from their primary record and couldn't login. Cole, the CTO, started emailing the client who reported the issue to give a play by play of the updates. All-in-all it took 30 minutes to fix. The client walked away incredibly thankful at the end of the outage, and a bigger advocate for the platform than when they started the day. The clear and frequent communication separated his experience from the status quo.

Interestingly it's still not a de-facto standard for most legacy software players to provide outage tracking. That's probably a cultural barrier - many organizations don't want to publicly acknowledge when there's a problem. It can harm their initial pitch of reliability. But in the long term the lack of clear reporting hurts more than helps. It decreases trust in the application and in the organization. That might actually provide the opening for a challenger to contend for the throne.

For software and for trains, trust is everything. If only du Nord got the memo.