I can't pay rent because devs just don't care

Original Article ↗ Hacker News Discussion ↗

Blame and responsibility (devs, management, users)

  • Many argue the real problem is banks and managers prioritizing features, growth, and compliance over robustness and efficiency; devs often lack authority to fix bloat or UX edge cases.
  • Others push back: devs still declare features “done” without caring about performance, error handling, or low-end devices; they often choose bloated stacks and dependency chains.
  • A strong minority says users don’t truly care either: people keep using slow, bloated apps and rarely reward lean alternatives with their wallets.

Micro-optimizations, bloat, and JS-heavy web

  • Several comments distinguish “micro-optimizations” from basic efficiency: the issue isn’t shaving 150ms from a button, but avoiding multi‑hundred‑MB apps to send a few fields of data.
  • Widespread frustration with JS-heavy SPAs for simple tasks (parking payments, banking, government forms) when plain HTML + light JS would suffice.
  • Some argue customers implicitly “demand” rich interactions; others counter that many transactional sites (banks, utilities, taxes) gain nothing from this complexity.

Socioeconomic blind spots and timing of payments

  • Some dismiss the scenario with “just don’t pay rent at the last minute” or “use autopay/cheques/debit.”
  • Others emphasize that many people live paycheck-to-paycheck, can’t pay early, fear overdrafts, and lack buffers; well-paid devs often don’t see these constraints.
  • Commenters with poorer backgrounds note how different their risk calculations and priorities are from colleagues’.

Banking apps, critical services, and fallbacks

  • Strong sentiment that anything on the “critical path for life” (rent, visas, healthcare, utilities) should work on low-end devices, slow connections, or even without tech.
  • Calls for maintaining low-tech fallbacks: checks, cash, in-person branches, phone support, human restaurant ordering, taxis without apps.
  • Others reply that physical options can be insecure, inconvenient, or disappearing (mail theft, limited hours).

App size, dependencies, and trackers

  • Many astonished at 100–300MB+ “simple” apps (UPS, banks, Amazon, Google); theories include cross-platform frameworks, multiple DPI assets, bundled languages, and numerous tracking/metrics SDKs.
  • Some note platform tooling now allows device-specific resource delivery, but not all apps use it.
  • Several insist making apps truly small is work: pruning dependencies, dropping analytics, removing needless media.

Process, QA, and organizational incentives

  • Common theme: organizations optimize for “features must flow” and visible change (new UI, redesigns) rather than stability and polish.
  • Good QA and PMs are seen as rare but crucial for representing real user constraints (low-end devices, edge cases); many teams skimp on them.
  • Some advocate that engineers should resist shipping “works on my machine” code and refuse to call features done without basic performance and reliability.

Hardware, RAM, and “old phone” debate

  • One side: using a 2GB/old phone and expecting everything to work is unrealistic; modern encryption, media, and features require newer hardware.
  • Other side: there’s no technical reason a simple transactional flow should fail on such hardware; bloated layers and frameworks, not fundamental capability, are blamed.
  • Disagreement over whether new hardware “eliminates” the problem or just masks poor software design.

Reactions to the article’s style

  • Some like the rant as an emotional expression of real user pain and a wake-up call to engineers.
  • Others criticize the fictionalized hook and perceived “JS bad” strawman as sophomoric, lacking concrete proposals, and over-dramatizing edge cases.