// , “It is not so important to be serious as it is to be serious about the important things. The monkey wears an expression of seriousness... but the monkey is serious because he itches."(No/No)
// , 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.
// , “It is not so important to be serious as it is to be serious about the important things. The monkey wears an expression of seriousness... but the monkey is serious because he itches."(No/No)
// , “It is not so important to be serious as it is to be serious about the important things. The monkey wears an expression of seriousness... but the monkey is serious because he itches."(No/No)
// , 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.
Current CTO exploring entrepreneurship on the side; coach; mentor; instructor.
Dedicated to promoting digital literacy and ideological diversity in tech.
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.
// , “It is not so important to be serious as it is to be serious about the important things. The monkey wears an expression of seriousness... but the monkey is serious because he itches."(No/No)
// , 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.
// , 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.
You forgot
10x// , 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.
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
// , 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.
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!
// , 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.
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