DEV Community

Cover image for Why “Building in Public” Is Hollowing Out Your Developer Career
Karol Modelski
Karol Modelski

Posted on • Originally published at javascript.plainenglish.io

Why “Building in Public” Is Hollowing Out Your Developer Career

Somewhere in the last few years, “being a developer” quietly turned into “being a content creator with VS Code open in the background.”

You’re told to:

  • post daily on X,
  • share screenshots on LinkedIn,
  • thread your way to a “personal brand,”
  • and narrate every micro-step of your side project like a reality show.

If you’re honest, a lot of it doesn’t feel like growth.

It feels like performance.

The industry told you to build in public to grow your career. What it often did instead was trade your deep work for a never‑ending cycle of performative updates.


The Illusion of “Building in Public” as Career Growth

In theory, building in public has real benefits:

  • you share your journey,
  • you attract collaborators and users,
  • you get feedback early,
  • you build trust over time.

In practice, a lot of devs experience something closer to this:

  • pressure to post even when there’s nothing meaningful to say,
  • anxiety about negative feedback and nitpicking, especially early on,
  • a creeping sense that the project now exists for the timeline, not for users.

Founders and solo builders have already started saying:

  • building in public added pressure and opened them up to criticism before they were ready;
  • sharing every step sometimes attracted the wrong audience — other builders, not actual customers.

For developers, it’s even worse:

  • your “work” isn’t just code; it’s suddenly threads, carousels, and engagement metrics.

Building in public can work when it’s in service of a real product. When it becomes its own product, your career quietly turns into a content channel.


Hustle Culture in a Hoodie: When “Community” Is Just a Content Farm

Scroll LinkedIn or X long enough and you’ll see the same formula:

  • “Day 27 of building my SaaS in public.”
  • “Five lessons I learned shipping this tiny feature.”
  • “Here’s how I grew from 0 to 10k impressions in a month.”

It looks like community.

Underneath, it’s often:

  • everyone broadcasting,
  • almost nobody actually talking,
  • endless “value posts” designed to farm engagement, not build relationships.

Hustle culture research is very clear:

  • constant pressure to be “always on,” visible, and optimizing yourself is a fast path to burnout;
  • people burn out not from hard work alone, but from tying their identity and worth to constant output and public performance.

“Developer community” can quietly morph into:

  • a place where you perform your progress to be seen as serious,
  • instead of a place where you can be confused, wrong, and still belong.

If every post needs to be ‘high value,’ you’re not in a community — you’re on a stage. And you can’t do deep engineering from a stage.


The Myth of Networking: Why Most “Connections” Feel Empty

A lot of dev networking advice sounds like this:

  • comment on 20 posts a day,
  • DM people with a “value offer,”
  • build a pipeline of leads,
  • track your interactions like a CRM.

No wonder networking feels gross.

When you see people as:

  • “targets,”
  • “leads,”
  • “potential collabs,”

every interaction becomes a bit of a transaction.

Writers on networking point out:

  • transactional networking focuses on what you get and what you give right now;
  • real, long-term networking looks more like friendships: shared curiosity, vulnerability, mutual support without immediate ROI.

The developer version of this:

  • boosting each other’s posts,
  • trading likes and “fire thread bro,”
  • without ever actually reading each other’s code, docs, or ideas.

If your “network” disappears the moment you stop posting, you didn’t build relationships. You built an audience with commitment issues.


Deep Work vs. Shallow Visibility: What Actually Moves Your Career

Here’s the part almost no “build in public” thread admits:

High-quality engineering work still comes from long, quiet, cognitively demanding sessions — deep work.

Deep work for engineers looks like:

  • designing or refactoring serious systems,
  • debugging hairy production issues,
  • learning technologies deeply enough to bend them, not just copy patterns.

Shallow work looks like:

  • checking analytics,
  • replying to on-platform comments,
  • cranking out posts to stay “top of mind,”
  • tweaking your “personal brand.”

Productivity research keeps finding the same thing:

  • deep work blocks (60–90 minutes, protected from distraction) are where engineers produce lasting value;
  • constant context-switching into social apps and content creation erodes your ability to concentrate and reason deeply.

Even content people are starting to say:

  • meaningful writing and creative work also need deep work;
  • churning out fast food content creates attention, not substance.

So when developers try to:

  • be great engineers,
  • be consistent content creators,
  • be always-on networkers,

they’re effectively trying to run three cognitively expensive careers at once.

You can either optimize for long-term leverage in your skills, or for daily impressions. Pretending you can do both at scale is how you quietly burn out.


How to Grow Your Career Without Becoming a “Content Creator”

If building in public and hustle-flavored networking feel wrong to you, good.

You’re not anti-growth. You’re allergic to nonsense.

There is a quieter, more sustainable path.

1. Trade public performance for small, real circles

Instead of:

  • broadcasting to thousands you don’t know,

do this:

  • join or form a small group (3–8 devs) around a stack or topic you care about.
  • meet regularly (monthly/bi-weekly) to:  — review each other’s code,  — share real problems,  — talk about trade-offs and decisions.

This is closer to genuine networking research:

  • relationships built around vulnerability and mutual help, not transactions.

2. Treat deep work as your primary “brand”

Your actual career capital is:

  • systems you’ve built,
  • migrations you’ve survived,
  • incidents you’ve handled well,
  • weird bugs you’ve debugged and understood.

Protect daily deep work blocks like meetings:

  • 60–90 minutes a day where Slack, socials, and posting are off.
  • learn, design, or build something hard, then document it privately first (notes, ADRs, internal docs).

You’ll have far more to say publicly later if and when you choose.

3. Share selectively, not compulsively

You don’t owe the internet your process.

A healthier rhythm:

  • focus on building for weeks or months,
  • periodically share one well-thought-through post:  — “Here’s how we solved X at Y scale.”  — “Here’s a migration that hurt, and why I’d do it differently.”

Quality over cadence.

As even pro‑content people admit: resonant work takes time.

4. Network like a human, not a funnel

When you reach out:

  • reference something specific you actually read or used,
  • offer something small but real (a useful comment, a perspective, a resource),
  • be okay if nothing “converts” immediately.

Long-term networking research is blunt:

  • real opportunities come from a handful of strong ties built on trust and vulnerability, not from hundreds of shallow interactions.

The most valuable developer network you’ll ever have fits into a group chat, not a follower count.


The Quiet Flex: Being Good at the Boring Parts

The irony of all this is simple:

  • the people shipping the most meaningful work are often too busy doing it to narrate every step;
  • the loudest “builders in public” are sometimes optimizing more for perception than for durable skill.

If you want a career that actually compounds, not just one that looks impressive on social media:

  • get uncomfortably good at deep, focused engineering work;
  • cultivate a small, honest circle of peers with whom you can be wrong, confused, and ambitious;
  • share publicly when you genuinely have something to say — not because the algorithm demands a sacrifice.

You don’t have to become a thought leader.

You don’t have to “build in public” every commit.

You just have to:

  • keep learning in private,
  • keep shipping in reality,
  • and build a handful of relationships strong enough to survive even if you never post again.

The best thing you can do for your developer career is not to become more visible. It’s to become someone worth finding, even if you’re quiet.


I’m an Independent Technology Partner for SMEs. If you’re looking to optimize your architecture or accelerate your MVP, let’s connect at karolmodelski.pl.

Top comments (0)