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.
Top comments (15)
// , 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/deletedeplatform 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.No 1.tip:
Always include at least one of the following words in your title:
Otherwise your article won't be taken seriously.
But it's preferable to use more of them
Now that's instant 5k views and 300 reactions.
// , Am I greedy for wanting a dev.to title generator?
Write it. And then use it to generate the title of the post that you make about it.
You forgot
10x
How you can add example like that??, I mean photo with some line of code.
Use markdown in your posts. You can learn more here: dev.to/p/editor_guide
// , 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.
// , 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:
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.
Oh
Yeah, woops. I didn't sense that tone.
Poe's law strikes again
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:
Good luck!
Google shared a guide on how to write tech docs.
Plenty of useful tips, take a look:
developers.google.com/tech-writing...
I think that a good post should both provide helpful information and foster discussion. Incidentally I wrote a post on the topic.
Blogging Goals
Corey McCarty γ» Jan 24 γ» 5 min read