DEV Community

Cover image for 20+ Lessons I've Learned Writing on DEV for 4 Years
Jean-Michel ๐Ÿ•ต๐Ÿปโ€โ™‚๏ธ Fayard
Jean-Michel ๐Ÿ•ต๐Ÿปโ€โ™‚๏ธ Fayard

Posted on • Updated on

20+ Lessons I've Learned Writing on DEV for 4 Years

I've written 69 articles in the last 4 years and I'm eager to share with you what I've learned so far.

I'm by no means done learning, so if you have additional tips for writing good articles, the comments section is all yours!

1. First, get started ๐ŸŽฌ

If you have not written your first post, nothing you would read here matter much.

So make sure to get started, and if you are unsure how, I have a guide for you!

2. Do not Bury the Lede โšก๏ธ

Your first sentence should contain what is most important in your article.

Here is a test you can use to find out whether you bury the lead in your articles:

Can the first sentence of your article be used as a good tweet to introduce your article?

This one is rather good I would say:

Home___Twitter

This one is rather bad:

Home___Twitter

3. Brainstorm on Paper ๐Ÿ“

To write a good article, you need a good topic, either one you are excited to write about, or one requested by the public(*). You need a good title, and a mission statement of what you are trying to achieve with the article.

I've found it easier to find multiple good titles than to find only one. By that I mean that coming up with a good title when I'm exhausted after finishing an article is hard. On the other hand, if my relaxed brain focuses only on coming up with topics, titles and mission statements, my creativity kicks in. Your mileage may vary but for me nothing beats pen and paper for brainstorming.

(*) Bonus: https://answerthepublic.com/ is a cool tool to find out what the public wants to read. Enter your topic and you will be greeted by the most common questions asked on Google.

4. Talk it Through With a Friend ๐Ÿ—ฃ

Words always come easily - said no writer, ever.

A strategy that works wonder is to:

1) write a shitty first draft as fast as possible, with no structure or formatting getting in the way.

2) talk it through with a friend: "... and what I find very interesting is... / ... what I really wanted to say is that...".

3) now write the article you wish you had discussed with your friend.

5. Learn Markdown ๐Ÿ“š

If you haven't learned Markdown yet, put that on your TODO-list because you need it to format things nicely.

It won't help you only on DEV but also on GitHub, StackOverflow, Blogging software and many more websites.

I won't elaborate on this because @yechielk has done a wonderful job explaining markdown, so bookmark this:

6. Add a Table of Contents โœ…

One flaw of Markdown is that there is no build-in way to say: "Hey, please insert a table of contents here".

If you use Visual Studio Code, I recommend Marky Dynamic with which you can insert and update an automatically generated table of contents.

This is how the table of contents for this article is built.

7. Be Liquid ๐Ÿ’ง

DEV has liquid tags that allow to preview a link

{% post https://dev.to/jmfayard/things-i-ve-been-writing-on-dev-to-22io %}
{% github jmfayard/refreshVersions no-readme %}
{% tag kotlin %} 
{% comment 2d1a %}
Enter fullscreen mode Exit fullscreen mode

GitHub logo Splitties / refreshVersions

Life is too short to google for dependencies and versions

#kotlin

a cross-platform, statically typed, general-purpose programming language with type inference

Deleting code.

(The context here being: working with problematic legacy code and getting to the point where you have new code (paths) that do(es) the same thing but without the issues, so that the old code, and its issues, can just be discarded)

There is a friendly doc available in the editor.

New_Post_-_DEV_Community_๐Ÿ‘ฉ๐Ÿ’ป๐Ÿ‘จ๐Ÿ’ป

8. Use emojis ๐Ÿ˜„

Break the monotony of walls of text by adding emojis as often as they make sense.

I used to think that was ridiculous, I changed my mind.

9. Use #๏ธโƒฃtags

Take some time to discover what tags are available at https://dev.to/tags

Technology-related tags are pretty obvious: #javascript #css #java #python...

There are cross-cuttings tags you want to be aware of:

  • #beginners if your article is accessible for them.
  • #productivity if you have tips to be more productive.
  • #career for anything related to jobs and careers.
  • #showdev to show off what you've built.

Some tags have non-obvious rules you need to be aware of:

  • #discuss is for eliciting community responses but is not appropriate for blog posts.
  • #help is to ask for help, not to be helpful to others.
  • #opensource is for discussing the philosophy and practice of open-source, it's not for promoting your open-source project.
  • #watercooler was hard to understand for me, because I have lived in France where slightly off-topic discussions happen around the coffee machine, and in Germany where they happen in the Biergarten. No watercooler involved.

10. Upload images on GitHub ๐Ÿž

You can get your point across with fewer words using screenshots, annotations, shapes and sketch.

I use Skitch for that, happily so.

One thing I don't like is uploading pictures in the editor.

As a work-around, I have a GitHub issue where I drag&drop all my pictures

Markdown_drag_drop_pictures_ยท_Issue__1_ยท_jmfayard_writing

11. Start a series โญ

Instead of writing one yuuuge article, you can divide & conquer your thoughts in a serie of articles.

Make sure to use the Series feature so that the different parts are linked together.

New_Post_-_DEV_Community_๐Ÿ‘ฉ๐Ÿ’ป๐Ÿ‘จ๐Ÿ’ป

12. Originally published on your own blog ๐Ÿ”—

As much as I like DEV, I want to stay the owner of my content.

For this you need to set the Canonical URL to link to a copy hosted on your own blog. This will tell Google and other search engines where the article originally comes from, and prevent them from flagging the dev.to article as duplicate content (thus banning them from the search results).

Edit_Post_-_DEV_Community_๐Ÿ‘ฉ๐Ÿ’ป๐Ÿ‘จ๐Ÿ’ป

13. Generate your blog with Stackbit โค๏ธ

You don't have an own blog yet?

Wait no more, you can generate it from what you publish on DEV.

https://dev.to/connecting-with-stackbit

This is what I use for https://jmfayard.dev/

I love how low-maintenance it is!

14. Add a cover image ๐ŸŒ…

If you have spent time and effort in your article, you don't want it to to look like a boring link when shared on Twitter/Slack/Whatever.

Therefore you need a cover image of size 1000x420.

(I always forgot this information).

I'm a backend guy so I struggled to produce decent cover images.

My favorite strategy is to write programming code and transform it in a gorgeous image with https://carbon.now.sh/

This is what I've done in Android's billion-dollar mistake(s)

If you can draw, you have a super power that you should use here!

I can't but my wife produced this great cartoon in โ€œWhat is your current salary?โ€ is a red flag that you donโ€™t want to work here

If you publish often on the same topic, Canva is a good tool to produce a branded image where you only have to change the title.

This is what I used in How to learn Kotlin: browser vs IDE, books vs tutorials, for newbies and Java devs - DEV Community ๐Ÿ‘ฉโ€๐Ÿ’ป๐Ÿ‘จโ€๐Ÿ’ป

Last but not least, @pjijin has made a good cover generator. This is what I used for this article:

15. Write in a Markdown Editor โœ๐Ÿป

DEV has its own editor at https://dev.to/new but they won't take offense if I say that a stand-alone Markdown editor is much better.

Thanks to Markdown being a standard (not really, but that's off-topic), there is a variety of editors you can try:

  • Visual Studio Code is good as always, and it has a spell-checker.
  • Notion is a solid choice.
  • Typora is my current favorite for its distraction-free interface.

16. Push to a private GitHub repo ๐Ÿ‘จ๐Ÿปโ€๐Ÿ’ป

Once you start to use a stand-alone Markdown editor, the logical next step is to push your changes to GitHub. Or Gitlab or whatever you prefer.

I got this tip from @john_papa

Saving my content and making sure I do not lose it (2 of my goals) are reinforced by creating a GitHub repository for my content. I prefer this to be private as it contains a lot of my writing. I also organize my repository in a way that makes sense to me. I can find my articles quickly, modify them, iterate on them, and move along.

17. If English is Not Your Mother Tongue... ๐Ÿ‡ฌ๐Ÿ‡ง

Being able to write a complete and easy to read article with no dumb mistakes in a foreign language is such a hard multi-years journey.

Even after 25 years, I'm far from being perfect.

I feel your frustration.

And I highly recommend this article from @vtrpldn who share useful tips to cope with the challenge:

18. Publish Early, Publish Often ๐Ÿ’ก

It is often exhausting to polish an article until everything is ready.

My tip: hit the Publish button before you are ready.

What do you fear? It's not like thousands people will read it the minute you publish it, that never happens.

Having something published releases some of the tension involved in finishing the article.

Now read again your published article, and incrementally improve what needs to be corrected.

19. Publish now, Share later ๐Ÿ“ฃ

It is often exhausting to publish an article, and I will advise you against sharing it right after it's done.

I have a friend who writes epic super long stories, and I was surprised and jealous that he managed to write 1.000 additional words to promote his work on Facebook and LinkedIn afterwards.

His secret was that he gave time to his brain to relax. He "finished" an article on Monday, published it on Tuesday and shared it on Wednesday.

20. Beware of Vanity Metrics ๐Ÿ‘Ž๐Ÿป

Blogging platforms, including DEV, gives you access to the number of views in your article.

It's in the human nature when you see a number to want to see it big, and growing.

I want to have a word of caution here: this is a hedonic treadmill that is not good for you.
As soon as you hit a target, you get used to it, and disappointed when you don't hit it again.

It's dangerous to have goals that are not meaningful. I would suggest to focus on the impact you have, on meaningful conversations, etc.

[UPDATE] Even more tips

I do all my writing in Obsidian which you use similar to Notion, but technically it's more like VS Code for writers, basically a navigator with an infinite amount of plugins.

I have already 381 files and 12k lines of text here, something I would have never expected when I started.

The main process I recommend if you want to fail spectacularly is to try to write a big article all at once until it's perfect.

Rather I recommend writing a shitty first draft, without judgement, without ever pressing the backspace key.
Later I will refactor things.

I already gave that tip from Anne Lamott, the new idea now is that ChatGPT is often perfect for generating that shitty first draft. No blank page syndrom anymore, that's a big deal.

I've discover that scheduling is really important. I would recommand to always schedule your post. It removes the pressure "is my article ready yet?". Who cares, you schedule it for Monday 09:00. You can always improve it until then. And once it's published you are not refreshing your notifications like "oh I hope someone like me and has giving me an emoji". Instead you forget about it and it's a nice comment that reminds you that indeed you have published something.

I also recommend picking a pace. For example I will try to post ever Monday at 09:00. Which pace? Every day? Every month? There is no rule except that the pace suits you. We are creature of habits so this really gets you to the next level.

But for me the biggest win was to use a Swipe File from which you pick your article ideas once you start writing. So you never again face an empty screen and ask yourself: "what I'm gonna write about today?". Instead you separate ideation from writing. If you are out in Paris walking your dog and you get a cool idea for an article --> you put in in the swipe file.

The swipe file is a concept, not an app, you can use any app for that, for example Bear(iOS), Google Keep(Android), SimpleNote(All)
The one very important rule is that you must use that note app only for that purpose.

For example with this comment, I have in fact written the More written tips idea from my swipe file :)

My final advice is that writing is great, just do it, don't worry about being bad at it when you start. It's like programming, it's all practice.

Now I just need to embed this comment in my previous writing tips article.

What About You?

What challenges have you faced trying to write regularly?

What strategies did you use to overcome them?

Any article you want to share?

If you want to write to me, there is a standing invitation at https://jmfayard.dev/contact/

Top comments (42)

Collapse
 
urstrulyvishwak profile image
Kurapati Mahesh • Edited

Superb one. Thanks for sharing your experience for free. It saves lot of my time.

I know my first article is very bad and not the latest article.

First Article: vkglobal.hashnode.dev/js-reduce
Latest article till date: vkglobal.hashnode.dev/explore-es-2...

I don't feel guilty about sharing like this because I never stopped learning and thinking innovative ways in presenting the content.

I have a goal to add new impression like mark down, table of contents, using emojis..etc. for each article I write.

Hence, one day I will surely have all the best practices to present my article in a very beautiful manner.

But your article shown some blunt paths I am currently following.

Many Thanks,
Vishwak

Collapse
 
brandonwallace profile image
brandon_wallace

Nice article. You should also have an introduction to introduce what you will discuss in the article and a conclusion at the end to summarize everything.

Collapse
 
jmfayard profile image
Jean-Michel ๐Ÿ•ต๐Ÿปโ€โ™‚๏ธ Fayard

Good point, I always struggle with conclusions :)

Collapse
 
brandonwallace profile image
brandon_wallace

Me too brother.

Collapse
 
josefine profile image
Josefine Schfr

Thanks so much for this, I found the tips & all the additional resources super helpful! One thing I learned while writing and I try to improve on is writing inclusively. You never know who reads your article and what their background is - and I think it's important that nobody feel belittled or excluded.

Collapse
 
jmfayard profile image
Jean-Michel ๐Ÿ•ต๐Ÿปโ€โ™‚๏ธ Fayard • Edited

Thanks for your kind words.

Agree, I try to remember that we are all different and avoid at all costs title like 5 reasons why EVERY PROGRAMMER should have a BLOG! because it's so wrong to be prescritiptive like this:

I dislike not the content but the title, which deny that we all have different lives.

You can be a developer, mother of two small twins, therefore have no time for blogging outside of your job, therefore your title is false.

Collapse
 
mejunaidraza profile image
Junaid Raza

I use to recommend people use blogging but your opnion is really appreciable. It's true that we can't get time for everything in a short day of life.

Thread Thread
 
mejunaidraza profile image
Junaid Raza

And hope you won't mind it, that a stranger commented on your posts. I am new to these platforms, and I am afraid if people like strangers comments or not.

Thread Thread
 
jmfayard profile image
Jean-Michel ๐Ÿ•ต๐Ÿปโ€โ™‚๏ธ Fayard

Hello, you are very welcome to comment! My hope when I write an article is to have meaningful conversations with people like you.

Collapse
 
pavanbelagatti profile image
Pavan Belagatti

Thanks for all the pointers shared. This article should be bookmarked and I am doing it!

Collapse
 
moose_said profile image
Mostafa Said

This is a great article here. I started writing 1 month ago and i truly love it.

Collapse
 
mpedroc90 profile image
Pedro Carlos Martรญnez • Edited

Very good article Jean!!

Collapse
 
jmfayard profile image
Jean-Michel ๐Ÿ•ต๐Ÿปโ€โ™‚๏ธ Fayard

Thanks a lot for your insights @yechielk @pjijin @john_papa @vtrpldn @helenanders26 !

Collapse
 
petermortensen profile image
Peter Mortensen

For "4. Talk it Through With a Friend":

How exactly is that done? Do you summarise it (the friend is unprepared)? Read it aloud as is (the friend is unprepared)? Does the friend get it in advance in writing and then you talk about it? Or something else?

Collapse
 
jmfayard profile image
Jean-Michel ๐Ÿ•ต๐Ÿปโ€โ™‚๏ธ Fayard

Good question. I don't use the draft article, I try to summarize it, and I try to make it interesting enough to keep my friend's attention

Collapse
 
petermortensen profile image
Peter Mortensen

For 3. ("Brainstorm on paper"):

If it is relatively simple text only, I prefer it on the computer (in a simple text editor, not a word processor where you are distracted by formatting).

But I often use a mind map on paper to generate and exhaust thoughts about a subject, including blog posts.

Collapse
 
jmfayard profile image
Jean-Michel ๐Ÿ•ต๐Ÿปโ€โ™‚๏ธ Fayard

Mind maps are also a good thing to have in your toolbox. I use paper when I feel stuck on my computer. If I don't, I don't use it.

Collapse
 
miguelmj profile image
MiguelMJ

Very valid points!