DEV Community: Mauro Damian Perez Garcia

The Browser Is Filling With Synthetic Fog

Mauro Damian Perez Garcia — Thu, 20 Aug 2026 13:32:50 +0000

"Browser de-slop" is a phrase I did not expect to need, which usually means the problem has already become ambient.

Open a page. Skim. Feel the slight nausea of text that is fluent, generic, and uncommitted. Image carousels that look like memory but point to nothing lived. Layouts that are complete without being considered. The tab title promised a human answer. The body delivered a probabilistic average of answers.

I am not pure about this. I use models every day. I also want the open web to remain a place where attention is spent on work that someone stood behind.

Slop is not "AI exists." Slop is unowned fluency.

The distinction matters.

A carefully edited essay that began as a draft with an assistant can still be human work. A product changelog written with help can still be responsible. The failure mode is publishing without judgment: pages that exist because empty surfaces are bad for ads, SEO, or the appearance of momentum.

Browsers sit at the worst seat in the house. They are the aggregation layer for everyone else's incentives. When content farms, marketplace listings, and mediocre docs sites all optimize for the same fluency, the browser becomes a fog machine.

Users respond with coping strategies. Aggressive blockers. Reader modes. "site:" queries. Trust circles. Ignoring the first page of results. That is rational. It is also a tax on curiosity.

What I want tools to do about it

I do not want a browser that moralizes. I want one that helps me allocate attention.

Useful directions look like:

stronger reader views that strip decorative mush,
clearer signals for authored versus generated-looking bulk,
better controls for autoplay, trackers, and script-heavy scaffolding,
and user-side preferences that favor sources I already trust without locking me into a garden.

Some of this will be imperfect heuristics. Fine. We already accept imperfect spam filtering. The alternative is pretending every HTTP 200 is equally worth my evening.

There is a parallel to ad blocking. For years, people said the "right" answer was better ads. Users chose survival tools instead. Synthetic fog may force a similar pragmatic turn.

Creators have a job here too

If you publish, the way out is not a purity contest. It is accountability.

Put a name on the work. Include the constraint that only you know. Cut the paragraphs that could have been written about any company. Show the scar: the benchmark, the failure, the weird edge case, the decision you regret.

Models are good at the smooth middle. Humans are still better at the awkward specific.

The web gets healthier when the awkward specific remains economically and socially rewarded. That reward is partly algorithmic and partly cultural. Culture is the part we can still choose in public.

My working stance

I will keep using AI. I will keep reading strangers on the internet. I will also keep raising my bar for what deserves a full-attention read.

If a page cannot survive a one-sentence summary that includes a concrete claim, I bounce sooner than I used to. That sounds harsh. It is self-defense.

The browser used to feel like a library with noisy halls. Lately it feels like a hallway where every poster was printed by the same overconfident machine.

De-slop, to me, is not nostalgia for 2007. It is a demand that tools and norms help humans find the pages that still contain a person.

I want my browser to be an instrument again, not a fog machine with a search bar.

Attention is the scarce input. Anything that conserves it is infrastructure.

Radians Are Correct; Turns Are Kind

Mauro Damian Perez Garcia — Thu, 20 Aug 2026 13:32:15 +0000

Every so often a mathy essay climbs the ladder by saying something that feels almost too obvious once said out loud: humans think in whole rotations more naturally than they think in π.

Turns versus radians is one of those fights that looks pedantic until you have debugged a graphics bug at midnight and watched two coordinate systems disagree by a factor nobody can feel in their bones.

Radians are elegant for calculus and physics derivations. They are the correct internal language for a lot of mathematics. That does not automatically make them the kindest default for APIs that humans configure, animate, or reason about under pressure.

Correctness and kindness are different layers

Software keeps confusing these layers.

Floating point is "correct" in IEEE ways and still mean to newcomers. Time zones are "correct" as civil abstractions and still eat production. Regex is "correct" as a tiny language and still creates unreadable policy engines.

Radians sit in that family for spatial and periodic quantities. They compress beautiful identities. They also hide the simple idea of "halfway around" behind 3.14159-something and a prayer that everyone used the same constant.

Turns make fractions obvious. Half a turn. A quarter turn. One turn. Your eye can audit the number. Your code review can catch "wait, did we mean half or tau/2?" before it ships.

I am not arguing that math libraries throw away radians. I am arguing that product interfaces and domain APIs should choose representations that match the mental model of the caller.

Defaults are pedagogy

An API default teaches.

If your animation library asks for radians, you teach a tiny tax to every designer-adjacent engineer. If your shader helpers assume degrees in one place and radians in another, you teach despair. If your config file wants turns, you teach a model people can check without a calculator.

The best systems I have used are bilingual: precise internal forms, humane external forms, and explicit conversions at the boundary. The worst systems pretend one representation is morally superior and then leave conversion bugs as a rite of passage.

Units are part of UX. Engineers forget that because we live inside the units until they feel like air.

A practical rule I use

When I design an interface that accepts angles, periods, or normalized cycles, I ask:

Will a tired human eyeball this value in a JSON file?
Can a tester express expected results as simple fractions?
Are we optimizing for derivation beauty or for operational clarity?

If operational clarity wins, I expose turns or degrees at the edges and keep radians inside the math kernel. If the audience is numerical methods researchers, I do the opposite and document it loudly.

The mistake is mixing audiences without saying so.

Why this tiny debate keeps mattering

Because software is filling up with similar mismatches.

We store money as floats because math class said real numbers. We expose UTC everywhere and then surprise people with local civil time. We make agents speak probability to executives who hear confidence. We choose representations for the implementer and call the caller inexperienced when they stumble.

Turns versus radians is a friendly microcosm of that arrogance.

I like mathematics. I also like software that respects the nervous system of the person holding the pager.

If a representation is correct in theory and hostile in practice, it is incomplete as an interface choice.

Prefer kindness at the boundary. Keep purity where it earns its keep. Convert deliberately. Name the unit in the type or the field. And when someone proposes a "simpler" default that matches how people count whole things, listen longer than your reflexes want to.

Sometimes the advanced move is admitting that 0.5 turns is clearer than a shrine to π.

A Locked Cutter Is How Ownership Quietly Dies

Mauro Damian Perez Garcia — Thu, 20 Aug 2026 13:32:02 +0000

There is a particular anger that shows up when someone buys a machine, the vendor cloud shrugs, and the physical object becomes e-waste while still mechanically fine.

Unlocking a deactivated Cricut Maker sits in that genre. Craft hardware. Creative tools. A device that should have been scissors with a motor. Instead it is a subscription to permission.

I care about this beyond hobby cutters. The same pattern is spreading through routers, printers, tractors, medical accessories, and home batteries. Purchase becomes a revocable license. Repair becomes a gray art. Secondary markets get poisoned because buyers cannot know whether the object will still obey them next year.

The product promise and the control plane diverge

Hardware marketing still sells permanence. Buy this. Own this. Make things in your house.

Then the control plane ships elsewhere. Activation servers. Account binding. Firmware that phones home. Features gated on cloud moods. When the vendor changes strategy, your bench tool inherits the strategy.

Engineers understand why companies do it. Fraud. Consumables revenue. Support boundaries. IP theater. Ecosystem lock-in dressed as "experience."

Users understand something simpler: a machine that refuses to run without a remote blessing is not fully theirs.

Those two understandings are now in open conflict.

E-waste is an engineering outcome

We talk about sustainability as materials science and recycling policy. Fine. Also look at software decisions that brick working devices.

A locked cutter in a closet is not abstract. It is metal, electronics, packaging, shipping carbon, and a person who now needs another unit. Multiply that by product categories and you get a quiet industrial leak. Not a headline oil spill. A thousand small discards justified by terms of service.

Right-to-repair fights often sound legalistic because they have to. Underneath them is an engineering ethics question: should physical usefulness be separable from vendor continuity?

I think yes. Not because vendors owe eternal free cloud services. Because basic local function should degrade gracefully when accounts die, startups pivot, or regions lose support.

What good ownership looks like in practice

I do not need every device to be fully open. I do need a minimum bar:

core function works offline after legitimate purchase,
repair documentation exists for wear parts,
account deletion does not corpse the hardware,
security updates are separable from engagement metrics,
and secondary buyers can reset and use the device without a morality play.

If a business model cannot survive that bar, it may be a rental business pretending to be retail. Rentals are fine when labeled. The dark pattern is selling "yours" while retaining a kill switch.

Why hackers keep unlocking things

People reverse these systems for the same reason they always have: the object is right there, the restriction feels illegitimate, and competence is a form of dignity.

I am glad that competence exists. I wish it were less necessary.

Every unlock writeup is both a celebration of curiosity and an indictment of design. Celebrate the curiosity. Fix the design.

If you build devices, ask an ugly question early: what happens to this product when our company is gone, bored, or acquired by someone who hates the legacy SKU?

If the honest answer is "it becomes sculpture," you did not ship a tool. You shipped a timed souvenir.

I have started applying that question to my own side projects when they touch hardware or local-only workflows. If a feature requires my personal server to stay alive forever, it is not a feature. It is a future apology. Shipping a local fallback is less glamorous than a cloud dashboard. It is also how you respect the person who trusted you with money and shelf space.

Ownership should be dull. You paid. It works. You can maintain it. The cloud can add delight without holding the motor hostage.

Anything less and we are just decorating landfills with DRM.

Postgres as a Default Is a Discipline

Mauro Damian Perez Garcia — Thu, 20 Aug 2026 13:31:28 +0000

Every few months someone writes a clean, slightly stubborn essay that amounts to: what if we just used PostgreSQL for more of the architecture?

Queues. Documents. Full text. Geospatial. Analytics adjacent to the app. Job state. Feature flags. The comment section then splits into two camps: people who have been burned by polyglot sprawl, and people who have been burned by one database asked to do circus tricks.

I land closer to the first camp, with scars from both.

The real cost was never the second database

The second database looks cheap on a whiteboard. It is "just Redis." It is "just Elasticsearch." It is "just another managed service with a cute dashboard."

The cost arrives later as operational fan-out. Separate backup stories. Separate failure modes. Separate auth models. Separate local-dev myths. Separate "who understands this at 2 a.m." lists. Separate schema migrations that drift out of sync with the system of record.

If your company is large enough, that sprawl can be rational. Specialization wins at scale. If your company is still finding product shape, every new datastore is a bet that you already know your access patterns and staffing model. That bet is often wrong.

Postgres as a default is not romance about SQL. It is a forcing function: make the data model honest before you multiply the moving parts.

What "for everything" should actually mean

It should not mean stuffing every workload into one process until the vacuum settings become folklore.

It should mean:

prefer one transactional core until a measured pain appears,
use extensions and proven patterns before new infrastructure,
keep derived systems explicitly derived,
and treat specialized stores as exits you earn, not toys you collect.

I have watched teams adopt a queue because a table felt unfashionable. Then they spent months recreating transactional outbox semantics they already had. I have also watched teams insist on Postgres for a search workload that genuinely needed a purpose-built engine. Dogma is bidirectional.

The discipline is evidence. Latency histograms. Lock contention. Operational toil. Not vibes from a conference hallway.

Where Postgres earns the center of gravity

For product applications with relational truth, rich constraints, and humans who need to debug with SQL, Postgres remains an unusually good gravity well. Foreign keys are documentation that runs. Transactions collapse classes of distributed regret. The ecosystem is mature in the ways that matter when money and identity are involved.

If I can keep user state, billing-adjacent records, and workflow status in one place with clear invariants, I sleep better. Caching can sit in front. Search can sit beside. Streams can fan out. The core stays boring and queryable.

That architecture is less impressive in diagrams. It is more impressive in incident reviews.

A personal rule of thumb

I ask one question before adding a new store: what failure becomes easier, and what failure becomes harder?

If the new system makes one happy-path metric prettier while making consistency and recovery harder, I wait. If it removes a real, measured ceiling that Postgres cannot reasonably clear, I adopt it without guilt.

"Postgres for everything" is a slogan. Useful slogans are really about sequencing. Start centered. Specialize on purpose. Keep the system of record boring enough that the product can be interesting.

There is also a cultural benefit I do not want to underweight. Shared SQL literacy is one of the last cross-role languages left in many companies. Support can inspect rows. Analysts can validate a metric. Engineers can reproduce a bug without learning a fifth vendor dialect. When every concern gets its own store, that shared literacy fragments into guild knowledge.

I do not need every team to worship one database. I need more teams to stop confusing optionality with progress.

The best stack is often the one your future teammate can still explain with a whiteboard marker and a straight face.

Go Releases Are Boring on Purpose

Mauro Damian Perez Garcia — Thu, 20 Aug 2026 13:31:24 +0000

Go 1.27 landing on the front page always feels a little funny to me. There is rarely a single feature that would make a conference keynote explode. The discussion still shows up, because a lot of us have learned to treat boring language evolution as a product decision.

I used to chase languages that felt exciting week to week. New syntax candy. New paradigms. New ways to rewrite yesterday's working code. Then I spent enough years shipping systems where the expensive part was not writing the first version. It was keeping a team fluent across releases, dependency bumps, and the quiet tax of "we should probably migrate that."

Go's release cadence, at its best, is an argument against that tax.

Stability is a feature you feel in code review

When a language changes slowly, reviews stay about behavior. Naming. Failure modes. Whether the interface leaks. You spend less time arguing about whether the idiomatic style changed again since last quarter.

That matters more than it sounds. Style churn is not neutral. It creates status contests. People who live in the bleeding edge look "modern." People who keep the old pattern look "behind." Neither signal is strongly correlated with whether the service is reliable on Tuesday morning.

I am not saying Go is finished or perfect. I am saying the culture around compatibility makes a specific kind of engineering easier: long-lived services maintained by rotating humans.

What I actually want from a point release

My checklist is selfish and practical:

keep the standard library unsurprising,
make tooling better without inventing a second religion,
improve compile and runtime behavior in ways I can measure,
and avoid forcing rewrites just to stay current.

If a release also adds something elegant, great. Elegance without migration pressure is the luxury I will pay for with loyalty.

There is a temptation, especially in an industry hypnotized by model releases, to treat every software surface as a stage for novelty. Languages are not models. They are the floorboards. You notice them most when they creak.

The other side of boring

Boring can become complacent. Ecosystems stagnate if they refuse to learn. Generics arrived late and imperfectly. Error handling still starts arguments that will outlive us. The module story had years of pain. Pretending otherwise is fan fiction.

The useful question is not "did Go invent the future this quarter?" It is "did Go reduce accidental complexity for people who already bet on it?"

For many teams, yes. For others, the answer is to choose something else and mean it. The worst outcome is living in a language you resent while refusing to leave because switching costs became a personality.

A builder habit I like

When a mainstream language ships, I skim the notes looking for three classes of change:

things that delete a class of bugs,
things that delete a class of ceremony,
things that create a class of rewrite pressure.

I celebrate the first two. I budget for the third.

That habit has made me calmer about release hype in general. Not every update needs to rearrange my identity as an engineer. Sometimes the win is that Monday still compiles, the race detector still teaches, and the standard library still does the boring network and crypto work without a scavenger hunt.

Go will keep shipping. Some releases will feel thinner than others. I have started treating that thinness as a signal of confidence rather than decline.

The industry has enough drama. A language that mostly refuses to participate is doing a kind of infrastructure kindness. I will take that kindness, even when the HN title is just a version number.

If your stack depends on longevity more than fashion, boring releases are not a letdown. They are the product working.