The kind of company I want to be a part of

Original Article ↗ Hacker News Discussion ↗

How Much Do Pluralization Details Matter?

  • Some see the article’s concern as overreaction: pluralization is nice but ranks below higher-impact work like accessibility, main workflows, or performance.
  • Others argue “death by a thousand paper cuts”: each small rough edge signals lack of care and, in aggregate, degrades user trust and perceived quality.
  • There is broad agreement it’s a tradeoff: polishing copy vs shipping sooner; maturity is knowing where to draw that line.

Internationalization and Linguistic Complexity

  • Several comments note that naive n == 1 ? "item" : "items" only works for English and even then misses edge cases like zero.
  • Examples from Polish, Russian, Slovenian, Ukrainian, and Korean show complex plural and case systems, dual forms, and context-dependent endings.
  • This is used both to:
    • Argue that “(s)” is a pragmatic, language-agnostic hack when translation frameworks just substitute strings.
    • And to argue the opposite: “(s)” only works for English-like languages and falls apart elsewhere; proper i18n frameworks with plural rules (e.g., CLDR, Qt, Fluent) are preferred.
  • Some teams avoid pluralization entirely by restructuring text: e.g., “Files scanned: 3” rather than “Scanning 3 file(s)”.

Craftsmanship vs. Pragmatism and Business Pressures

  • Many read the post as being about craftsmanship: caring about small details as part of professional pride, akin to well-made furniture.
  • Others push back: obsessing over pluralization can become bikeshedding or “garnish over meal” if core functionality is shaky.
  • There’s a “broken windows” view: tolerating sloppiness in small things invites bigger defects and vulnerabilities.
  • Counterpoint: modern software is often bad not because developers don’t care, but because ad-driven business models and management incentives prioritize metrics and speed over quality.

Signals, Trust, and the Brown M&M Analogy

  • Some liken pluralization to Van Halen’s “no brown M&Ms” rider: a trivial detail used as a canary for deeper process quality.
  • Others are skeptical of such pop-psych shortcuts; a venue (or company) might ignore the trivial clause yet still do the critical work correctly.
  • Several commenters like these tacit signals but note they must align with reality—“say/mean/do” consistency—rather than being empty polish.

UX Tone and “Soulless Machinery”

  • Views diverge on friendly language and anthropomorphizing software.
  • Some want UIs that feel considerate and “human”; others find this fake-friend tone grating and only care about speed, clarity, and correctness.
  • Non-technical users often equate UI polish with overall quality, even when it hides deep complexity or cross-platform compromises.