DEV Community

Bryan Winter
Bryan Winter

Posted on

How to Write a good Dev.to post?

I really like the Dev.to community. Only been here a few days but people are super nice and it's a great place to brain dump my thoughts.

So for both networking and personal satisfaction reasons, I'm thinking about making posts and sharing them to the general public rather than haunting people like a poltergeist.

Any thoughts from the community, especially those that actually have some community street cred, on the kinds of things you make posts about, the ones that stick, the ones that get engaged and the ones that stink or are just magnets for trolling?

I'm specifically interested in starting friendly debates over slightly controversial things. IE, the advantages of certain frameworks over others, good vs. bad practices, the state of the industry, etc. I want to sort of trial run my thinking on a lot of things and get friendly and helpful push-back so I can refine my ideas.

I'm also interested in maybe writing a few tutorials. I'm self-taught and being able to give a hand-up to the new generation coming up behind me appeals to me greatly.

I can see a few patterns on what works and what doesn't already, but I'm interested in any nuggets of insight that might not be obvious.

Discussion (16)

Collapse
v6 profile image
🦄N B🛡 • Edited on

// , I can give you a few tips that I think have helped me. I don't really get much feedback on my writing style, aside from the occasional "Why? Why did you do this to us?", but, in the spirit of "I think I've got this," I think I've got this.

Tip number 1: Include examples. Examples help people to understand things, because they give us the chance to generalize, rather than relying on you to generalize for us.

Tip number 2: Don't get too sad if no one reads what you are writing. If you want to be famous, go on Twitter and say woke things until someone criticizes you.

Tip number 3: Some kind of picture can help, especially if it's funny, for people like me who are easily amused.

Tip number 4: Whatever your sense of humor is, whether it's puns, wry satire, or silly stories, it's possible to show that humor without getting in the way of precise technical points. Also, see Tip number 7.

Tip number 5: If you have some kind of epic, huge journey the reader should take, it miiiiiiiiiight help to make it a series, rather than writing a booklet in a single blog post.

Tip number 6: For interactive stuff, set conditions for engagement. This not only reduces the unavoidable "No ur rong" responses, it also gives people who might disagree with you a way to get around their writer's block. Fun fact: People knowledgeable on a subject are more likely to get writer's block when faced with something they disagree on, especially if they're the civil type.

E.g. for to stimulate a hearty Rust flamewar, "If you want to respond with a rejoinder, please include your least hated and most hated library, what it was that made you hate the Rust language, and the most complex thing you ever made with it (or tried to make)."

Tip number 7: Do you own your data, and your platform? Back up your posts in case you get kicked off of Dev.to. They can exercise their editorial privilege/delete deplatform your stuff if they decide they don't like what you post, man, especially if you follow Tip number 4. Every post is an offensive post if you try hard and believe in yourself. Plus, one of the great things about dev.to is that the devs made it easy to set up canonical URLs and get your own self-hosted blog going.

Collapse
weeb profile image
Patrik Kiss • Edited on

No 1.tip:
Always include at least one of the following words in your title:

let clickBaitTitleWords=
["ultra","ultimate",
"super","extreme",
"mega","ninja",
"superman","god",
"master","king"]
Enter fullscreen mode Exit fullscreen mode

Otherwise your article won't be taken seriously.

But it's preferable to use more of them

Become the ultimate Javascript ninja master with these super extreme tricks

Now that's instant 5k views and 300 reactions.

Collapse
v6 profile image
🦄N B🛡

// , Am I greedy for wanting a dev.to title generator?

Collapse
xanderyzwich profile image
Corey McCarty

Write it. And then use it to generate the title of the post that you make about it.

Collapse
xanderyzwich profile image
Corey McCarty

You forgot 10x

Collapse
mahardikacode profile image
Mahardika-Code • Edited on

How you can add example like that??, I mean photo with some line of code.

Collapse
mellen profile image
Matt Ellen

Use markdown in your posts. You can learn more here: dev.to/p/editor_guide

Collapse
aleksandrhovhannisyan profile image
Aleksandr Hovhannisyan • Edited on

The most important piece of advice I can impart is one that experts in the SEO space always emphasize: Produce genuinely useful/informative/helpful content that people will actually want to read.

In other words, don't do what I've noticed some people doing here on Dev.to: Regurgitating documentation. We don't need another post on Array.reduce, data structures and algorithms, light/dark mode in CSS, etc. This is the main reason why I stopped reading Medium—lots of low-quality posts bubble to the top and pollute Google search results.

This does NOT mean that you should avoid writing about something just because someone else already has. It just means you'll have to try extra hard to make your content even better/unique.

Good luck!

Collapse
v6 profile image
🦄N B🛡 • Edited on

// , As a Documentation Regurgitator, I take offense to that. What if people like to read documentation in dev.to's special format?

But seriously, good tips there. Actually useful stuff you've figured out on your own can be good.

And in a less silly defense of my Regurgitation, sometimes it's helpful to see an example of the documentation in action, provided it's reproduced on the post author's own environment with enough variation to allow the reader to generalize.

Collapse
aleksandrhovhannisyan profile image
Aleksandr Hovhannisyan

It's okay to take offense. Could you clarify what you mean by "dev.to's special format"? What makes this format acceptable for content pollution?

Content that doesn't add value to existing literature is, in my opinion, useless. It's increasing the amount of noise on the site. I can't count how many blog posts I've already seen popping up in my feed that are 0-effort copy pastas of the same JavaScript topics that have been covered in depth by documentation, blog posts, YouTube videos, courses, and lots more.

Judging from your post history, it doesn't seem like you're actually regurgitating documentation—you're writing in a fairly unique niche where there are few, if any, people doing the same thing that you are. So I think you either misunderstood what I meant or are playing devil's advocate.

There's a certain cluster of posts on Dev.to that do nothing but rehash the same topics over and over and over again, sometimes just a day apart from each other. These dead horses have been beaten well into the afterlife, but people still keep going.

I'd bring up specific examples with screenshots, but I don't want to cause offense :)

Thread Thread
v6 profile image
🦄N B🛡 • Edited on

// , Hm. I didn't make it clear enough that I was being cheeky. Sometimes I really do feel like I'm just saying stuff people can figure fairly easily on their own from RTFM though.

Edit:

There's a certain cluster of posts on Dev.to that do nothing but rehash the same topics over and over and over again, sometimes just a day apart from each other. These dead horses have been beaten well into the afterlife, but people still keep going.

Yeah, there are topics that are popular, (and I've heard "urgent", not sure what that's code for yet) or "topical," and there are topics that are useful and can be reasoned about. The useful stuff tends to be a bit more niche, in my experience.

Sometimes there's overlap on those two and sometimes not.

Thread Thread
aleksandrhovhannisyan profile image
Aleksandr Hovhannisyan

Oh

Yeah, woops. I didn't sense that tone.

Poe's law strikes again

Collapse
brandinchiu profile image
Brandin Chiu

I'm in the middle of drafting some work of my own here, so while I don't have advice on the writing piece, I will offer some ideas for things that I like and dislike in the articles I read:

  • avoid clickbaity titles. They seem disingenuous from the start even if the content is great.
  • try to do something that someone else hasn't done before.
  • avoid absolutes. Any time I read someone say "this is the objectively best way to do this and all other ways are bad" I'm immediately gone. Real life doesn't work like that.
  • do include your personality. Whether that's wit, a rhythm in your prose, or maybe funny gifs. Make it personal.

Good luck!

Collapse
napicella profile image
Nicola Apicella

Google shared a guide on how to write tech docs.
Plenty of useful tips, take a look:
developers.google.com/tech-writing...

Collapse
xanderyzwich profile image
Corey McCarty

I think that a good post should both provide helpful information and foster discussion. Incidentally I wrote a post on the topic.