🍐#106: How to write blog posts developers want to read and April Fools’ Day in dev tools

Pearrrumble!

Author

Jakub Czakon
April 06, 2025

Hey,

Am I addicted to YouTube shorts? Yes. Do I mostly watch people make food? I wish. Have I found a fantastic pear recipe? Yes. I. Did. Pear Bourdalou đŸ. Yummy.

Also, have I accidentally sent a broken link to an absolute bomb of an article that you later clicked on A TON? Yes ;(. Sorry, this time it works: The Ultimate Guide to Building Developer Tool Websites

This week on the agenda:

  • How to write blog posts developers want to read

  • April Fools’ Day examples in dev tools

  • + a few bonus links at the end

Total pearusing time: 6min

Before we start a word from this week’s sponsor:

Knock is a drop-in replacement for contact forms that lets people talk to you from their Slack, LinkedIn, WhatsApp (and more to come).

It solves a few problems for dev-focused motions:

  • Feels more devy. You see a Slack icon + Chat with us. It has that familiar community vibe.

  • Sets expectations that they will speak to someone “right now-ish” (not wait 4 days to be qualified by sales)

  • Doesn’t ask all the annoying qualifying questions because they enrich/check based on your Slack, LinkedIn, WhatsApp. + you get those contacts enriched on the fly

  • Makes it easy to continue conversations in those places where email threads might have just died out.

Customers like Codeacy, Port, and Descope see qualified conversations (opps) up by 72%.

I’ll be starting to test it out this month. Let’s see how it goes, but I am excited.

Developer marketing insights

1. April Fools’ Day in dev tools

Marie Jaksman put together an awesome post with examples of what dev tool companies did for April 1st this year.

My favorite? OnlyScans. “In today’s slow-moving world of enterprise marketing” you've got to have the guts to do stuff like that. Chuckled and highly appreciated for sure ;)

This one about tariffs is on the nose, too. Very current. Painful but funny.

2. How to write blog posts developers want to read

So a few weeks ago, a HN discussion started following a brilliant article by Michael Lynch, who has a very successful developer blog.

How to Write Blog Posts that Developers Read

Software bloggers can make the same mistakes for years that prevent readers from discovering their writing. I know because I'm one of them. Over time, I've learned techniques that help some blog posts succeed and the pitfalls that cause others to languish in obscurity.

Michael Lynch, refactoringenglish.com

There are many gems there, but this one here can make a huge difference. I mean if people don’t read/skim/scroll nothing else matters.

“When the reader arrives, they’re trying to answer two questions as quickly as possible:

1. Did the author write this article for someone like me?

2. How will I benefit from reading it?

Give yourself the title plus your first three sentences to answer both questions. If you find yourself in paragraph two and you haven’t answered either question, you’re in trouble.”

The HN discussion was fantastic too. Takeaways:

Inverted pyramid is the way to go: Start with the TLDR. Deliver the takeaway first, details second. Frontload information as if your life depended on it. Assume people may skip at any point.

"The inverted pyramid is almost always the correct format for your text. I often put the tweet-length version of the post in the title or first paragraph."

Clarity >>> cleverness: No one owes you their attention. Write like you're being skimmed. Drop the suspense, avoid fluff intros, and spell out the value ASAP.

"In the real world, you are competing for attention. Nobody has to read what you write."

"Get to the point quickly, then elaborate. Means you can bail out at any point of the text and still take home most of what mattered."

Know who you're writing for: If you’re vague about the audience, no one clicks. If you're precise, the right people stay and read.

“The problem of finding an audience is best solved by being really transparent about what you're about.”

Visuals are a liability unless essential: Developer readers aren’t looking for stock photos or cutesy illustrations. Use diagrams if they clarify. Skip decorative fluff.

"Illustrations for the sake of having illustrations are no bueno. Images should never be funny."

Note: I don't agree fully with this comment but others did. Like the article author, the illustrations make articles appear more juicy, especially when those are hand-crafted, diagrams, funny illustrations etc.

Don't bury the lede: Long intros or anecdotes? Most devs won’t make it. Structure like a newswire: who, what, when, why. Then layer context.

"I despise modern long-form journalism which does not establish any of these things until 1/3 through the article."

Balance storytelling with structure: While storytelling is valuable, ensure that the core message isn't buried, allowing readers to extract value even if they don't read the entire piece.​

"You can have other formats as well, and the one you describe can work out, though you're at serious risk of losing the audience before the big payoff."​

Need more developer marketing insights?

1. Work with me 🍐

"You helped us land messaging that clearly states the problem and solution in the words our champions actually use. The homepage is super crisp now."

Chinar Movsisyan, Founder, Feedback Intelligence

If you want my help I do Workshops (60-minute session on whatever you want), Teardowns (audit+suggestions for your homepage, messaging, ads etc), and longer-term Advising.

2. Bonus links to check out

3. Join our Slack community

"Been here 20 min and already folks are sharing great advice."

Charles Cook, VP Marketing & Ops @Posthog

2000+ dev tool CMOs, heads of growth, product marketers, and other practitioners talking shop.

Reply

or to participate.