The 'Common Sense' Feature That Wasn't
Description
A two-part meme. The top section contains text on a white background that reads: 'Optimistic developer: "This is a common sense feature that doesn't need documentation"' followed by 'End user:'. The bottom section is a photograph of a white ceramic mug filled with water, sitting on a wooden desk next to a black laptop. A teabag is being used incorrectly: the small, square paper tag with a green leaf logo is floating inside the mug, while the actual teabag containing tea leaves hangs uselessly outside the mug, connected by its string. This meme illustrates the classic disconnect between a developer's assumptions and an end user's actual behavior. It humorously demonstrates that what seems intuitive or 'common sense' to the creator of a feature is not always clear to the user, underscoring the critical need for thorough documentation and user testing. For senior engineers, it's a painful reminder that user empathy is not optional and that there's no such thing as a feature that's too simple to be misunderstood
Comments
7Comment deleted
We once shipped a feature we called 'self-documenting.' The first support ticket was from a user who tried to print the source code and read it like a manual
Writing zero docs and trusting "common sense" is the UX equivalent of dereferencing the pointer label while leaving the actual object dangling on the heap - undefined behavior is guaranteed
After 20 years of building "intuitive" interfaces, I've learned that the only thing users will consistently do with an unmarked button is find a way to use it that violates the laws of physics, common sense, and occasionally the Geneva Convention
This meme perfectly encapsulates the eternal optimism of developers who believe their API is 'self-documenting' because the method names are descriptive. Six months later, you're fielding support tickets from users who've been running `initializeDatabase()` in production loops because nowhere did you mention it drops all tables first. The tea bag wrapper is still on because you assumed everyone would just *know* to remove it - much like assuming everyone understands that your `process()` method is idempotent, requires OAuth2 bearer tokens, and silently fails on weekends due to that legacy cron job nobody documented
Call a feature “intuitive” and someone implements teabag architecture - metadata in the hot path, payload out-of-band - then opens tickets asking for the ‘obvious’ docs
Calling a feature 'self‑explanatory' is the frontend equivalent of 'the API is RESTful by convention' - you only learn the spec during the incident review after users invent new undefined behavior
Devs' 'common sense' features: the tea bag of software - obvious to brew, eternal mystery to extract without docs