Don't Be Frupid

Value of Conferences

  • Strong disagreement on big vendor conferences: many see them as overpriced “paid vacations” with talks available free on YouTube; main in‑person benefits are networking, recruiting, and perks, not unique learning.
  • Some argue conferences function as rewards, tax-advantaged perks, or mini-holidays, not serious training.
  • Others stress value in:
    • Focused, protected learning time away from day‑to‑day work.
    • Specialized, industry‑specific user groups (e.g., regulated industries, vendor user conferences) where operational experience and roadmap details matter, sometimes “must have.”
    • Local/regional, community-driven events (FOSDEM, USENIX, etc.) as higher-signal and cheaper than big vendor shows.
  • Concern that many attendees mainly job-hunt or socialize; some prefer 1:1 expert training instead.

Tools, SaaS, and “$15 Saves Hundreds of Hours”

  • Several find the article’s anecdotes (cheap tools saving hundreds of hours, a conference saving millions) exaggerated compared to the reality of SaaS sprawl and unused licenses.
  • Descriptions of dark SaaS patterns: seat blocks, forced “enterprise” upgrades for basic security/SSO, hard-to-remove accounts, viral per-seat growth leading to huge recurring bills.
  • Counterexamples show that small spends (e.g., a design tool, a VPS) can indeed unlock large productivity or cost savings.
  • Consensus: both “no-questions-asked spending” and blanket penny-pinching are harmful; the difficulty is knowing which tools pay off.

Cloud, Infrastructure, and Databases

  • Debate over “cutting cloud costs”: some advocate moving to cheaper VPS/colo/on‑prem; others say that’s naive for complex, regulated, or highly scalable systems relying heavily on managed services.
  • Example of cost-optimization gone right: consolidating many tiny services into one “expensive” instance that was actually dramatically cheaper overall.
  • Example of cost-cutting gone wrong: under-provisioned CI/build infra causing multi-day turnaround, flaky tests, and major productivity loss.
  • Disagreement on database consolidation: one side fears underpowered shared DBs; others note multi-DB, microservice-heavy setups often create race conditions, stale data, and more cloud spend.

Developer Hardware and Work Environment

  • Many support high-end laptops, fast CI, prod-like dev environments, and strong connectivity as obvious ROI for expensive engineers.
  • Others think “give them the fastest MacBook” is self-serving without quantitative justification; cheap-but-adequate machines plus remote build/SSH can suffice.
  • Measuring productivity effects (e.g., compile times vs throughput) is viewed as both important and very hard; risk of false precision and overconfidence in shaky models.

Business Travel, Everyday Frupidity, and Incentives

  • Business travel cited as classic “frupid” territory: rigid policies banning discounted business class, requiring receipts (favoring taxis over public transit), or mandating multi-hop flights to “save” cash while burning staff time and energy.
  • Story of removing in‑office coffee machines to save one salary, which led to long café queues and huge time losses for highly paid staff.
  • Other examples: homebrew NAS vs reliable storage, rolling your own internal tools instead of buying, forcing office work instead of WFH, and multi-week onboarding due to IT constraints.
  • Multiple comments tie frupidity to:
    • Optimizing only easily measurable line items (hardware, cloud bills) while ignoring intangible costs (morale, flow, delay).
    • Split budgets where the team that “saves” doesn’t bear the resulting productivity cost.
  • The term “frupid” is linked to internal Amazon culture around “frugality” and compared to concepts like “false economy,” “suboptimization,” and the “Vimes boots” theory.