Hacker News, Distilled

Definition of “software productivity”

• Many argue productivity is, in principle, just outputs/inputs (an economic ratio), so it must exist for software.
• Others say that for software, “output” is inherently fuzzy: is it code, features, solved problems, business value, or long‑term stability?
• Some see the article as mainly semantic: rejecting the word “productivity” to emphasize “solving problems” and reducing long‑term costs instead of “producing code.”

Can it be meaningfully measured?

• One camp: Yes, at least in aggregate or over long time frames. Examples: revenue per employee, completed projects per time, “shit_done/time_elapsed”.
• Another camp: Any non‑toy attempt runs into confounding factors (maintenance, correctness, compute cost, future extensibility), making comparisons unreliable or domain‑specific.
• Many distinguish between observing that some engineers outperform others vs. turning that into a robust, reproducible scalar metric.

Problems with simple metrics (especially LOC)

• Strong consensus that lines of code are a bad metric: more code often means more bugs, more maintenance, and lower real value.
• Deleting code or avoiding code can be higher value than adding it; code is often a liability, not an asset.
• Attempts to refine LOC with adds/deletes, tickets closed, or DB “tasks” still fail to normalize for difficulty, quality, or downstream impact.

Business value, money, and customers

• Several commenters say only business value or profit really matter; productivity must be evaluated via money.
• Others argue money is a crude proxy for usefulness; happy or “demanding” customers and long‑term value may diverge from short‑term profit.
• Debate spills into capitalism vs. alternatives and whether “money is the measure of usefulness.”

Teams, knowledge work, and impact

• Repeated point: metrics work better at the team/product level than for individuals; software is closer to research or art than factory work.
• Impact is viewed as the only truly meaningful metric, but many argue it is inherently unmeasurable beyond rough proxies.
• Goodhart’s law and perverse incentives (rewarding firefighting, visible artifacts, or short‑term gains) are recurring concerns.
• Some propose multidimensional dashboards (speed, quality, user impact, job satisfaction) used as managerial input rather than a single ranking number.

Perl as a productivity and text‑processing tool

• Many describe Perl as a “superpower” for Unix text wrangling, one‑liners, and fast scripting, often replacing days of manual or multi-person effort.
• Strengths highlighted: tight integration with Unix/POSIX, powerful regex syntax, associative arrays, and the ability to solve complex text problems in very few lines.
• Some see Perl, awk, sed, jq, and bash as transformative for sysadmin/devops work compared to heavier general-purpose languages.

Ecosystem and CPAN vs modern package managers

• CPAN is praised as historically unmatched for breadth, obscure libraries, and “batteries included” feel.
• Others argue that Node/NPM and ecosystems around Python/PHP/JS have surpassed CPAN in current, business‑oriented libraries (APIs, modern file formats, data science).
• Concern that parts of CPAN are aging or unmaintained as early contributors move on, though Perl’s strong backward compatibility mitigates breakage.

Maintainability, readability, and culture

• Perl’s terseness and features (regex, implicit $_, sigils, AUTOLOAD, etc.) are seen by fans as expressive and close to how humans describe tasks.
• Critics stress readability problems, surprising semantics (contexts, references, filehandles), Unicode pitfalls, and “hieroglyphic” code that others rewrite rather than maintain.
• There’s a recurring debate about “lone-genius” productivity vs team maintainability, and pushback against elitist attitudes toward Python and mainstream tools.

What to learn now for CLI text processing

• Some recommend learning Perl as a “superset” of awk/sed; others suggest starting with awk because it’s smaller and easier.
• Several argue that today the gap is smaller: Perl might turn a 100‑line task into 1 line, but modern alternatives often do it in a few clearer lines.
• Python and Ruby are suggested when tasks grow beyond quick shell pipelines; tools like miller (mlr) are mentioned for structured data formats.

Language features and OO

• One side claims “it’s all regex”; others point to references, map/grep, pack/unpack, OO frameworks (Moose/Moo), functional patterns, and type systems.
• Perl’s OO is described as flexible but low‑level; higher‑level libraries make it powerful but also fragmented.
• Some features (e.g., given/when/smartmatch) are noted as deprecated, illustrating evolution and design reversals.

Web backends and modern usage

• Perl web frameworks (Mojolicious, Dancer, Catalyst, etc.) are cited as capable for APIs and apps.
• However, many see PHP/Ruby/Python frameworks as “miles ahead” in ecosystem depth (auth, validation, admin UIs, integrations), reducing Perl’s appeal for new web projects.

Longevity, ubiquity, and decline

• Perl is praised for scripts that keep running unchanged across OS upgrades, like a “solar calculator.”
• Counterpoint: some modern Unix systems no longer ship Perl by default; certain domains (e.g., ClickHouse drivers) lack up‑to‑date Perl libraries.
• Several note that enthusiasm is strongest among those who learned Perl in the 1990s; advice to “learn it while young” is reframed as mostly nostalgia and early‑imprint bias.

Overall interpretation of the article’s claim

• Many readers found the article vague and asked what it was “actually saying.”
• Several commenters summarize it as: advanced civilizations may pursue sustainability and integration with their biosphere, resulting in technospheres that look like “nature” and are hard to detect.
• This reframes the Fermi paradox: instead of Kardashev-style megastructures, advanced societies might be efficient, quiet, and ecologically harmonious.

Civilization as “indistinguishable from nature”

• Sci‑fi precedents: futures with lush landscapes, buried or invisible machines, or fully biological habitats.
• Suggestions that optimal “progress” may be small high-density hubs plus rewilded planets.
• Some imagine biological or bio-digital computing distributed through ecosystems, or uploaded consciousness into planetary biospheres.
• Others extend this to possible “privacy” or stealth: advanced civilizations might deliberately hide detectable signatures.

Growth, sustainability, and thermodynamic limits

• One side argues exponential energy/economic growth is mathematically unsustainable; even galactic-scale energy runs into physical limits and waste-heat constraints.
• Counterarguments:
  • Growth rates can slow (S-curves), and future tech/efficiency may decouple growth from resource use.
  • Human choices, not physics alone, shape trajectories; it’s unclear how other civilizations choose.
  • On human timescales (centuries), limits of growth may be practically irrelevant.
• Debate over whether we “already have the tech” for sustainable growth versus fundamental thermodynamic/ecological ceilings.

Resources, materials, and long-term industrial futures

• Concerns that industrial civilization may be time-limited by finite high-grade ores and recycling entropy.
• Others claim materials are effectively inexhaustible with enough energy and substitution, especially if space resources become viable.
• Disagreement on plausibility and timescales of asteroid mining, fusion, and large-scale space industry.

Interstellar travel and colonization

• Skeptics: interstellar travel and even Mars bases are economically irrational, slow, and fragile; nearer options like Antarctica or oceans are easier.
• Supporters: long-term species survival, resource access, or “planting trees for future generations” can justify it despite poor short-term ROI.
• Some argue biological systems are too low-power for interstellar travel; others propose hybrid bio–tech solutions for ultra-long missions.

Evolution, intelligence, and “nature vs technology”

• Debate over whether complex artifacts must be products of conscious design or can emerge from evolution.
• Some insist evolved structures show “baggage” distinct from engineered systems; others note that human creativity itself is an evolutionary product.
• A few philosophical tangents explore whether “nature” and “technology” are even fundamentally distinct, or whether civilization is just another natural process.

Overall reception of “A Philosophy of Software Design”

• Many commenters find it one of the best practical books on software design, especially around modularity, “deep modules,” and thinking explicitly about complexity.
• Others consider it shallow or obvious, or say it covers only “low‑hanging fruit” and skips the hardest design problems (e.g., large, dynamic systems like game engines).
• Several note that you only really “get” it after some real‑world experience; junior devs may benefit but also risk over‑applying rules.

Functional programming (FP) vs the book

• FP‑oriented readers criticize the book for barely addressing purity, mutation, and separation of IO from logic.
• They argue FP (or “functional core / imperative shell”) gives formal, concrete tools for reducing complexity that should be central to any “philosophy of design.”
• Others reply that useful design philosophies need not be formally complete, and that a simpler, more accessible treatment may be more effective for most practitioners.
• Some see FP evangelism itself as quasi‑religious; there’s pushback against the idea that non‑FP developers are “unqualified” to talk about complexity.

Deep modules, APIs, and abstraction size

• A major praised idea: modules should have small, simple public interfaces but “deep” implementations that hide substantial complexity.
• Examples like Unix file IO and garbage collectors are debated: some see them as quintessential deep modules; others argue their true “interface” is large and cross‑cutting, so the example is misleading.
• Several like the guideline of narrowing public APIs and being less dogmatic about short methods; others worry about over‑abstraction (e.g., excessive service classes).

Small methods, Clean Code, and incidental complexity

• There’s substantial criticism of “Clean Code”–style rules (e.g., very short methods, many tiny classes) for leading to fragmented, hard‑to‑navigate code and lifted state.
• Others defend those books as useful for beginners to develop an aesthetic sense and awareness of maintainability, but agree rules must not be followed mechanically.

Examples, testing, and business logic

• Some feel the book’s or article’s examples (e.g., discount services) are oversimplified or even bad: they may mix distinct business concepts (shipping vs order discounts) or introduce unnecessary abstraction.
• Others argue the refactorings improve testability (via injected services and fakes) and demonstrate how to centralize logic as complexity grows.
• Several emphasize that “it depends”: duplication can be acceptable early (WET—write everything twice) until real reuse patterns and divergent requirements emerge.

Memory Bandwidth, Caches, and “RAM Myth” Nuances

• Several commenters note the benchmarked throughput (400 MB/s for 50M 8‑byte elements) is far below nominal DDR4 bandwidth (50 GB/s), implying the code is hitting latency, not peak throughput.
• Others point out that sequential vs random access, cacheline behavior, controller design, and prefetching mean “theoretical bandwidth” is rarely achievable.
• Clarification that misses are mostly about latency, but poor access patterns can also hurt effective throughput.

Access Patterns, Locality, and Algorithm Design

• Strong agreement that access patterns and locality dominate performance once data exceeds cache sizes.
• Radix-style sharding is praised for keeping only per-bucket tails hot in cache; parallel per-bucket minima is suggested as an even more cache-friendly alternative to moving full elements.
• Cache-oblivious algorithms and hardware prefetchers are mentioned as important but underused tools; explicit prefetch is seen as niche but sometimes useful.
• Some expected deeper coverage of NUMA, GPUs, SRAM, and temporal instructions; current article is viewed as only one slice of the memory hierarchy story.

Optimization vs Engineering Time and Complexity

• One camp argues hardware is cheap and engineering time is expensive; sub–10× speedups rarely justify extra complexity for most workloads.
• The opposing view stresses cumulative impact of “good enough” decisions: more cores, higher cloud bills, slower CI, and poor user experience (e.g., slow Jira).
• Debate over when smaller wins matter: at scale, even shaving nanoseconds in hot loops or milliseconds in critical paths can pay off; for many business apps, readability and simplicity still dominate.

Language-Level Details and Micro-Optimizations

• Python examples spark debate: choice of data structures (array, list, deque) and RNG functions (random() vs randint()) can yield 2×+ speedups but often don’t affect bottom line unless in hot loops.
• Several say Python is the wrong place to obsess over micro-optimizations; hot paths should move to C/Rust or vectorized libraries (e.g., NumPy).
• Others counter that understanding such tradeoffs is part of basic craftsmanship even if not always used.

Abstraction, Curiosity, and Developer Culture

• Strong disagreement over whether tech is uniquely “incurious.” Some describe burnout and impossibility of staying current across stacks; others lament overreliance on frameworks and lack of systems understanding.
• There’s frustration that many developers don’t automate repetitive tasks or reason about performance, relying instead on hyperscaler infrastructure built by more performance-conscious teams.

Pedagogy, Pseudocode, and Communication

• Mixed reactions to Python pseudocode: some find it clear, others argue a lower-level language (C/C++/Go) would better expose memory layout and cache behavior.
• General sense that industry lacks structured, widely adopted “continuing education” on performance fundamentals; blogs and talks fill the gap unevenly.

Using Java “in the small”

• Many are surprised how far Java has come for scripting: single-file source execution (java file.java), preview implicit classes/top-level main, automatic imports (e.g., IO.println), and JShell.
• Newer features like var, record, local records, and switch expressions make short programs less clunky and more expressive.
• Some use Java 21+ for Advent of Code and quick utilities and report it feels much nicer than “old Java”.
• Others argue that for true “one-off” CLI scripts, Java remains heavier than ideal, especially once dependencies or build tools enter the picture.

Comparisons to Other Languages for Scripting

• Python and Go are still widely seen as better fits for quick scripts: less ceremony, easier deployment (including static binaries in Go).
• Several note that C#/.NET (with top-level statements, LINQ, scripting tools, notebooks) is ahead of Java in “small” productivity.
• Kotlin, Scala (scala-cli, ammonite), Groovy, Clojure/babashka, JRuby, and Kotlin scripts are highlighted as JVM-based options that feel more “script-like” while reusing Java libraries.
• Deno, Node.js, PHP, Ruby, and F#/dotnet-script are cited as alternative scripting ecosystems.

Ecosystem, Frameworks, and Tooling

• Strong split on frameworks: some praise Spring Boot and Spring Data as massive productivity multipliers; others describe legacy Spring/Hibernate codebases as opaque, slow, and hard to reason about.
• Debate over frameworks vs libraries: frameworks invert control and boost CRUD productivity but can hide complexity and create tight coupling.
• Many dislike Maven/Gradle complexity for small tasks; others point to tools like JBang, coursier, scala-cli, or simple CLASSPATH usage to keep things lightweight.

Language Design, Exceptions, and Types

• Several see Java as excellent for large, long-lived projects: stable evolution, strong tooling, runtime introspection, and backward compatibility.
• Others criticize checked exceptions and verbosity; comparisons are made to Rust-style ? and other languages’ more ergonomic checked-error syntax.
• Discussion of generics, type inference, and upcoming features (value objects/Valhalla, improved nullability) shows recognition that Java is converging toward more modern type systems, though some still prefer Kotlin/C#.

Teaching and First-Language Debate

• Simplified main is seen by some as a big win for beginners, reducing confusing boilerplate; others think the old public static void main was a useful early lesson in Java’s model.
• Broader disagreement over whether Java is a good first language at all versus starting with a REPL-driven, less ceremonious language (Python, BASIC-like environments).

Performance, Memory, and Deployment

• Consensus that modern HotSpot is very fast and GC is highly advanced, but disagreement over memory footprint and startup time relative to Go/Rust/Zig.
• Some organizations remain on Java 8/11 due to upgrade risk, effort, or lack of perceived benefit, despite clear performance and GC gains in newer JDKs.
• Native images (GraalVM) and better container tuning are suggested to mitigate startup and memory concerns for microservices and functions.

Parallels to Current Drone/UFO “Lights in the Sky” Stories

• Many see the 1954 windshield pitting scare as analogous to current drone/UFO reports (especially New Jersey), where increased attention leads to a surge in sightings and interpretations.
• Commenters note people are now noticing planes, stars, Venus, satellites, and consumer drones they previously ignored, then labeling them as “mysterious drones.”
• Examples: a governor misidentifying stars as drones; local news mislabeling Venus; people flying their own drones to “hunt” other drones, further confusing the picture.

Mass Hysteria, Attention, and Collective Delusion

• The thread frames the 1954 event as a mix of:
  • Attentional/confirmation biases (you “can’t unsee” pitting once primed).
  • Frequency illusion (once primed, you suddenly “see it everywhere”).
• Debate on terminology:
  • Some prefer “collective delusion” or “mass hysteria.”
  • Others argue people were actually noticing real pits, but wrongly concluding they were new.
• Many historical analogues cited: Havana syndrome, killer clowns, Mad Gasser of Mattoon, Monkey-man of Delhi, Pennsylvania UFO–Bigfoot wave, dancing plagues, witch trials, Cold War scares.

Debate Over What’s Actually Flying Around Now

• One side: most recent “mystery” videos are explained by planes, helicopters, stars, satellites, flares, fireworks, consumer drones, camera artifacts. NYT analysis reportedly found no conclusive drone footage.
• Other side: insists there are genuine large, quiet drones/UAPs with unusual light patterns and behavior; some suggest military origin and say official non-denials support this.
• Strong pushback: humans can’t reliably judge distance, size, or speed of unknown lights at night; personal eyewitness certainty is not strong evidence.

Narratives, Conspiracies, and Human Psychology

• Several comments focus on:
  • How media, social networks, and partisan outlets direct attention and outrage.
  • “Low Information High Satisfaction” explanations (conspiracy-like stories that feel good with little evidence).
  • Humans as highly suggestible animals, prone to overconfidence, confirmation bias, and social proof—even among educated or “rational” people.
• Some find the takeaway “terrifying”: societies can rapidly self-organize around false or overblown beliefs with minimal triggers. Others see this as a stable, longstanding human trait to understand and manage, not panic over.

Clarifications on the 1954 Windshield Case

• Consensus: most pits were long‑existing wear and tear newly noticed after media coverage.
• The “epidemic” was less about new physical damage and more about a sudden, socially amplified shift in perception.

General reception & use cases

• Many Linux users report using Solaar for years without issues, often via distro repos or Flatpak.
• Common uses: pairing devices to Unifying/Bolt receivers, checking battery status, toggling Fn vs F1–F12 behavior, disabling tap-to-click, and adjusting MX-series features like scroll-wheel ratchet thresholds and gesture buttons.
• Some only use it occasionally (e.g., after battery changes or device moves) but consider it essential “quality of life” tooling.
• A few found the rule editor and gesture configuration confusing and gave up for simple remaps.

Comparison with Logitech’s official software

• Logitech’s Windows/macOS tools are widely criticized as bloated (hundreds of MB, Electron-based), resource-hungry, intrusive (auto-running agents, upgrade checkers), and phoning home; the “offline” corporate build is said to still contact Logitech.
• The addition of an “AI prompt builder” to the mouse driver is seen as emblematic bloat.
• Some praise Logitech’s features: per-application profiles, automatic profile switching, cross-computer mouse/keyboard and clipboard sharing, and lightweight Onboard Memory Manager for programming onboard profiles.
• Several users explicitly say they buy Logitech hardware because Solaar lets them avoid the official software on Linux.

Why a peripheral manager is needed

• Base HID drivers handle typing and pointing, but not:
  • Programmable buttons, macros, DPI/polling changes.
  • Scroll-wheel clutch/detent control and reassignment of wheel vs extra middle button.
  • RGB lighting control and persistence.
  • Per-device behavior (MX keyboards’ media vs F-keys, special laptop-like shortcuts).
• Some posters argue these are “niche” or goofy, others respond that such features are exactly why these premium devices sell.

Dongles, pairing, and connectivity

• Discussion of three receiver families: single-device dongles, Unifying (up to 6 devices), and newer Bolt (BLE-based, more secure).
• Bolt and Unifying are incompatible; users end up with multiple dongles for different Logitech lines (MX, Lightspeed, etc.).
• Solaar is valued for managing receiver pairing fully on Linux; Logitech also provides a web-based pairing tool.
• Connectivity tips: use Bolt instead of Bluetooth for reliability (though some report the opposite on Linux); avoid USB 3 ports or use short USB 2 extension cables to reduce 2.4 GHz interference.

Device quality and longevity

• Mixed reports on Logitech durability: some mice and keyboards working flawlessly for 10–14+ years; others see switches double-clicking in 2–3 years, especially on some gaming and budget models.
• Several users replace switches with higher-quality parts (TTC, Kailh, etc.), or choose brands that emphasize repairability.

Alternatives & broader ecosystem

• Other Linux tools mentioned: Piper/libratbagd, logiops/logid, input-remapper.
• On macOS, users recommend SteerMouse, BetterMouse, Mac Mouse Fix, and similar tools over Logitech’s own software.
• Thread situates Solaar within a growing Linux hardware-management ecosystem (e.g., CoolerControl, LACT, Boatswain).

Implementation details & portability

• Solaar is written in Python and is not a kernel driver; it talks to devices via HID++ over existing HID drivers.
• Some express desire for first-class Windows/macOS ports; there are experimental macOS attempts but nothing polished yet.

Nostalgia & Historical Parallels

• Many compare 1‑800‑ChatGPT to GOOG‑411, TellMe, ChaCha SMS search, and 90s-era phone-based or dot‑com services (e.g., “call the internet,” AOL keywords, novelty sites like zombo.com).
• Some note it “feels like” something early Google or Yahoo would have launched, with a playful, retro marketing vibe.

Intended Users, Accessibility & Use Cases

• Strong interest from people who want hands‑free access while driving, walking, cooking, or doing housework; phone calls integrate better with car systems and voice assistants than a dedicated app.
• Several mention this is ideal for people without smartphones, with only landlines, or in restricted environments (e.g., jail, flights with messaging-only Wi‑Fi).
• Debate over whether older (50+) users are a target: some assume they prefer phones; others push back, calling that stereotype wrong and noting many in that age group are highly tech‑literate.

Perceived Value vs. Gimmick

• Enthusiasts see this as:
  • A genuinely useful new channel (especially via WhatsApp/SMS).
  • A “killer feature” for hands‑free voice, and a low-friction trial for non‑users.
• Skeptics view it as:
  • A gimmicky wrapper over existing capabilities.
  • Evidence that model quality may be plateauing, with energy shifting to “bells and whistles.”

Model Quality, Hallucinations & UX

• Mixed reports: some get instant, correct answers; others see misrecognition (e.g., simple math questions via voice) and verbose “LLM yap” that feels more annoying when spoken.
• Confusion over model identity and knowledge cutoff: the FAQ says Oct 2023, but some sessions claim GPT‑4 with a Jan 2022 cutoff.
• Generally acknowledged that LLMs can hallucinate, especially on precise specs or recent media, though others argue their reliability has improved and is task‑dependent.

Data Collection, Privacy & Ethics

• Many assume this will generate large volumes of telephony-grade voice data, useful for training speech, customer support agents, and user-preference models.
• Some are uneasy about calls being recorded, caller ID handling (including blocked numbers still being recognized for rate limits), and whether disclaimers should be repeated every call.

Technical & Implementation Notes

• Built on Twilio SIP trunking with custom SIP servers for logic (usage limits, user-specific greetings) and internal access.
• Telephony constraints (8 kHz bandwidth, noisy environments) are discussed as challenges; users note background noise can still trigger misinterpretation.

Free Tier Details & Usage Limits

• New free GitHub Copilot tier in VS Code includes ~2,000 completions and 50 chat requests per month.
• Many full‑time developers consider this far too low (“a few days” or “one day” of use); hobbyists or occasional coders may find it sufficient.
• Several see it as “shareware” or a funnel to upsell Pro, not a truly free professional tool.
• Some developers plan to downgrade/cancel paid plans but keep using the free quota opportunistically.

Copilot vs Cursor, Windsurf, Codeium & Others

• Numerous users say they switched from Copilot to Cursor or Windsurf and find those significantly better, especially for:
  • Multi‑file edits and patch application.
  • Inline multi‑line edits and “edit around cursor” behavior.
  • Faster, more relevant autocomplete.
• Others argue Copilot Edits and chat+edits are improving and closing the gap but still feel clunky or unreliable for large refactors.
• Some feel Copilot remains “glorified autocomplete” compared to more agentic tools.
• A minority report opposite experiences: local tools or alternatives like Continue felt worse than Copilot for them.

IDE Ecosystem & Workflow

• Strong divide between:
  • VS Code / Cursor / Windsurf users, who praise rapid AI integration and multi‑file agents.
  • JetBrains users, who value superior navigation, refactoring, debugging, and tooling, and bolt on AI via Copilot, Cody, CodeGPT, etc.
• Several keep two tools open: one “real IDE” (JetBrains, Visual Studio) plus an AI‑centric editor (Cursor/Windsurf/Zed).
• Vim/Neovim users rely on plugins (copilot.vim, CopilotChat, Continue, CodeCompanion) but feel still behind Cursor‑style experiences.

Privacy, Training, and Licensing Concerns

• Many worry Copilot free tier is partly about harvesting more proprietary code for training.
• Settings default to allowing use of editor code snippets for “product improvements”; some are uneasy even with opt‑out, citing policy changes and vague language.
• Strong objections to:
  • Training on public code without explicit consent.
  • Terms that forbid using Copilot outputs to train competing AI systems.
• Some developers have left GitHub entirely or moved to “no AI” forges and self‑hosting.

Local & Open Models

• Active interest in local or BYO‑API setups: Continue + Ollama, Tabby, Cody+Ollama, Qwen2.5‑Coder, StarCoder, Llama, Gemma, etc.
• Debate over tradeoffs:
  • Local models: more control and privacy, but slower, require hardware, often weaker than state‑of‑the‑art cloud models.
  • Cloud SOTA (Claude, GPT‑4/4o, Sonnet): better quality and large‑scale edits, but proprietary and metered.

Impact on Work, Quality, and Jobs

• Some report huge productivity gains (rapid test generation, boilerplate, sweeping UI or config changes).
• Others find AI‑heavy codebases chaotic: inconsistent style, duplicated patterns, subtle bugs, and dependence on agents for any nontrivial change.
• Broader skepticism: AI may accelerate sloppier software, erode skills, displace workers, and concentrate power and knowledge inside a few vendors.

Market & Strategy Views

• Several see Microsoft’s move as classic “embrace, extend, extinguish”: bundling Copilot with GitHub/VS Code to starve startups.
• Others predict eventual price hikes once dominance is secured.
• Some believe AI tooling is overhyped, unprofitable at current costs, and may see a correction when returns and maintenance burdens become clearer.

Battery life, chemistry, and the “10‑year” claim

• Some argue “that’s not how batteries work” and expect real life closer to 2–3 years.
• Others cite Energizer Ultimate Lithium AA datasheets (≈25‑year shelf life, ~3,500 mAh) and low self‑discharge to say 10 years is plausible when replacing a ~200 mAh CR2032.
• Lithium primaries are highlighted as far more leak‑resistant than alkalines and widely used in “10‑year” smoke alarms.
• Concern: AA cells or contacts might age or leak before 10 years, especially if people ignore the “use lithium” guidance and install cheap alkalines.

Size, use cases, and UX trade‑offs

• Many find the enclosure too big for keys, wallets, pets; better suited to luggage, camera bags, tools, RVs, boats, storage units, etc.
• Some say annual CR2032 replacement is trivial, especially with Find My low‑battery alerts; others complain of “battery fatigue” when managing many tags and other sensors.
• A recurring theme: “set it and forget it” is valuable for rarely accessed or hard‑to‑reach locations (hidden in cars, trailers, cases, time capsules).

AirTag protocol longevity and Apple obsolescence

• Skeptics doubt AirTags and protocols will be fully supported in 10 years, citing Apple’s history of deprecating ports (FireWire, etc.).
• Others argue Apple tends to support accessories for a long time, that AirTags ride on the broader Find My ecosystem, and that cutting off v1 entirely would anger customers heavily invested in tags.

Theft tracking vs. loss prevention and stalking concerns

• Strong debate over whether AirTags are useful for anti‑theft:
  • Pro: Numerous anecdotes of recovering bikes, cars, luggage, and cameras by tracking tags, often involving police assistance. Hidden placements and disabling the speaker can make removal hard.
  • Con: Anti‑stalking features (iPhone/Android alerts, chirping) and ease of physical removal make them unreliable against determined thieves; they’re designed primarily for “lost,” not adversarial scenarios.
• Some worry longer life + waterproof, muffling enclosures could aid stalkers; others call this overblown given existing ways to hide tags and system‑level anti‑tracking alerts.

Reliability, software, and hardware aging

• A few question whether AirTag firmware or protocol assumptions (e.g., key rotation, watchdog behavior, memory leaks) were designed for 10× expected battery life; others note watchdogs and constrained RAM would expose most bugs well before a year.
• Disagreement over whether other components (sensors, capacitors) or software aging make 10‑year expectations unrealistic; some cite decades‑old electronics still working fine.

Alternatives, DIY, and adjacent products

• Multiple DIY suggestions: CR2032‑to‑AA adapters, 3D‑printed housings, OpenHaystack‑based NRF52 beacons with AA packs, and cheap Chinese enclosures.
• Comparisons to cellular/NB‑IoT asset trackers: more expensive and subscription‑based but better for theft, since they lack anti‑stalking constraints.
• Some prefer rechargeable or different form‑factor trackers (credit‑card shapes, bike‑integrated mounts) over a bulky AA pack.

Why Meta Migrated Java → Kotlin

• Many agree Meta can justify large one‑time investments for modest gains in safety/productivity at their scale.
• Kotlin is now the de facto Android language; staying on Java is seen as “legacy” and hurts hiring and developer satisfaction.
• Null‑safety in core frameworks is viewed as critical when 1B+ Android users are affected; even a rare NPE can cost millions.
• Several argue that partial migration (Java + Kotlin) leaves “nullability chaos”; going all‑in reduces mixed‑language friction.

---

Perceived Advantages of Kotlin Over Java

• Less verbosity: data classes, top‑level functions, expression bodies, properties, default immutability.
• Built‑in null safety without annotations/tooling; nullable vs non‑nullable types enforced by the compiler.
• Stronger type system: better generics, function types, declaration‑site variance, type aliases, contracts.
• Language features not easily matched by Java + tools:
  • Extension functions and delegated properties.
  • Sealed classes, exhaustive when, pattern‑matching‑like constructs.
  • Coroutines for async / generators; keyword arguments; interface delegation.
  • Powerful DSL support (scope functions, lambdas with receivers, infix/operators).
• Multiplatform story (JVM, JS, native, WASM) lets orgs share models/logic across platforms.

---

Critiques of Kotlin and Counterpoints

• Some dislike loss of checked exceptions; see unchecked‑only flow as worse, even with Result.
• Others argue checked exceptions in Java are painful and top‑level handlers + explicit unwraps are enough.
• Concerns about:
  • Coroutines vs preemptive lightweight threads; function coloring and ecosystem lock‑in.
  • Lambda/DSL style making code hard to read; “every library its own mini‑DSL”.
  • Extension functions scattering behavior across files; harder to see where methods come from.
  • Tooling lock‑in to JetBrains IDE; weaker LSP support than Java.
• Some see Kotlin as only “marginally better” given modern Java (records, lambdas, Optional, pattern matching, Loom, Valhalla), plus strong Java tooling and static analyzers.
• Others insist Kotlin is vastly better because Java can’t undo legacy choices (null‑by‑default, mutability, openness).

---

Android, Ecosystem, and Oracle

• Android is Kotlin‑first; some newer libraries (e.g., Jetpack Compose) are Kotlin‑only or Kotlin‑centric.
• Using modern Java on Android can be awkward (desugaring, limited standard library); Kotlin sidesteps this.
• Several tie Kotlin and Go’s rise partly to unease with Oracle’s stewardship of Java, though others note Kotlin still rides the JVM.

---

Process, Automation, and AI

• Meta built an automated pipeline around JetBrains’ Java‑to‑Kotlin (J2K) converter.
• Deterministic, correctness‑preserving transforms are preferred over LLMs, which can silently produce wrong but compiling code.
• Some worry about lost git blame granularity; others note careful file moves can preserve history, but per‑line history still gets noisy.

Approach to reducing nitpicks (embeddings & KNN)

• Many commenters find the final solution (embedding comments and doing KNN-style similarity filtering) plausible, even if “hacky.”
• Some note this is effectively a simple classifier; suggest trying other ML models (random forest, XGBoost, small neural nets) on top of embeddings.
• Idea of a “universal nit” via averaging embeddings across customers is proposed; authors say they’ll try it and already combine upvoted/downvoted sets to reduce false positives.
• Concern raised that clustering might incorrectly suppress comments about specific modules/classes if many prior comments there were downvoted.

Prompting vs post-hoc filtering

• Several argue the problem “should” be solvable via better prompting, including:
  • Clearer definitions instead of “nits” (e.g., “stylistic/pedantic/trivial comments”).
  • Explicit severity labels at the end of responses.
  • Chain-of-thought plus tagging nitpicks for removal in a second pass.
• Others report similar experiments with severity scores and LLM-as-judge that still misclassified important issues as nitpicks.
• Discussion of known failure modes: action bias, long-context confusion, ambiguous wording, conflicting instructions.

What counts as a nitpick?

• Strong disagreement on whether the article’s example is actually a nitpick; some see it as important for long-term maintainability.
• Many emphasize that nitpickiness is context- and company-dependent, and even the same comment can be trivial in one PR and crucial in another.
• Some suspect ego or “ship fast” culture may drive pressure to label valid criticism as nitpicking.

Usefulness of AI code review bots

• Mixed views:
  • Supporters see value as a first-pass “extra pair of eyes” that catches style, duplication, and obvious problems before human review.
  • Critics report high noise, hallucinated issues, and little real benefit compared to linters and human review; fear juniors over-trusting AI feedback.
  • Several argue code review is precisely where human judgment, knowledge-sharing, and mentoring are most important.

Linters, alternatives, and metrics

• Debate whether AI review adds more than well-tuned linters/formatters; proponents point to more nuanced, context-aware rules.
• Others say overly complex rules are themselves the problem.
• Metric choice criticized: “percentage of comments addressed” may reward leaving fewer comments; suggestions include normalizing by files or lines changed.

Pricing & incentives

• Some see the quoted per-file/per-dev pricing as expensive, especially for lower-wage markets or cash-strapped orgs; others note it’s a small fraction of developer salary.
• Commenters highlight that LLMs being billed per token may bias toward verbosity, though competition and user instructions can push toward concision.

HTTP status codes and API semantics

• Debate over whether HTTP status codes are good design for app-level errors.
• Some argue app-specific error payloads should dominate, with HTTP codes only indicating transport-level success/failure.
• Others insist layered design makes sense: HTTP handles resource/transport status (e.g., 404, 429), app errors go in the body.
• Disagreement over using 404 for “resource not found in DB” vs “endpoint doesn’t exist”; some see both as 404, others prefer 200 with an empty/“no results” payload.

Feed reader behavior & conditional requests

• Central complaint: many RSS/Atom readers poll too frequently with unconditional GETs of large feeds.
• Proper behavior cited: send If-Modified-Since / If-None-Match and respect 304 Not Modified.
• Some readers do this correctly; others hammer feeds every few minutes and ignore caching semantics, effectively wasting bandwidth.

Aggressive rate limiting and 429 responses

• The blog in question returns 429 and advises a 24‑hour retry for clients that repeatedly fetch unconditionally.
• Supporters: servers owe clients neither unlimited requests nor special treatment; 429 + Retry-After is a clear signal, and misbehaving clients should fix caching.
• Critics: blocking after 2 hits in 20 minutes for a 500KB RSS feed is “hostile” and punishes end users, especially behind shared IPs or when testing new readers.
• Semantic dispute over whether 429 is “rate limiting” vs “blocking,” but practical effect is the same: no content during the window.

Bandwidth, feed design, and caching

• The feed contains 100 full posts (500KB). Some say that’s excessive and should be trimmed (e.g., fewer items, summaries only).
• Others defend full-content, long-history feeds; the real waste is clients re-downloading unchanged content instead of using conditional requests.
• Examples given where individual readers account for noticeable percentages of a site’s yearly egress.

Bots, LLM scrapers, and infrastructure

• Several report big increases in bot and LLM-related traffic, often ignoring robots.txt and faking user agents.
• Approaches mentioned: blocking datacenter IPs, “bot motels” (trapping crawlers in junk content), poisoning indexes.
• Some suggest CDNs, WebSub/pubsubhubbub, or third-party hubs to offload polling; others resist CDNs as corrosive to an open, independently hosted web.

Miscellaneous tangents

• Grammar digression on “which” vs “that.”
• Reflections on falling traffic for small sites, search downranking, paywalls, and monopoly/antitrust politics.

Nature of the work and PTSD

• Many describe Facebook-style moderation as “absolutely grim” and uniquely corrosive: constant exposure to murders, suicides, child sexual abuse, torture, war gore, etc., for 8–10 hours a day.
• Commenters stress that occasional exposure to brutality (accidents, illness, a few violent videos) is not comparable to “mainlining” it full-time.
• Some note that people often think they can “handle it” until cumulative exposure triggers PTSD or other lasting effects.

Comparison to other traumatic jobs

• Moderation is compared to paramedics, ER staff, police, soldiers, suicide hotlines, and CSAM investigators.
• Key differences cited:
  • Volume and density of disturbing material are much higher.
  • Moderators are powerless to help victims, unlike first responders.
  • Often minimal support, low pay, and outsourced contractor status.
• Others argue many professions carry trauma and that susceptibility varies widely between individuals.

AI, automation, and technical fixes

• Strong support for using AI to reduce human exposure, especially for “obvious” repeats via hashing or classifiers.
• Counterpoints:
  • AI can’t fully replace humans; new and borderline content still needs human labeling.
  • Moving the problem to dataset curators just shifts the trauma.
  • Concerns about over-censorship, lack of appeals, and corporate incentives to remove staff once AI is “good enough.”
• Debate over on-device vs server-side scanning for CSAM, and the civil-liberties risks of scanning users’ private devices.

Centralization, incentives, and platform design

• Several argue giant centralized platforms inherently concentrate the worst content and create industrial-scale trauma; more federated or self-hosted models might limit spread and scale.
• Others note federation (e.g., Mastodon) also has moderation whack-a-mole problems and can harbor abusive instances.
• Many blame engagement algorithms rather than mere hosting; calls for simple chronological feeds and less growth/engagement pressure.

Compensation, exploitation, and equity

• Dispute over paying Kenyan moderators a fraction of US rates:
  • One side calls it straightforward exploitation enabled by borders and local labor markets.
  • Another says “local market rate” is normal and workers chose these jobs over alternatives.
• Some suggest hazard pay, strict exposure limits, mandatory psychological support, and time-limited rotations; others question whether such work should exist at all at current scale.

Security concerns vs. geopolitics

• Many see the move as partly justified: routers are critical choke points, TP-Link has a long vulnerability history, and Chinese state leverage over companies is viewed as a serious risk (botnets, infrastructure attacks, backdoors, coerced updates).
• Others argue the focus is selective and political: all major router vendors have poor security track records, US/Western agencies also tamper with networking gear, and the US is not applying the same standard to domestic or allied companies.
• Some say if the US were serious, it would enforce uniform security/privacy rules (including data-broker bans and anti‑“cloud lock‑in”) rather than targeting specific Chinese brands.
• There’s debate over whether this is legitimate security hardening or protectionism to preserve US tech dominance and raise prices.

Router firmware, updates, and responsibility

• Widespread consensus that consumer router firmware is generally bad: slow or nonexistent updates, many CVEs, insecure defaults, cloud dependence, and short support lifetimes.
• TP-Link is called out for especially poor patching and update discipline; some suggest bans or tariffs should target insecure products regardless of country.
• Proposals: regulators scan ISP address space for vulnerable routers, require ISPs to pressure/suspend customers until patched, and force vendors to allow third‑party firmware (OpenWRT/DD‑WRT) and not sell near‑EOL devices as “new”.
• Some highlight that even “open” router stacks still rely on closed Wi‑Fi firmware blobs from chipset vendors.

Alternatives, brands, and architectures

• Popular alternatives mentioned: Ubiquiti/UniFi, Mikrotik, Aruba Instant On, Ruckus (often off‑lease), GL.iNet, Protectli + pfSense/OPNsense, OpenWRT One, generic mini‑PCs as routers, and separate APs.
• Experiences with TP-Link are mixed: some praise price/performance and reliability; others report instability, poor mesh behavior, forced registration, and dark patterns.
• Several recommend a “router-as-PC + APs” approach for better control and longevity, but acknowledge complexity for non‑experts.

Home networking & IoT design debates

• Strong thread arguing for:
  • Client isolation via VLANs or AP‑level mechanisms.
  • Default denial of Internet access for IoT, with local brokers (e.g., MQTT) mediating behavior.
  • APs evolving into trusted, frequently updated “edge platforms”.
• Counterpoints: whitelisting Internet domains is hard at scale; vendors want cloud lock‑in; most users can’t manage VLANs; and “client isolation vs. easy casting/streaming” is a real usability trade‑off.

LLM–LLM Conversations and “Cooperation”

• People report running models against each other (e.g., via local tools) and observing endless polite “goodbye” exchanges.
• Many argue this is just next-token prediction over human-style data, not genuine cooperation or cultural evolution.
• Some note that models are usually forced by the surrounding code to always reply; they lack a true “end of conversation” state.

End-of-Conversation and Agent Framing

• Suggestions: introduce explicit “[silence]” or “[end-conversation]” tokens, or treat “end chat” as a tool the model can call.
• Others counter that models are optimized to always respond and don’t “decide to obey”; they just continue the script.
• A popular framing: LLM interactions are like movie scripts where a writer extends text containing fictional agents; “cooperation” is a property of the story, not the underlying program.

Mimicry, Reasoning, and Consciousness

• One side: LLMs just mimic patterns; there’s no new culture unless they create their own slang or styles, not found in training data.
• Counterpoint: humans also learn from examples; cultural evolution only appears in larger interacting populations.
• Debate extends to whether LLMs “reason” or could be conscious, with comparisons to ordinary software and even rocks or chemical reactions. No consensus is reached.

Security, Prompt Injection, and Token Trust

• Prompt-injection is framed as hard because the model sees one undifferentiated text stream.
• Proposed fix: “colored” tokens (trusted vs untrusted) or stronger treatment of system messages.
• Critics note annotation and conceptual complexity, arguing we should mostly reuse standard security principles (least privilege, user prompts, defense in depth).

Paper’s Methodology and Claims

• Several see the work as interesting for game-theoretic / evolutionary analysis (e.g., Donor Game and indirect reciprocity).
• Skeptics say parameter choices are arbitrary; results may be artifacts of the setup or output style (more detailed vs vague strategies) rather than deep training biases.
• Concerns about weak ablation/sensitivity analysis and overreaching language around “cultural evolution” and “falsifying” broad claims about LLM cooperation.

LLMs as Experimental Agents

• Some are excited about using LLM agents for large-scale social or game-theoretic simulations, potentially aiding sociology and theory-of-mind research.
• Others caution that cultural effects in LLMs are transient (lost once context is gone), so “evolution” may be very different from human culture.

Overview of the new H‑1B rules

• Thread participants say the changes include:
  • Beneficiary‑centric lottery (one person, one draw; passport required).
  • Easier job changes: can start work upon petition filing rather than waiting for approval.
  • Extended “cap‑gap” so F‑1 students keep work authorization longer while transitioning to H‑1B.
  • Founders can self‑petition if they effectively control the company.
  • More roles tied to research institutions are cap‑exempt, including some startup research hires.
  • Clarified “specialty occupation” rules, especially for interdisciplinary AI roles.
  • Stronger fraud checks, mandatory site visits, and “bona fide job offer” requirements.

---

Green cards, dual intent, and backlogs

• Several comments stress H‑1B is explicitly a dual‑intent visa; using it as a step toward a green card is legal.
• Long green‑card queues (especially for Indians and Chinese) are described as “decades long,” creating de‑facto semi‑permanent H‑1B status and strong employer leverage.
• Per‑country caps are heavily criticized as arbitrary and discriminatory; defenders say they preserve diversity.
• Some want caps eliminated or a single global queue; others argue caps prevent single‑country dominance.

---

Labor markets, wages, and abuse

• One camp says there is no real shortage of US tech talent; H‑1B is framed as wage‑suppression and “indentured servitude” via deportation risk.
• Others counter that:
  • H‑1Bs often earn similar or higher total comp at big tech firms.
  • The main abusers are offshore “body shops” and IT consultancies, not core product companies.
• Reported abuses:
  • Multiple sham entities submitting registrations for one person.
  • Fake offices, ghost jobs, and PERM ads placed where no US worker will realistically see them.
  • Underpayment via misclassified roles or low prevailing‑wage levels.
• Proposed fixes from commenters: high H‑1B wage floors (e.g., 90th percentile), auctioning visas, or heavy per‑visa fees to ensure only truly scarce hires are sponsored.

---

Startups, founders, and self‑petition

• New founder‑friendly rules (self‑petition if owning or controlling the company) spark debate:
  • Some fear shell LLCs purely to obtain visas.
  • Others note you must still meet prevailing‑wage and job‑reality tests, and argue this is good if you can genuinely fund your own salary.

---

National competitiveness vs. citizen protection

• Pro‑H‑1B side: US tech dominance, “brain drain” of other countries, and net economic growth depend on attracting top global talent; restricting this pushes work and offices abroad.
• Skeptical side: in a period of large tech layoffs, expanding or easing H‑1B is seen as directly harming US workers and weakening bargaining power.

---

Politics, timing, and social tension

• Some see the timing (late‑term rulemaking) as “regulatory theater” likely to be reversed by the next administration; others reply that rulemaking is inherently slow and has been in the works for years.
• Commenters expect differing futures depending on political control: anything from outright hostility to legal immigration to dramatically expanded H‑1B quotas.
• The thread contains visible tension around race, nationality, and class; several participants explicitly call out xenophobia and racism, while others focus on economic self‑interest and national labor priorities.

Phone calls, trust, and verification

• Many argue any unsolicited call/email demanding urgent action should be treated as hostile; you should hang up and call back via a number you independently look up (“hang up, look up, call back”).
• Others note banks, telcos, and healthcare providers routinely behave like scammers (calling from unknown numbers, asking for SSN/DOB, sending links), which normalizes risky patterns.
• Disagreement on how often banks legitimately block or freeze accounts after customers refuse to cooperate on such calls; some say it happens, others are skeptical.
• STIR/SHAKEN and carrier “scam likely” flags help somewhat, but caller ID can still be spoofed; SS7-level attacks and network compromises are mentioned as deeper risks.

Google Authenticator, cloud sync, and 2FA philosophy

• Strong criticism of Google Authenticator’s cloud backup: once TOTP seeds are in Google’s account backend, compromising Google yields all codes.
• Some report bugs where disabling sync corrupted codes; others confirm you can turn off sync but debate whether Google truly deletes seeds.
• Broader debate: backing up/syncing TOTP undermines “something you have,” turning 2FA into “phishing with extra steps,” but without it many users lose access and support becomes impossible.
• Alternatives discussed: other authenticator apps, password managers with TOTP, hardware tokens (WebAuthn/FIDO2, YubiKeys), and their usability vs. security tradeoffs.

Crypto custody and irreversibility

• Thread emphasizes that crypto’s irreversibility and lack of institutional recourse make these scams uniquely destructive compared to bank accounts.
• Storing seed phrases in cloud photos or screenshots is widely condemned; suggestions include offline physical storage, hardware wallets, multisig, and separating “hot” vs. “cold” wallets.
• Counterpoint: robust self-custody procedures (titanium plates, safes, multisig, inheritance planning) are complex and fragile for ordinary users; losing or damaging physical backups is also a risk.
• Several see crypto as effectively “speedrunning” why financial regulations and chargebacks exist; others argue banks and cash are still dominant tools for money laundering.

Google support, impersonation, and UX issues

• Many find it inherently implausible that “Google support” would proactively call a free-user, which itself is a useful red flag.
• Complaints about big-tech customer service: opaque processes, reliance on volunteer “product experts,” and lack of reliable, human recovery channels.
• Some suggest Google and similar firms should publish definitive “we never call you about X” messaging and SEO it, or simply provide real, paid support.

Prompts, MFA bombing, and security UX

• Concern that Google’s one-tap “Yes/No” device prompts are too easy to fat‑finger or approve under pressure; this enables MFA bombing.
• Comparison to systems that require entering or matching a code on the second device, which are slightly slower but more resistant to social engineering and accidents.

DMCA and abuse

• Example raised where a scammer allegedly used a bogus copyright claim to get an incriminating recording removed, illustrating how DMCA-style systems can be abused to erase evidence.

Aesthetic reactions to Boston City Hall

• Many commenters call the building “hideous,” “dystopian,” and intimidating, describing its message as “we will crush you.”
• Some see it as humorous or “absurdist,” like an elephant ballerina or a Quake level, and enjoy it as an extreme, memorable object compared to bland glass boxes.
• A smaller group argues it is beautiful or at least visually striking, especially in photos without the plaza, and appreciate it as a bold, expressive work of brutalism.
• Several say it feels like totalitarian or military architecture, evoking torture chambers, machine-gun nests, or civil defense bunkers.

Functionality and user experience

• Critics describe the interior as dark, confusing, soul-sucking, and uncomfortable (wild temperature swings, awkward columns, poor accessibility).
• Others say it is easy to navigate, has good light and air, and offers many gathering spaces inside and out, especially compared to the cramped, inaccessible old City Hall.
• Some argue the building serves its large-plaza role for protests, concerts, and TV events, even if unpleasant day-to-day.

Plaza, climate, and urban context

• The brick plaza is widely disliked as an empty, windy, winter “wasteland” and missed opportunity in an otherwise lively area full of shops and alleys.
• The recent (2022) renovation is seen as an improvement—playground, more activation—but many still find it harsh in cold months and underused for commerce.
• Several regret the demolition of Scollay Square and other neighborhoods for Government Center, seeing it as emblematic of damaging mid‑century urban renewal.

Materials, aging, and construction quality

• Commenters discuss post‑WWII shifts: loss of skilled labor, preference for cheap concrete and glass, and reduced use of durable brick or wood.
• There is concern that exposed concrete ages poorly in Boston’s polluted, salty, humid climate and may deteriorate faster than older stone or brick buildings; sealants or stucco are proposed but clash with brutalist aesthetics.

Architecture, taste, and ideology

• Debate over whether beauty is subjective vs. some forms (e.g., Gothic, classical) having near‑universal appeal.
• Some blame modern architects and clients for prioritizing “bold statements” and personal ego over usability and public preferences.
• Others defend challenging styles as legitimate art, arguing that public incomprehension does not alone make a design bad.