DEV Community: Mauro Damian Perez Garcia

Most of My Retrieval Problems Were Never About Retrieval

Mauro Damian Perez Garcia — Wed, 26 Aug 2026 12:40:58 +0000

A post arguing that RAG is simpler than people think made the rounds, and I nodded through the whole thing with the specific satisfaction of someone who learned it the expensive way.

If you built a retrieval-augmented system in the last couple of years, you probably did what I did. You compared vector databases. You read about chunking strategies. You tuned the embedding model. You added a reranker. You drew a diagram with six boxes in it and felt like a serious engineer.

Then you shipped it and the answers were mediocre, and almost none of the mediocrity came from the parts you spent your time on.

Where the failures actually came from

For me, in rough order of how much damage they caused:

The documents were bad. Outdated pages sat next to current ones with no way to tell them apart. The same policy existed in three versions across a wiki, a PDF, and a Slack thread. Retrieval worked perfectly and confidently handed the model a document from 2023. No amount of embedding quality fixes a corpus that contradicts itself.

Permissions were an afterthought. The moment a system can surface any document, it can surface the wrong document to the wrong person. Retrieving with the user's own access rights rather than a service account's is not a feature to add later. It is a property of the architecture, and retrofitting it is miserable.

The prompt assembly was sloppy. I had spent weeks on which chunks to retrieve and about ten minutes on how to present them to the model. Whether sources are labeled, whether the model is told what to do when the context does not contain the answer, whether the ordering implies priority — these mattered more than the retrieval nuance.

And I had no way to tell whether a change helped. That one is the real killer.

Evaluation is the whole game

If you take one thing from this: write down thirty real questions with known good answers before you optimize anything.

It does not need to be sophisticated. A spreadsheet is fine. What it gives you is the ability to make a change and know whether it helped, which is the difference between engineering and redecorating. Without it, every tuning decision is a vibe, and you will happily add a reranker that makes things slightly worse while feeling productive.

Thirty questions from actual users beats three hundred synthetic ones, because real questions are weirder. They are ambiguous, they use internal jargon, they assume context, and they ask about things that are genuinely not in your documents. That last category is where most systems embarrass themselves.

The boring baseline is stronger than it looks

The other thing I underrated: plain keyword search, plus metadata filtering, plus a modest amount of context, gets you remarkably far.

Not always. Semantic search genuinely helps when users and documents use different vocabulary, which is common. But keyword matching is precise, debuggable, and instant to explain when someone asks why a particular result showed up. Hybrid approaches win in practice partly because they let you reason about failures.

Metadata filtering may be the most underrated component in the entire stack. Restricting retrieval by date, document type, product area, or team eliminates a whole class of confidently wrong answers, and it costs almost nothing. I have seen a filter on "current version only" improve output more than a model upgrade did.

How I would start over

If I were building this again from zero, I would spend the first week on the corpus, not the code. Find out what documents exist, which are authoritative, what the access rules are, and how stale things get. That work is unglamorous and it determines the ceiling of everything downstream.

Then I would build the dumbest possible pipeline: search, take the top handful of results, put them in a prompt with clear labels and an explicit instruction to say when the answer is not present. Measure it against the question set. Only then start adding machinery, one piece at a time, keeping whatever the numbers justify.

My suspicion is that a lot of teams have complex retrieval systems where a simple one would perform the same, and the complexity persists because nobody can prove which parts are earning their keep.

The pattern is not unique to this technology. When a field is new, we mistake the interesting part for the important part. The interesting part was the vector math. The important part was knowing which document is true.

A Vote About Bots Is Really a Vote About Trust

Mauro Damian Perez Garcia — Wed, 26 Aug 2026 12:40:23 +0000

Debian is polling its developers on how to handle AI-assisted contributions, with options that range from broadly permitting them to banning them outright. Whatever the outcome, I think this is one of the more consequential governance conversations in open source right now, and not for the reason the headlines suggest.

The framing everyone reaches for is philosophical. Is generated code authored? Is it derivative? Does using a model make you less of a contributor? Those are real questions and I do not have confident answers to them.

But if I imagine actually being a Debian maintainer, my problem is not philosophical at all. It is that my queue is full and my reviewing hours are finite.

The bottleneck was never writing code

Volunteer projects have always been constrained by review capacity, not by supply of patches. The scarce resource is someone knowledgeable enough to say "this is correct, this fits our conventions, I will own the consequences if it breaks."

Assistants change the ratio between those two things dramatically. The cost of producing a plausible patch has fallen much faster than the cost of evaluating one. That asymmetry is the whole story. A project can absorb a lot of contributors when each contributor's output is roughly proportional to their understanding. It struggles when someone can submit a large, fluent, superficially reasonable change to a subsystem they have never read.

I want to be careful here: plenty of experienced maintainers use these tools well, and their patches are better for it. The failure mode is not the tool. It is the decoupling of confidence from comprehension.

Why detection is the wrong axis

A ban sounds like a clean answer, and I understand the appeal. But I am skeptical it can be enforced in a way that means anything.

You cannot reliably detect generated code, especially after a human has edited it, and especially for the kind of small idiomatic patch that makes up most of a distribution's traffic. A rule you cannot enforce does not produce compliance. It produces silence: people stop disclosing, which is strictly worse than a norm that encourages honesty.

So the more useful axis is accountability rather than provenance. Not "did a machine help you write this," but "do you understand this well enough to defend it, and are you the one who will be here when it breaks?"

That shifts the question to things a project can actually check. Can the contributor explain why this approach and not the obvious alternative? Did they test it on real hardware or just assert that they did? Is the changelog honest about scope? Have they engaged with review feedback in a way that shows they read the code?

Those signals have always separated good contributors from noisy ones. They just matter more now, because fluency no longer implies effort.

Disclosure as a courtesy, not a confession

I have come around to thinking that disclosure norms are worth having anyway, even though they are unenforceable, because of what they do culturally rather than technically.

If saying "I used an assistant for the boilerplate here, and I verified the parsing logic by hand" is normal and unremarkable, reviewers get useful information about where to focus. If it is treated as an admission of laziness, nobody says it, and reviewers get nothing.

The projects I expect to handle this well are the ones that write down what they want from a contribution rather than what they forbid. Something closer to: you are responsible for every line you submit, you must be able to explain it, large changes need prior discussion, and tests are not optional. None of that mentions AI. All of it addresses the actual risk.

What is really being decided

A distribution like Debian is infrastructure for a staggering amount of the world's computing, maintained largely by people doing it in their spare time. Its trust model is social: humans vouching for humans, over decades, with reputations that took years to build.

The question on the table is not really about tooling policy. It is whether that social fabric can survive a sharp increase in the volume of plausible contributions from people with no accumulated stake in it.

I do not know the answer. I do know that a permit-or-ban vote is a blunt instrument for a problem that is fundamentally about attention and accountability. Whatever the ballot says, the projects that come out healthy will be the ones that got explicit about what a maintainer owes the code and what a contributor owes the maintainer.

That conversation was overdue regardless of the machines.

I Miss Reviewing Changes, Not Branches

Mauro Damian Perez Garcia — Wed, 26 Aug 2026 12:40:17 +0000

Someone posted a tool that brings a Gerrit-style review workflow to GitHub and the other forges, and I felt a small pang of recognition. Not because I want to relitigate which review tool is best, but because it named a frustration I had stopped noticing.

The pull request model quietly conflated two different things: the branch you are working on and the unit of change you want reviewed. For a long time I assumed that was just how code review works. It is not. It is one choice among several, and it has costs we have all agreed to pay without discussing.

The unit of review should be a decision, not a container

In a change-centric workflow, the thing under review is a single logical change. It has an identity that survives rewriting. You can amend it, rebase it, improve it after feedback, and the review conversation stays attached to the change itself rather than to a pile of commits that happen to share a branch name.

The practical consequence is that stacking becomes natural. Change A introduces the interface. Change B implements it. Change C migrates the callers. Each one is small, each one is reviewable in ten minutes, and each one can move forward at its own pace.

In a branch-centric workflow, that same work tends to collapse into one pull request with forty files in it, because splitting it means juggling branches, base branches, and the fun of every rebase invalidating the review below. I have watched excellent engineers batch up a week of work into a single reviewable lump purely because the tooling made the alternative annoying.

We then blame the reviewer for skimming. The reviewer is not the problem. Nobody reads forty files carefully. They read the first three and approve the rest on trust.

What large reviews actually cost

The cost is not just missed bugs, though there are missed bugs.

It is that a large review cannot be honest about intent. When a diff contains a rename, a refactor, a behavior change, and a new feature all at once, no reviewer can tell which lines are load-bearing. The refactor camouflages the risky change. I have shipped bugs this way and I have approved bugs this way, and in both cases the review technically happened.

It is also that a large review makes disagreement expensive. If I object to one design decision inside a big pull request, I am blocking a week of someone's work. So I soften the comment, or I leave it as a "nit," or I say nothing. Small changes make it cheap to disagree, which means disagreement actually surfaces.

And it is that revert becomes a blunt instrument. Reverting a focused change is a five-minute operation. Reverting a mega-branch means untangling four unrelated things at the worst possible moment.

You can get most of this without switching tools

Here is the part I want to be practical about. I am not going to convince an organization to migrate its review infrastructure, and I would not necessarily recommend it.

But most of the benefit comes from habits rather than tooling:

Write commits that each stand alone, so a reviewer can walk them in order and follow the reasoning.
Split mechanical changes from behavioral ones. A rename-only pull request is a gift. It gets approved in a minute and it makes the next diff readable.
Open the interface change before the implementation, so the design conversation happens while it is still cheap.
Use stacked pull requests when the platform supports them, even if the ergonomics are imperfect.
Say in the description what you want reviewed. "The retry logic is the risky part; the rest is plumbing" saves everyone twenty minutes.

None of this requires new software. It requires treating review as a communication problem rather than a gate to pass through.

Where the tools still matter

That said, tooling shapes behavior more than intentions do. If rebasing a stack is painful, people will stop stacking, regardless of what the style guide says. If review comments do not survive a force-push, people will avoid force-pushing and let their history get messy instead.

So I am glad these alternative workflows keep getting built, even when they stay niche. They function as a running argument that the dominant model is a choice. Every time I use one, I come back to the mainstream flow noticing friction I had accepted as weather.

The goal was never to have opinions about Git. It was to make it easy for a colleague to understand one decision at a time, and to disagree with it while disagreeing is still cheap.

What Lowercasing Taught Me About Trusting Strings

Mauro Damian Perez Garcia — Wed, 26 Aug 2026 12:39:43 +0000

Every so often a post reminds me that the most dangerous line of code in a system is the one that looks like it could not possibly be wrong. This week's version: calling .lower() on a string can be a security vulnerability.

If your first reaction is skepticism, mine was too. Lowercasing is the plumbing of programming. We do it to normalize usernames, compare header names, canonicalize domains, and check things against blocklists. It feels like arithmetic.

The problem is that case conversion is not a character-by-character mechanical operation. It is a linguistic one, defined by Unicode, and it has behavior that surprises almost everyone who has not been bitten before.

Case is not symmetric, and not always local

Two examples that break the mental model. Turkish has a dotless i, and correct locale-aware conversion maps between letters differently than English does, which means "the same" string can lowercase into two different results depending on locale settings. And there are characters outside ASCII whose lowercase form is an ASCII character, meaning a string that contains no k at all can become one that does after normalization.

Sit with that second one for a moment, because it is the security-relevant shape. If you validate a string, then normalize it, you have validated something that no longer exists. Your check ran against one value and your system acts on another.

That is the classic time-of-check versus time-of-use bug, except the mutation is not caused by an attacker racing you. It is caused by your own normalization call, quietly doing what the spec says it should do.

I want to be careful not to overstate the specifics here, since the exact behavior depends on language runtime, Unicode version, and locale configuration. The generalizable lesson is what interests me.

The pattern to look for in your own code

Anywhere a string travels through this sequence, there is potential for trouble:

Accept input.
Check it against a rule: an allowlist, a blocklist, a comparison with a known value.
Transform it: lowercase, strip, unescape, decode, or normalize.
Use it: as a filename, a header, a domain, a database key, a routing decision.

If step three sits between steps two and four, the check is guarding a value the system never actually uses. The fix is not usually to remove the transformation. It is to reorder: canonicalize once, immediately at the boundary, and then validate the canonical form. After that point, the value is settled and nothing downstream may touch it.

This is the same discipline we already accept for HTML escaping and SQL parameterization. Decide on one representation, produce it at the edge, and treat the inside of your system as trusted-by-construction rather than re-cleaned at every stop.

Security comparisons want boring rules

The other thing I have changed my mind about over the years is how much locale-awareness belongs near security decisions.

Human-facing text should be locale-aware. If you are sorting names for a user, or displaying a title, or building a search feature, you want the real linguistic behavior. That is what it is for.

Security comparisons want the opposite. They want a narrow, explicit, boring rule that does the same thing in every environment on every machine. If I am comparing a header name, I want an ASCII-only comparison. If I am matching a token against a list, I want exact bytes, chosen deliberately. If I need case-insensitivity for identifiers, I want the language's dedicated case-folding function rather than the display-oriented one, and I want a comment explaining which one and why.

The general principle: when a function's behavior depends on ambient configuration, do not put it on the path of a decision about access.

Why this keeps happening

Because these functions are marketed to us as trivial. Nobody reviews a .lower(). Nobody writes a test for a lowercase call. There is no linter rule that fires, and if there were, we would probably silence it.

Meanwhile the functions themselves are doing something genuinely complex on behalf of a global user base, and doing it well. Unicode is not the villain in this story. The villain is our assumption that "normalize the string" is a single obvious operation with one obvious result.

What I take away is smaller and more useful than "be afraid of Unicode." It is this: find the places where your code validates a value and then changes it. Those are the seams. In my experience, they are also where the interesting bugs have been hiding all along, patient and well-tested and completely wrong.

Delay Is a Design Material

Mauro Damian Perez Garcia — Wed, 26 Aug 2026 12:39:40 +0000

I read a short argument this week that tooltips need a delay before they appear, and then, once you are obviously working your way along a toolbar, they need to drop that delay entirely. It is a tiny piece of interface behavior. It stayed with me longer than most architecture posts I read this month.

Partly because it is correct, and partly because it is not really about tooltips. It is about the fact that timing is something you design, the same way you design spacing or color. Most teams treat it as a leftover.

We pick 200ms because it felt fine on a fast laptop. Or we pick zero because zero seems honest. Or we inherit whatever number shipped inside the component library we installed on day one and never revisit it. Then the product feels twitchy or sluggish, and the bug report says "it feels weird," which is the hardest class of bug there is.

Two different users living in the same hands

What makes the tooltip case interesting is that a single person switches modes mid-interaction.

When my cursor is crossing the screen on its way somewhere else, a tooltip that fires instantly is noise. It flashes, it covers content, it makes the interface feel jumpy for no reason. The delay exists to filter accidental passes.

But the moment I stop and read one tooltip, I have declared intent. I am now surveying. If the next four icons each make me wait 500ms, the interface is punishing me for exactly the behavior it was trying to encourage. The delay was a filter for accidents, and I stopped having accidents.

So the right behavior is stateful: wait at first, then trust me until I leave the neighborhood. That is the whole insight, and it generalizes further than hover states.

The same pattern, wearing other clothes

Once you see it, this shape is everywhere:

Autocomplete that should debounce while you are typing a word, then feel instant once you have paused and are clearly evaluating results.
Confirmation dialogs that make sense the first time you delete something and become a wall when you are cleaning up thirty items.
Retry backoff that protects a struggling service but should collapse quickly once the service is clearly healthy again.
Loading spinners that should not appear at all under about 300ms, because a flashed spinner reads as a glitch rather than as progress.

In every case the naive fix is a single constant, and the good fix is a small state machine that reflects what the user or the caller is currently doing. Not complicated. Just deliberate.

Why we skip this

I think there are two reasons, and neither is laziness.

The first is that timing behavior is nearly invisible in code review. A diff that changes delay: 0 to delay: 400 looks like nothing. There is no diagram, no type signature, no failing test. Reviewers approve it in two seconds because there is nothing to hold onto.

The second is that we test interfaces in the wrong conditions. We test them on our own machines, with our own muscle memory, in the specific flow we just built. We do not test them while distracted, on a trackpad, at the end of a long day, in the fifth repetition of a boring task. That is where timing either helps or grates.

Designers often catch this and get overruled, because "it's just a hover delay" sounds unserious next to a migration or a latency budget. But these details are the texture of the product. They are the difference between a tool that feels like an extension of your hand and one you have to consciously operate.

What I try to do now

My rough rule is that any timing constant in the codebase deserves a name and a sentence.

Not a paragraph of documentation. Just enough that the next person knows what the number is protecting against. HOVER_INTENT_DELAY with a note that it filters cursor pass-through tells a reviewer what to think about. A bare 400 tells them nothing, so they will change it based on vibes and someone will change it back six months later.

Then I ask whether the constant should stay constant. If the answer is "it depends on what the user just did," that is the signal to add the tiny bit of state. Usually it is a few lines. Usually it is the difference people actually feel.

The broader belief underneath all of this: latency is not only a performance concern. Sometimes the fastest thing is not the best thing, and the right amount of waiting is a feature you chose on purpose.

Interfaces happen in time. Design that dimension too.

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.