DEV Community

Cover image for What Developers Get Wrong About Reputation, and Why It Costs Them Everything
Sonia Bobrik
Sonia Bobrik

Posted on

What Developers Get Wrong About Reputation, and Why It Costs Them Everything

Most engineers I know treat reputation the way they treat documentation: something they will get to eventually, probably right after the next sprint, definitely before the launch. The honest version of this article begins with admitting that nobody actually gets to it, and the people who win at building software businesses in 2026 are the ones who figured out that reputation is infrastructure, not garnish. A surprisingly substantive USC Scalar publication on public relations services building trust visibility and long-term brand authority puts a name to what the best indie hackers and founder-engineers have been doing intuitively for a decade: building credibility before they need it, in public, with patience that feels almost irrational by quarterly-metrics standards. The argument I want to make here is that this discipline has stopped being optional, and the developers who refuse to learn it are about to discover what irrelevance feels like in a market where AI tooling has collapsed the cost of shipping software to roughly zero.

The Collapse of the Build-It-And-They-Will-Come Theory

There was a moment, somewhere between the early days of GitHub and the peak of Product Hunt, when a sufficiently clever weekend project could become a real company on the strength of the work alone. That window is closed. The shipping rate of new tools, libraries, and SaaS products has accelerated past any human's ability to evaluate them, and the gatekeeping function has migrated from editors and curators to a much harder problem: trust networks. People install your tool because someone they respect has used it. They subscribe to your newsletter because three different smart engineers in their feed mentioned it in the same week. They evaluate your library not by reading the README but by checking who has starred it.

This is not new wisdom dressed up. It is a genuine phase shift in how technical work gets discovered, and the reason it matters is that the underlying mechanics of attention have changed beneath us. Reporting from the Reuters Institute Digital News Report documents the steady fragmentation of audience attention across platforms and the growing reluctance of readers to trust any single source, which means the old playbook of one big launch in one big publication does not produce the lift it used to. Distribution is now a portfolio problem, and the portfolio is built over years.

What Public Relations Actually Means for People Who Write Code

Let me strip the term of its agency-pitch connotations. Public relations, for a working developer, is the deliberate practice of being legibly useful to your community in ways that accumulate. It is not press releases. It is not paying someone in New York to email journalists on your behalf. It is the sum of every public artifact you produce that demonstrates judgment, taste, generosity, and depth in a specific technical area.

The developers who do this well share a pattern. They pick a narrow domain, almost embarrassingly narrow at first, and they publish steadily inside it for years. The author of a popular Rust async library did not become trusted overnight; they spent four years answering questions on Discord and writing patient explainers about runtimes before anyone outside a small circle knew their name. The same is true of the people whose database benchmarks get cited, the people whose API design opinions get screenshotted, the people whose conference talks get watched after the conference is over. None of them set out to build a personal brand. They set out to be useful, in public, repeatedly, in a domain they actually cared about.

The Three Asymmetries That Make This Worth Your Time

The economics here are strange and need to be stated plainly. Reputation work has three asymmetries that compound in your favor if you commit to it, and that destroy you if you ignore it.

The first is that the cost of producing a thoughtful artifact, a blog post, a benchmark, a teardown of someone else's architecture, is roughly constant whether ten people read it or ten thousand. But the value scales nonlinearly with audience trust. The tenth post in a sequence is not ten times more valuable than the first; it can be a hundred times more valuable, because by then the audience has decided you are worth their default attention.

The second asymmetry is temporal. A post written in 2023 about a difficult debugging problem still surfaces in search results today, still drives Discord mentions, still produces inbound consulting inquiries three years later. Paid acquisition stops working the moment you stop paying. Earned credibility keeps working while you sleep, and keeps working through job changes, company pivots, and platform deaths.

The third is reputational arbitrage. Most of your competitors will not do this work, because it is slow and unglamorous and produces no dopamine for months. The fact that the practice is widely disliked is precisely why it is valuable. Coverage in long-form outlets compounds with this effect, as illustrated by sustained reporting from The New York Times technology section, where the developers and founders quoted year after year are almost always people who built relationships with reporters long before they had anything to sell.

A Working Practice You Can Actually Sustain

If you accept this framing, the question becomes operational. What does the practice look like on a Tuesday, when you have shipping commitments and an inbox and a life? The answer is less impressive than people want it to be, which is part of why most people refuse to do it. The discipline rests on a few habits worth committing to memory:

  • Publish narrowly and often, treating every artifact as a small deposit in a long-term reputation account rather than a launch event that must succeed on its own
  • Engage substantively with other people's work, leaving comments and reviews and replies that demonstrate you actually read the thing, because public attention reciprocates in ways private email never will
  • Document your mistakes in detail, since postmortems and revised opinions build more credibility than victory laps and produce a body of work competitors cannot replicate
  • Show up in the same places for years, the same forums, the same conferences, the same newsletters, because trust is built through repeated low-stakes interactions more than through dramatic high-stakes ones
  • Refuse to optimize for vanity metrics, ignoring follower counts and viral moments in favor of the slow accumulation of readers who would notice if you stopped writing

This list is short on purpose. The actual work is repetition, not strategy.

The Part Nobody Wants to Hear

The hardest thing about this advice is that it cannot be compressed. A six-month sprint of intense content production produces almost nothing of value. The mechanism only works on the timescale of years, and the early returns are so small that quitting feels rational at every checkpoint. The developers who win at this are not smarter or more disciplined than the ones who quit. They simply happened to keep going for one more quarter, and then another, until the compounding kicked in and the inbound started arriving without effort.

If you are reading this and your instinct is to bookmark it and start next month, I would gently suggest that the instinct is the problem. Open a text file. Write four hundred words about something you debugged this week. Publish it under your real name. Do it again on Friday. The infrastructure builds itself if you let it.

Top comments (0)