You shipped something last week. Maybe it was a gnarly migration, a performance fix that shaved 200ms off page load, or a feature that unblocked an entire team. You merged the PR, mass-deleted the branch, and moved on.

Meanwhile, some product manager posted “Excited to announce we’ve updated our button color!” and got 4,000 likes.

Here’s the thing: your merged PRs are the best content source you’re ignoring. You’ve already done the hard part — the actual work. You just never tell anyone about it.

Let’s fix that.

Why PRs Are Underrated Content

Most developer “personal branding” advice tells you to start a blog, tweet hot takes, or build in public. That’s fine, but it requires you to generate new ideas from scratch. PRs are different because the content already exists. You already wrote the title, the description, the context for reviewers. You already know the “why” behind the change because you lived it.

The problem isn’t a lack of material. It’s the translation step — going from fix: resolve race condition in webhook handler to something a human on LinkedIn would actually want to read.

And look, I get the hesitation. Developer LinkedIn has a reputation. Nobody wants to be the person writing “Just mass-refactored 47 files and I’m literally shaking.” But there’s a wide gulf between that and staying completely silent about your work.

The Anatomy of a Good Dev LinkedIn Post

Let’s look at what makes a dev post land well versus what makes people silently hit “unfollow.”

The Bad Post

Excited to announce that I’ve been working hard on improving our API response times! After weeks of dedicated effort, I’m proud to say we achieved a 3x improvement. This wouldn’t have been possible without my amazing team. #Engineering #Innovation #Hustle

What’s wrong here: it’s vague, it’s full of filler words, and it reads like a press release from someone who’s never touched a terminal. There’s no technical substance. “Improving API response times” could mean literally anything.

The Good Post

We had an API endpoint taking 900ms to respond. Customers were complaining. Turns out we were making 6 sequential database calls that could’ve been 2 parallel ones.

Rewrote the query layer, added connection pooling, and got it down to 280ms.

The fix was 40 lines of code. The investigation to find it took 3 days.

Sometimes the hardest part of performance work isn’t the optimization — it’s figuring out where to look.

This works because it tells a story with real numbers. It has a beginning (the problem), a middle (the investigation), and an end (the fix). And it ends with a takeaway that other engineers can relate to.

For more formats that work, check out our developer LinkedIn post examples — we break down templates you can steal.

What to Pull From a PR

Not every PR is post-worthy, and that’s fine. But when you do have something worth sharing, here’s what to mine from it:

The Title and Description

Your PR title is your starting point, but it’s rarely the headline. fix: handle null user in billing flow is a good commit message but a terrible LinkedIn post. The description, though — especially if you wrote a good one for reviewers — often contains the narrative you need: what was broken, why it mattered, what you tried.

The Diff Stats

Numbers are attention magnets. “Changed 3 files, +47/-200 lines” tells a story by itself. Deleting more code than you added? That’s inherently interesting. A one-line fix to a three-day bug? People love that.

The “Why” Behind the Change

This is the most important part and the one most people skip. Nobody cares that you “updated the user service.” They care that customers were getting charged twice, that you tracked it down to a race condition in the event queue, and that the fix involved rethinking how you handle idempotency.

The “why” is what separates a forgettable status update from a post people actually engage with.

The Context You Won’t Find in the Diff

Some of the best material isn’t in the code at all. It’s the Slack thread where someone reported the bug. It’s the three wrong hypotheses you had before finding the right one. It’s the decision to not use the “clever” solution in favor of the boring one. That stuff is gold.

Framing Technical Work for a Non-Technical Audience

If your LinkedIn network includes recruiters, PMs, founders, or anyone who doesn’t read diffs for fun, you need to translate. The key principle: lead with impact, not implementation.

Non-technical people don’t care about your query optimization. They care that pages load faster, users aren’t churning, or the team can ship twice as fast.

Here’s the formula:

Start with the human problem. “Customers were waiting 10 seconds to see their dashboard.”
Briefly mention what you did. “Rewrote how we fetch and cache the data.”
End with the result. “Dashboard loads in under 2 seconds now.”

Skip jargon. Replace “implemented a Redis caching layer with TTL-based invalidation” with “added a faster way to remember data so we don’t fetch it from scratch every time.” You’re not dumbing it down — you’re translating it into the language your audience speaks.

The structure works great for visibility with engineering managers and leadership too. They want to know what shipped and why it matters, not which ORM you used.

Framing Technical Work for a Technical Audience

Different audience, different approach. When you’re writing for other engineers, the implementation details are the interesting part.

Here’s what technical readers want:

The Problem-Solution Arc

Engineers love a good debugging story. Start with the symptom, walk through your investigation, reveal what you found, and explain the fix. It’s the same structure as a good conference talk, just compressed into a few paragraphs.

Specific Technical Decisions

“We chose X over Y because Z” is one of the most engaging formats for a technical audience. Engineers are constantly making tradeoffs, and seeing how someone else reasoned through one is genuinely useful.

For example: “We considered adding a message queue but realized our throughput didn’t justify the operational complexity. A simple database-backed job table with SELECT FOR UPDATE SKIP LOCKED handled our load fine and we didn’t need to learn/deploy/monitor a new piece of infrastructure.”

That’s a post. That’s a useful one. Someone out there is making that same decision right now.

Numbers and Benchmarks

Technical people are skeptical by default (it’s a survival mechanism). Specific numbers build credibility. “Reduced memory usage” is hand-wavy. “Reduced memory usage from 2.1GB to 340MB by switching from in-memory joins to streaming processing” is concrete and believable.

The Honest Take

Did your “quick fix” turn into a two-week refactor? Did you over-engineer something and have to simplify it later? Technical audiences respect honesty about mistakes more than they respect a polished success narrative. The uncomfortable posts tend to perform best because they feel real.

Putting It Into Practice

Here’s a lightweight process you can use starting today:

At the end of each week, scan your merged PRs. You can do this directly on GitHub — filter your PRs by “is:merged” and look at the last 7 days.
Pick the one that has the best story. Not the most complex, not the biggest diff — the one with the most interesting “why.”
Write a first draft in 5 minutes. Don’t overthink it. Problem, what you did, result. Three short paragraphs.
Pick your audience. Technical or non-technical? Adjust the level of detail accordingly.
Post it. Seriously, just post it. Your first few posts won’t go viral and that’s completely fine. You’re building a habit.

If you want to skip the manual work, ShipPost can pull your merged PRs directly from GitHub and generate multiple post variations for you — tuned for different audiences and lengths. It’s built specifically for this workflow because, honestly, I got tired of doing it by hand.

But tool or no tool, the important thing is that you start turning your shipped work into visible work. Your PRs are proof that you solve real problems. The only question is whether anyone outside your team knows about it.

The “I Don’t Want to Be That Person” Objection

I hear this constantly. “I don’t want to be self-promotional.” “My work speaks for itself.” “LinkedIn is for salespeople.”

Here’s my counter: your work doesn’t speak for itself. It speaks for itself to your team, because they see the PRs. Everyone else — the hiring manager at a company you might want to work at someday, the conference organizer looking for speakers, the future cofounder you haven’t met yet — they have no idea what you’re capable of unless you tell them.

Talking about your work isn’t bragging. Bragging is taking credit for things you didn’t do or inflating your impact. Describing a real problem you solved with specific details is just… sharing knowledge. Other engineers benefit from it. That’s the whole reason conference talks and blog posts exist.

You don’t have to post every day. You don’t have to use hashtags. You don’t have to “engage” with influencer content. Just share one real thing you built or fixed, once a week, with enough detail that someone else could learn from it.

That’s it. That’s the whole strategy.

Ready to try it? Sign in to ShipPost, connect your GitHub, and turn your next merged PR into a LinkedIn post in about 30 seconds.