Stop Ruining It

Core theme: “Don’t ruin it” / via negativa

• Many comments agree that delight, trust, and curiosity often exist by default and are lost through overreach, not created from scratch.
• Once something is “ruined” (a product, brand, relationship), restoring it is slower and more expensive than not breaking it.
• Some point to “via negativa”: improvement often comes from removing harms and obstacles rather than adding more.

Trust, brands, and advertising

• Trust is seen as fragile and cumulative: people remember transgressions and may not return even after apologies or rollbacks.
• Example contrasts: a heritage physical-goods brand that offshores and cheapens quality is “hard to un-ruin,” whereas software can sometimes recover by clearly admitting mistakes and reversing bad policies.
• Debate on ads: some argue much ad spend is waste or mere brand awareness; others note that large firms redirect, not eliminate, spend and that effectiveness is hard to measure.
• Intrusive or misleading ad formats are said to damage both advertiser and host brand.

AI content and “cashing in” trust

• Observed pattern: individuals build trust with genuine insights, then switch to AI-generated “slop” that initially rides on prior credibility, then drives engagement off a cliff.
• Framed as a one-time extraction of reputation; rebuilding is hard.
• Some see this as part of wider short-term thinking and disbelief in the future.

Software design and “ruining it”

• Strong thread on Windows 11 File Explorer and other UI changes: complaints about clutter, lost clarity, slow rendering, and prioritizing KPIs and novelty over usability.
• Tabs are divisive: some see them as long-overdue quality-of-life; others as symptom of feature bloat and poor window management.
• General frustration with enshittified UX, especially when basic responsiveness and clarity regress compared to older systems.

Work, management, and empowerment

• One view: people start motivated; organizations “disempower” them through process and control. The real task is preventing this, not “empowering” after the fact.
• Parallel shift in software: from asking “what does the person want to do?” to “what do we want them to do?”, treating users as attention/Revenue units.

Simplicity vs. overengineering

• Several argue code and systems get better by removing complexity: fix flaky dependencies instead of layering caches/retries, favor simple loops over premature hyper-optimization.
• Emphasis on doing less, but better, rather than adding features to justify salaries or story points.