Korva is a scroll of the internet’s best ideas.

Defining bad and sad

Raw dashboards of load time or reliability are hard to read across many product surfaces, because it is unclear whether a given number is good. A simple framework helps: each team defines what a bad experience is for its own surfaces or services, what a sad one is, and the goal it wants to reach.

Examples in the CLI

In the CLI, a crash is bad, because work is lost. Flickering is sad: recoverable, but a pain point. Each team sets its own definitions, which makes it easier to zoom out and see the overall theme of the experience.

Why sads stack

Sads deserve attention because they stack. Tracking them alongside the bads supports earlier detection of quality problems, which the teams want to catch before they grow.

How do software teams define reliability targets?

Google's Site Reliability Engineering book, published in 2016, popularized service level objectives, which are explicit targets for how well a service should perform. A team picks a measure, such as the share of requests that succeed, and sets a goal for it. The gap between the goal and perfect performance is called an error budget. Teams spend that budget on risk and speed, and stop to fix problems when it runs out.

Why does terminal flickering happen?

A terminal interface redraws text by clearing lines and printing them again. If a program clears the whole screen and rewrites it on every update, the display briefly shows blank or partial frames, which the eye reads as flicker. Programs avoid this by updating only the lines that changed, or by sending a full frame in one step. The effect is cosmetic, since the underlying work is unaffected.

How are crash rates measured?

Teams commonly report crash-free sessions or crash-free users, the share of sessions that end without an unexpected exit. Mobile platforms and tools such as Firebase Crashlytics collect crash reports automatically and group them by cause. Tracking the rate over time shows whether a release made things better or worse. A rate that sounds high, such as 99 percent crash-free, can still mean many crashes at large scale.

More from Lenny's Podcast: Product | Growth | Career

Business & StartupsPlanning shrank to a monthly spreadsheetThe Claude Code team replaced its six-month roadmap with just-in-time planning: one lightweight spreadsheet of the month's priorities, checked weekly.
Enjoyed it?