At times, as writers, we may be really eager to write about a particular topic, only to be hindered by a mental block that makes it difficult to articulate our thoughts effectively. Despite our passion for writing, we may struggle to develop a cohesive idea that aligns with our intentions.

This common phenomenon is often referred to as "writer's block," and it affects not only book or article writers but also songwriters.

In this article, we will explore tools that can help writers generate titles aligned with their intentions and also optimize the title for search engine optimization (SEO). Additionally, we will discuss causes and strategies for overcoming writer's block.

What is Writer's Block?

Writer's block is a temporary condition that impedes a writer's ability to produce new written content or causes a significant decrease in creativity and productivity.

This form of mental paralysis can hinder progress on any project or piece of writing, making it difficult to focus, find inspiration, and stay motivated. The resulting frustration can often lead to procrastination and a sense of being stuck, ultimately hindering the completion of a project within the desired timeframe.

What Are the Causes of Writer's Block?

Various factors can lead to writer's block, such as:

1. Stress: High levels of stress or exhaustion can make it difficult for writers to concentrate and come up with fresh ideas.
2. Fear or self-doubt: Writers struggle with anxiety and self-doubt, which can make it difficult to feel motivated and productive. If you're currently experiencing this type of writer's block, you're not alone.
3. Lack of inspiration: Writers may struggle to find new and creative ideas. It's common for writers to face challenges, which result in a lack of motivation and a feeling of being stuck.
4. Environmental factors: External factors such as noise or interruptions can disrupt a writer's concentration and hinder their ability to produce quality work.
5. Perfectionism: Some writers strive for perfection and may become overwhelmed by the pressure to create flawless content, resulting in difficulty getting started or completing a project.
6. Physical or mental health issues: As the saying goes, health is wealth. Medical conditions such as depression, anxiety, or chronic pain can affect a writer's ability to focus and be productive.
7. Network Issue: such as low bandwidth or internet disruptions, can cause distractions, and frustrations, and ultimately lead to procrastination. As a result, by the end of the day, you may forget what you had intended to write about initially.

How Do You Overcome Writer's Block and Boost Your Creativity?

1. Free writing: keep a journal and write without any expectations or limitations. Simply jot down whatever comes to mind without worrying about grammar or structure. This technique can help generate new ideas and inspire your writing. I use this technique often and find that it helps me overcome writer's block and get started on a new piece.
2. Take a break: Stepping away from your work for a short period of time can help refresh your mind and provide a new perspective. When you come back to your writing, you may have a fresh perspective or renewed energy that can help you overcome writer's block and move forward with your project.
3. Change your environment: This can also help stimulate creativity. Being in a new location can provide fresh inspiration and break up the monotony of writing in the same place. Consider working in a new setting or taking your writing outdoors to help overcome writer's block. This can help you get inspired.
4. Try something new: Experimenting with a new genre, style, or format can spark fresh ideas and inspiration. This strategy has been recommended to me by my sister, and I have found it helpful in breaking out writer's block.
5. Practice self-care: Taking care of your physical and mental health is crucial in reducing stress and anxiety, which can hinder creativity and productivity. Prioritizing activities such as exercise, healthy eating, and mindfulness practices can help improve focus and promote a positive mindset, thereby stimulating your mind, and ultimately overcoming writer's block.
6. Reading Widely: This exposes you to a variety of writing styles. It can help broaden your perspective, increase knowledge, and spark new ideas. Reading can help overcome writer's block and boost creativity. Additionally, reading widely can also improve your writing skills by observing and learning from other writers' techniques and styles.
7. The Art of Brainstorming: This can unleash a flood of ideas and inspire creativity by gathering a diverse group of individuals and fostering an environment that encourages the generation of ideas without criticism or judgment.
8. Get organized: When faced with writer's block, getting organized can help clear your mind and provide structure, making it easier to focus and get your creative juices flowing.

Tools to Help to You Overcome Writer's Block

There are tools available that can help you generate ideas for articles. This can help you prevent episodes of writer's block.

Article Idea Generator:

This tool uses advanced algorithms and natural language processing to suggest a variety of SEO-optimized article topics based on user input.

Since it's open-source, it also allows for customization to suit individual writing styles, making it a personalized solution for beating writer's block.

[Article Idea Generator](https://www.articleideagenerator.com/" rel="noopener noreferrer nofollow)

Freedom

This application assists you in getting rid of distractions by preventing certain websites and apps from interfering with your writing process.

By concentrating solely on your writing, you may be able to overcome writer's block and produce better-quality work.

It's worth noting that Freedom has both free and paid versions, and you need to sign up to access all of its features. Additionally, you can download the application to your device.

[Freedom](https://freedom.to/" rel="noopener noreferrer nofollow)

Headline Generator

The Headline Generator generates attention-grabbing and SEO-friendly titles for social media posts and YouTube captions by analyzing keywords. It saves time, sparks new ideas, and increases engagement and readership. Content creators can use it to boost their online presence.

[Headline Generator](https://www.contentrow.com/tools/headline-generator" rel="noopener noreferrer nofollow)

ProWritingAid

This is an online writing tool that can enhance your writing with suggestions for grammar and style, as well as readability analysis.

By utilizing this tool, you can overcome writer's block and improve the quality of your work. However, you need to sign up to access all of the features.

[ProWritingAid](https://prowritingaid.com/" rel="noopener noreferrer nofollow)

Conclusion

Writer’s block can be a frustrating and daunting experience for anyone, regardless of skill level. It can sap your creativity and leave you feeling stuck and unmotivated.

Luckily, there are plenty of tools out there to help you overcome writer’s block, boost your creativity, and stay productive.

These are just a few examples of the numerous software tools available to help prevent writer's block. Ultimately, the best tool for you will depend on your individual needs and preferences as a writer.

Keep exploring different tools and trying new things until you find what works best for you.

With some patience and determination, you find yourself writing with renewed energy and enthusiasm.

Here's a helpful article you can read about the power of rest and how it helps you be more creative:

If you found this article helpful, please consider sharing it with other Technical writers who may benefit from it.

If you're interested in reading more of my articles, feel free to check out my blog. Additionally, you can connect with me on Twitter and LinkedIn to stay up-to-date on my latest work.

Thanks for reading💖

Here is what it looks like: you are an awesome person.

These are various use cases for strikethroughs:

• To indicate that a piece or block of text that should be deleted.
• To indicate that a piece or block of text is outdated.
• To show task completion. This is usually seen in To-Do lists.
• To convey an unrelated or humorous message when writing, and so on.

In this article, we'll see how to strikethrough or cross out text when writing using Google Docs.

How to Strikethrough Text in Google Docs

There are two methods we can use when crossing out text in Google Docs – using a shortcut command or choosing the strikethrough option from the Format tab in the Google Docs header section.

How to Strikethrough Text in Google Docs Using a Shortcut Command

Here are the steps to follow when using a shortcut command to strikethrough text in Google Docs:

• Open Google Docs and create a blank document.
• Write some text in your document.
• Highlight the text you've written.

• On windows, press Alt + Shift + 5.
• On Mac, press ⌘ + Shift + X.

There you go, we have used a shortcut command to cross out text in Google Docs.

How to Strikethrough Text in Google Docs Using the Format Tab

In this section, we'll see how we can strikethrough text in Google Docs using the Format option. Here are the steps:

• Open Google Docs and create a blank document.
• Write some text in your document.
• Highlight the text you've written.
• Click on the Format tab in the header.
• Click on Text.
• Click on the Strikethrough option.

After you have done this, your text should be crossed out.

Conclusion

In this article, we talked about strikethroughs in writing, their use cases and how to strikethrough/cross out text in Google Docs.

Thank you for reading! But really, thank's for reading! :)

In this post we're going to get all the headings from a freeCodeCamp blog post to make a Table of Contents (ToC) in Ghost CMS.

I recently published quite a large post here on freeCodeCamp and needed to add a table of contents to the post.

There's a really good supporting post written by Colby Fayock on how to do this. It details the process really clearly.

You can check out the video and really comprehensive guide on that for all the details:

Colby's post details why you would want a Table of Contents (ToC) and how to create one using the Ghost editor (the editor used for writing this post in the Ghost CMS).

The thing is, I had 33 headings in the post I needed to add links for. And the thought of scrolling through a 10,000 word document to get a heading then scroll to the top to add it to the table of contents made me wonder if there was a better way to do it!

Table of contents:

• JavaScript to the rescue!
• Get the element properties
• Get the element id and innerText
• Filter on the localName
• Conclusion

JavaScript to the rescue!

With this thought in mind I did a quick search and found a Stack Overflow answer that I could use. Here's the snippet:

var ids = document.querySelectorAll('[id]');

Array.prototype.forEach.call( ids, function( el, i ) {
  // "el" is your element
  console.log( el.id ); // log the ID
});

So, let's hop on over to the browser now and try that out.

I'll go over to that published post now in the browser and open the developer tools. (In Chrome and Edge it's F12 to open the dev tools.) Then I'll paste in that example code into the console and hit enter, here's the output:

Get the element properties

Not bad but I want the heading title as well, so one quick way to see the properties of the elements is to wrap the el in some curly braces:

let ids = document.querySelectorAll('[id]');

Array.prototype.forEach.call(ids, (el) => {
  console.log({el});
});

You'll notice I've cleaned up the function a bit, replacing the inline function with an arrow function and replaced var with let so the syntax is more modern.

Running that snippet in the browser now gives me the object for each element:

I can then expand out one of the elements now to get all the properties relating to it. From here I'm going to want to get the id (which I already know was there) and also the innerText which is the heading title:

Get the element id and innerText

Let's add the innerText element to the snippet we're working with and see what that looks like now. Here's the snippet:

let ids = document.querySelectorAll('[id]');

Array.prototype.forEach.call(ids, (el) => {
  console.log(el.id);
  console.log(el.innerText);
});

And here's the output we get from that:

Ok, so that is really noisy as it's showing the innerText of every element in the document with a lot of irrelevant information on there. All we're really interested in is the title of the heading and it's id.

Filter on the localName

All the headings I use in the post are h2 headings so I want a way to filter that. So from the {el} properties I'll need to grab the localName which denotes the type of the element h2 in the case here.

So let's use an if function to see if the localName includes h2 and if it does log that out. I'll also use a template literal to add the anchor id # to the beginning of the id:

let ids = document.querySelectorAll('[id]');

Array.prototype.forEach.call(ids, (el) => {
  if (el.localName.includes(`h2`)) {
    console.log(`#${el.id}`);
    console.log(el.innerText);
  }
});

Let's take a look at the output now:

Much nicer!

Now I can use that output to start making my ToC!

Conclusion

We took what could be quite an extended process and turned it into a handy snippet we can use in the browser console every time we need to create a ToC for our blog posts.

That's it, hope you found it useful! 🙏

If you like the content you can check out much more from me on my blog and you can follow me on Twitter.

These extra pages could be caused by tables, hitting the ENTER key too many times, unnecessary section breaks, unintentional page breaks, extra paragraph markers, and more.

You don’t want your Word document to look unprofessional because of this quirk, so in this article I'll show you how to delete blank and extra pages in Word.

I will be using Microsoft Office 2016 in this tutorial, but you can follow along with any version, as pretty much the same thing applies to all versions.

How to Delete a Blank Page in the Middle of a Word Document

If you are working with a large word document and you are about to present it or print it, it’s a good idea to check for blank pages and an extra final page.

To do this, press CTRL + SHIFT + 8, or go to the Home tab and click the paragraph icon.

This key combination displays paragraph markers (¶) at the end of every paragraph and each blank line – basically, whenever you hit the ENTER key, and at the beginning of the extra blank page.

To remove these extra pages, highlight the paragraph markers with your mouse or trackpad and hit the DELETE button. If one of the markers remains there, remove it with the BACKSPACE key.

If you have the patience, you can also remove the blank page(s) by going to the blank pages and hitting the BACKSPACE key until the paragraph markers disappear.

How to Delete an Extra Blank Page in a Word Document

Step 1: To delete an extra blank page that might get added at the end of your document, click the View tab:

Step 2: Go to the Navigation Pane. This will display a sidebar containing 3 tabs – Headings, Pages, and Results. Click on Pages to display all the pages of the document in the sidebar.

Step 3: The active page will be automatically selected. Click the extra blank page to select it and hit the DELETE button on your keyboard to remove it.

You can also remove this extra blank page by simply pressing the BACKSPACE key.

Conclusion

In this article, you learned how to remove blank pages in Word, so you can make your documents appear more professional.

Thank you for reading. If you find this article helpful, please share it with your friends and family.

You might think that software development is all about writing code, but that's not true. A huge part of the job is communicating with others. And as we all move towards more remote work, written communication is becoming increasingly important.

“In their first few years on the job, engineers spend roughly 30% of their workday writing, while engineers in middle management write for 50% to 70% of their day; those in senior management reportedly spend over 70% and as much as 95% of their day writing.” - Jon Leydens

Last year, I left my career as a software engineering manager and CTO to start writing full-time. After a decade in engineering I was ready for a career change, so with six months of savings in the bank, I decided to take the plunge.

I'm happy to say that it's gone really well, and my company was recently featured on TechCrunch for our technical writing work.

I had written blog posts and tutorials on the side for years before starting Draft.dev, so I was pretty confident in my writing skills. But I've learned a lot since going out on my own. I've also met a number of excellent mentors and peers who gave me their advice for writing along the way.

_Photo by [Unsplash](https://unsplash.com/@bradneathery?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText">Brad Neathery on <a href="https://unsplash.com/s/photos/write?utm_source=unsplash&utm_medium=referral&utmcontent=creditCopyText)

In this post, I want to share a few of the writing tips I regularly share with other software developers. These will help you get over the resistance that all new writers face and hopefully give you the confidence to start writing sooner rather than later.

1. Start by Writing About What You Know

“No one started off as a great writer. Start writing about the things you currently know and share them with the community. You'll be surprised how many lives you'll impact.” - Eze Sunday, Software Developer and Technical Writer

In order to become a better writer, you have to do it more often. This is true of any skill, but it can be especially hard with writing because you can't just string random words together on a page. You have to write about something.

The most common piece of advice for overcoming this barrier is to start writing about things you already know.

Daniel Phiri, who does Developer Relations at Strapi, told me, "Start with a problem you just solved no matter how trivial you think it is."

He went on to point out that even if the topic has been written about extensively already, your piece can be different. "Writing is about perspective and as unique as we all are as humans, so are our perspectives."

Eze Sunday reiterated this idea: "Yes, there are a lot of articles. But, there are not a lot of good articles that will explain things the way you would love it to be explained to you if you were just starting out."

2. Focus on a Few, High-Quality Pieces

"Quality trumps quantity," James Hickey told me. "Focus on writing high-quality articles vs. a bunch of ok articles...No one will be impressed when your content is just ok."

James is a senior .NET Developer, Microsoft MVP, author, and speaker with eight young children at home, so finding time to write is always a challenge. His solution is to be very selective about the writing he takes on, but when he gets into a topic, he goes deep.

You can see this in his work, like this one on e-commerce data models that hit the front page of Hacker News.

Diagrams from James Hickey's post on e-commerce data models

I've similarly found that some of my most popular blog posts are the ones that went really deep into a topic.

For example, one of the most popular pieces on my personal blog is this 4,500-word guide to API development. I'll admit, I write a lot of shorter pieces, but there's something to be said for being thorough.

3. Perfect is the Enemy of Good Enough

On the flip side, don't let your drive to produce the best content possible stop you from hitting the "publish" button.

Dan Moore, who runs Letters to a New Developer and Developer Relations at FusionAuth, offered up this suggestion:

"Perfect is the enemy of the good enough. To combat that, I like to timebox and then publish even if the piece isn't perfect...Maybe your post won't hit the front page of Hacker News, but I guarantee that if you don't publish it, no one will read it."

Many new writers get too caught up in the mechanics rather than the structure and organization of their ideas. To be honest, readers are more likely to forgive spelling and grammar errors as long as they can follow your logic.

Keanan Koppenhaver, CTO at Alpha Particle, told me that being overly reliant on perfect grammar might even hurt your work by making it sound too robotic:

“It's easy to get caught up in trying to make your writing the best it can possibly be: with perfect grammar, great sentence structure, etc. I've used tools like Hemingway Editor to make my writing 'technically correct' and when I re-read my work, it comes out sounding stale and like it was produced by AI.”

_Photo by [Unsplash](https://unsplash.com/@rocknrollmonkey?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText">Rock'n Roll Monkey on <a href="https://unsplash.com/s/photos/robot?utm_source=unsplash&utm_medium=referral&utmcontent=creditCopyText)

4. Set Aside Time to Write Regularly

“You’ll want to treat [writing] like any habit and set aside time. One thing I’ve found useful is to write first thing in the morning, maybe even get up a little earlier. I was not a “morning person,” but still found this to be when I had the most writing energy. Nothing else at that point has taken my mental energy.” - Adam DuVander, Founder of EveryDeveloper

I've said this before, but I'll continue to reiterate the point: in order to become a better writer, you have to do it more regularly. This looks different for everyone though.

Personally, I block writing time on my calendar every week. I found that I do my best work when I'm focused on writing for 4-8 hours rather than trying to cram it into little breaks throughout my day.

Of course, not everyone works the same way. Stephanie Morillo, a Technical Communications Specialist, makes writing fit into shorter windows.

"I use timeboxes: if I know I have to write a talk or a blog post, I'll set aside multiple 30-minute blocks throughout the course of a day or a few days and will sit down and write."

She pointed out that these smaller chunks of time are more realistic for her schedule and it allows her to make progress and increase her output: "If you write 10 words or 100 words or 1,000 words in a day, you're still making progress toward your goal."

Another strategy is to make writing a daily habit. Alex Lakatos, who runs the Developer Avocados newsletter, did a daily writing challenge for part of last year:

The point is that every person is different and there's no one-size-fits-all approach to setting aside writing time. "The biggest thing is finding a time where your brain can focus and has the creativity to actually get your thoughts down in a coherent way," Keanan Koppenhaver told me.

5. Manage Your Expectations

"It is, of course, nice to have your writing read by others, but there's tremendous value in writing for yourself, and you're guaranteed an audience. So, write for yourself first and foremost." - Dan Moore

It's hard not to get caught up in the thrill of having something you write go viral. I've published hundreds of blog posts in the past 10 years and just five of them have hit the front page of Hacker News. This is not an impressive hit rate.

This is why you should primarily be writing for yourself. You don't even need to publish things publicly as Stephanie Morillo pointed out to me:

“Keep a journal and write notes about work, your day, your life, your emotions. Journaling gives you the opportunity to write without being self-conscious because you're not writing with an audience in mind; you're doing it for yourself.”

Finally, it's important to keep your goals in mind when you start writing. Are you simply writing to record your own learnings? Are you trying to promote a book or course or product? Do you need to get paid to write or is it just for fun?

Adam DuVander pointed out that being honest with yourself about these expectations is critical. "Decide whether it’s a side thing or a main thing," he told me. "You can make either work, but you’ll want to set your expectations appropriately...There are a lot of ways to use writing in an engineering career."

Conclusion

As Brian Kofi Hollingsworth says above, you won't get better at something unless you start doing it. Whether you want to use writing to advance your career, make side income, or help others in the community, you have to start doing it more if you want to get better.

What tips do you have for software developers who are looking to become better writers? I'd love to hear from you on Twitter if you've got something to add!

In this article, I am going to provide some tips and suggestions for maximizing the impact of your email newsletter: open rates, click-through rate, and not irritating your recipients.

I will also share some technical details and configurations you can use to maximize the deliverability of your email newsletter.

How to Write an Impactful Subject Line

Your subject line is the first thing your readers will see when the email appears in their inbox. It's important, then, that you use something eye catching that encourages them to read the message.

What to Include in the Subject Line

Your subject line should provide a brief summary of the email content or highlight the key information. Some examples would be:

Learn Data Structures and Algorithms [free 6-hour coding course]

This headline comes from one of Quincy's email newsletters, and calls out the first article out of a weekly curated list of five articles.

Our Community Reached 3,000 Members - Here's What's Next

Here the headline provides a clear summary of the email's content – an update on the community's success and future plans.

The Observatory #4: Gravity is the key to community growth

Pulled from an Orbit newsletter, this subject line has two benefits: Like the others, it summarizes the content of the email. It also helps readers recognize this email as a serial newsletter, and track the number to ensure they have not missed one.

What to Exclude from the Subject Line

You want to avoid headlines which are vague, uninformative, or may seem like spam.

Click Here! Important Information Within!

Avoid words and phrases such as click here, urgent, important, and priority. These types of subject lines are often used in spam emails, and can cause your readers to disengage.

April 2020 Community Update

While this subject is not going to seem like spam, it is also vague and uninformative. You want your subject to catch the reader's attention and be unique.

Top Picks Just For You

Another vague subject line, this one also gives off a "click-bait" vibe. This type of subject line doesn't hook your readers or entice them in to reading your full email.

How to Craft an Effective Email Body

The body of your email is where your core content will go. Having a well written and effective email body is essential.

HTML vs. Plain Text in Emails

Using HTML in your email can make it look nice, certainly. However, HTML emails are more likely to be flagged as spam by the receiving providers.

Plain text emails are generally safer, though they offer less functionality. Additionally, a plain text email will ensure maximum compatibility with all devices, and ensure that your email can be viewed even over slower internet connections.

HTML, on the other hand, offers a much higher level of customization in terms of layout, content, and functionality. You can even implement things like interaction tracking to see who is opening (open rate), reading, and clicking on links in your email (click-through rate). Whether these features are worth the potential impact to delivery is or not is up to you.

How to Handle Links in Emails

Speaking of links, there are some special considerations when it comes to handling links in your email. The key idea is to keep your links easily readable and verifiable.

One important aspect is the transparency of your links. You want to avoid using things like URL shorteners that hide the domain the link points to. Keeping your link's target clear ensures that your readers can trust the safety of the link.

Many sending providers offer click-tracking features, where they will provide metrics on how many of your readers click the links within your email.

While these metrics may seem useful, they do come at a cost – usually the links are obfuscated through a redirect via the provider's domain. This decreases the chance that your readers will click the link.

Unsubscribe Links

If your email is considered commercial material (marketing, advertisements, and so on.), having an unsubscribe link is required. If it is a transactional (receipt, account updates) or relationship (communicating with existing contacts) email, then an unsubscribe link is not necessarily required but is still strongly recommended.

Having an unsubscribe link allows your recipients to quickly and easily opt-out of receiving future communications. While it may not seem ideal to lose your reader base, it is much better than having your emails flagged as spam (which can impact your sender reputation and cause future emails to anyone with that email provider to be blocked).

Your unsubscribe link does not need to be prominent or featured – a simple link with the text "Unsubscribe" at the bottom of your email is often sufficient.

Content and Layout of Your Emails

The content and layout of your email body are also very important. If you are using plain text to send your email, then your biggest consideration will be the length of your paragraphs. In general, shorter paragraphs are easier to read than a "wall of text", and will help your readers stay engaged with the content.

If you are using HTML, then you have some additional obstacles to consider.

For example, including images may seem very tempting as they can make the email look more visually appealing. But each image increases the time it takes for the email to render on the reader's device, and images aren't as accessible for those who use screen readers as plain text is.

Remember that images should add to the content, not detract from the information.

Another aspect to consider when using HTML is the semantic structure. To avoid any rendering errors or accessibility concerns, you will want to keep your HTML semantically correct. I recommend using an HTML Validator before sending the email to ensure you don't have any errors.

Content length itself is also important. You don't want to overwhelm your readers with too much information in a single email. If you have a lot of content you want to share, consider making a blog post or news article – then, link that article in your email with a brief summary of the content.

How to Sign Off in an Email

The signature of your email is just as important as the main content. Signing off your email lets your readers know who sent it, and gives you the opportunity to close out the content.

You should include your name and your role within your organization, so that your readers see that the email came from a person. This creates the impression that it is a more personal communication and not an automatically generated email.

Finally, the signature and conclusion also give you the chance to thank your readers for their time. It is good to recognize that your readers took time out of their day to read your content. Time is valuable, and your readers have given you theirs.

Technical Aspects of Email Newsletters

Now that you've drafted your first newsletter, you need to address the technical concerns. Namely, you'll need to figure out how you'll send this newsletter.

Choose a Sending Provider

The first question to answer is what will you use to send this email? It is entirely possible to set up and run your own Secure Mail Transfer Protocol (SMTP) server, but that can be a significant investment of time and resources.

Instead, there are a number of providers that will handle sending the emails for you. Here at freeCodeCamp we use SendGrid. Most providers will offer an API to request that emails be sent, or a UI to prepare your emails. Then they will handle the actual send process for you.

While these providers can get expensive at higher volumes, often times the cost is worth the access to additional features such as email validation and bounce report tracking.

Set up Email Authentication

Another important technical aspect is email verification and authentication, especially if you are using a custom domain.

How does a provider such as Gmail confirm that the email has legitimately come from your organization and not someone pretending to be you?

There are a couple of security steps you can take to ensure that your emails are delivered while spoofed emails are not.

• Sender Policy Framework (SPF): You can use an SPF setting to validate that the mail server is authorized to send emails from your email domain. SPF is enabled via a TXT record in your domain settings. The content of that record will depend on the system you are using to send those emails.

• DomainKeys Identified Mail (DKIM): You can use DKIM to assert that the email message has not been modified in transit from the sending server to the receiving server. DKIM records are set up in your domain settings either as a TXT record or a CNAME record, depending on your provider. These records will indicate the public encryption/decryption keys.

• Domain Message Authentication, Reporting, and Conformance (DMARC): The final step, after enabling SPF and DKIM, is to set up a DMARC record. The DMARC record tells email providers what to do if an email from your domain fails SPF or DKIM, where to send delivery reports, and how often to apply the DMARC policy. A DMARC record is added as a TXT record to your domain settings, as _dmarc.yourdomain.tld.

Congratulations. Now that you have read this article, you should have a basic understanding of how to create and send your first email newsletter. I hope you found this article helpful.

What are we talking about here? We're referring to your voice and your tone. These two aspects of your writing can have a strong effect on how people react to your articles, how much they enjoy reading them, and whether or not they'll get through the whole thing.

So let's talk about voice and tone a bit more to help you develop yours so you can write educational, encouraging, and interesting tutorials for the developer community.

How to Develop Your Voice as a Writer

When you're writing, there are a number of things that come together to create your voice. So what do we mean when we say "voice"? Well, it's how you sound when you write – the language you use, how you phrase things, your writing style, and so on.

As you write more and more, you'll develop a stronger, more distinctive voice. Think of your favorite authors, or one you might have studied in school. Sometimes you feel like you could recognize their voice if you heard them speaking. That's what you want to develop as a writer for freeCodeCamp's publication.

Your writing voice is something that you don't really want to change. Once you've established how you write, try to stay consistent and keep writing in that style. That way, readers know what to expect when they read your articles and they'll feel comfortable with the way you write.

And here's something to keep in mind: the people reading your articles will often be learning to code, learning a new skill, looking for a job, or trying to level up in their current position.

Many of these readers are busy adults who have other jobs, families, and full lives outside of learning to code. So you want to engage them, welcome them into your article, and make them feel comfortable and interested.

Here's one more important tip about voice: it's usually better to write in active voice rather than passive voice. This gives the agency to the doer of the action, and it's a more powerful way to write.

So instead of saying something like "Now the project can be deployed", say "Now you can deploy the project". This keeps the focus on the reader and makes it clear that they're the ones doing the action.

If you want to read some articles by authors who have developed very strong voices, check out Colby's articles and Estefania's articles. These are just a couple examples – many freeCodeCamp authors have successfully found their own clear voices (and Quincy, freeCodeCamp's founder, has one of the most recognizable writing voices of all).

An example of active vs passive voice

Let's look at another example of how to use active voice in your writing. Here's a paragraph that uses a lot of passive voice. See what it sounds like when you read it aloud:

For aspiring web developers, HTML, CSS, and JavaScript should be studied. Once courses are taken, articles are read, and projects are built, the subjects will be learned thoroughly. It's especially important to build things with the skills you're learning, because that allows the knowledge to be cemented in your mind.

Instead of writing something like the above (which, admittedly, went a little overboard with the passive voice for demonstration purposes), try something like this:

If you're an aspiring web developer, you should study HTML, CSS, and JavaScript. After you've taken some courses, read some articles, and built some projects, you'll learn these subjects thoroughly. It's especially important to build things with the skills you're learning, because it will help cement that knowledge in your mind.

Why is this better? Well, first of all it uses action verbs and places the reader at the center of the action (the reader is often the subject). The language is also more powerful and direct, and it flows more naturally and isn't stilted or awkward.

How to Think About Tone in Your Writing

Tone is a bit different from voice, as it can change depending on what you're writing, who your audience is, and the feeling you're trying to convey.

If you're trying to sell a product, for example, you'd want your tone to sound authoritative, hopeful, maybe a bit intriguing – because you want people to trust and want to buy what you're selling.

If you're telling a story of a personal accomplishment, you want your tone to sound joyful, celebratory, expansive, and confident – but not boastful or hubristic. After all, you want to impart that feeling of success while still encouraging others and lifting them up with you.

If you're telling the story of how you got your first job in tech, you might sound excited and encouraging. If you're explaining how to use some particular syntax in Python, you might want to sound practical, informative, and engaging.

This is not to say you can't use different tones in the same article. Even if you're writing a deep technical guide, you can still bring in some levity and humor to keep readers engaged.

An example of how to use different tones in your writing

Let's look an example of a couple short paragraphs that display different tones.

First, let's pretend that you're writing a React tutorial, and you want to sound authoritative, knowledgable, and encouraging. You might write something like this:

In this tutorial, I'm going to teach you all the basics of React so you can use it confidently in your projects. You'll learn all about state, hooks, components, and other foundational React concepts. By the end of this article, you'll be able to build your own React app with x, y, and z features.

Pretty straightforward and to the point, but it provides clear information, tells the reader what they'll be able to accomplish, and gets right down to business.

How about an inspirational or personal story – what should that sound like? Well, you'll want to make sure you sound conversational, approachable, and engaging. Why would your reader care about your story? You want them to be able to relate to what you're saying and feel connected to it. Something like this:

When I graduated college, I knew I wanted to go to grad school to study archaeology. So I did – but things didn't turn out as I planned. After a couple career twists and turns, I found freeCodeCamp, started volunteering as an editor for the community's publication, and eventually got hired on full-time. Here's how it happened.

Hopefully this would make you curious and draw you in so that you would keep reading.

How to Choose the Right Tone for freeCodeCamp's Publication

When writing for the freeCodeCamp community's publication, your tone should stay positive, encouraging, and helpful. Avoid sounding disparaging and negative, as that sort of writing doesn't have a place in News.

Here are some tips to help you develop a helpful and positive tone in your articles.

Write like you're talking to a friend

When you're explaining a technical concept, pretend you're talking to a friend. Imagine how you'd explain it to a buddy or colleague, and then write that down. While it might need a bit of editing to tighten it up, this is a good start.

You probably wouldn't yell at your friend or make them feel stupid. You'd think about how to break the concept down into understandable chunks so they could learn and retain it. Then you'd explain and describe that concept in plain language you'd use in everyday conversation.

If you approach your articles in a similar way, it will help you keep your writing casual, simple, and relaxed. The publication is not an academic journal, and you don't need to be overly formal in your writing. Make it approachable and friendly when you can.

Even though it's best to keep your language simple and straightforward, it's helpful to maintain a basic level of professionalism and polish. After all, you want people to take your articles seriously and recognize them as helpful and insightful resources. So avoid too much slang, informal speech (keep the "LOLs" to a minimum), and so on.

But again, don't be afraid to use humor when it's appropriate – everyone can use a little chuckle now and then. And when you're reading through a long technical tutorial, sometimes the best mental break is a quick laugh. Don't force it, but if it comes naturally to you, let it flow.

So how should this language look? Well, for the most part it looks like the language in this article. Whenever a freeCodeCamp team member writes an article for our community's publication, we try to maintain a similar tone – generally casual, authoritative, positive, and helpful.

Use "You" Instead of "We"

When you're writing a step-by-step tutorial, it's easy to want to involve yourself. You might say "First, we need to install VS Code, since we'll use this as our code editor." But "you" is a powerful word, and it's more effective to use "you" than "we".

Just think of it as giving instructions directly to your reader – "First, you need to install VS Code, since you'll use this as your code editor." It's more direct, and focuses the reader on what they're doing. After all, you hope that they're coding along with your tutorial.

You can use "we", of course, if it's appropriate for the context – just don't overuse it, especially in step-by-step guides.

And on a related note, don't use "one" as a pronoun (like "To do this, one has to add the following code..."). It's overly formal and stilted, and can be a bit off-putting for the reader. Instead, always use "you" (or in rarer cases, "we", as discussed here).

How might this look in a more extensive example? Compare this:

Alright, today we're going to build a Twitter clone. We'll go through all the steps we need to build the app, and in the end we'll have a fully-functioning social app. We won't get into the details of x or y, as they're a bit out of our scope. But we'll learn everything we need to know to finish the project.

With this:

Today, I'm going to teach you how to build a Twitter clone. You'll go through all the steps you need to know to build the app, and in the end you will have a fully functioning social app. We won't get into the details of x or y, as they're a bit out of the scope of this tutorial. But you'll learn everything you need to know to finish the project.

You can see how the emphasis is on the reader in the second paragraph - "You will do this", or "You will learn" and so on. This makes the reader think of themselves, what they can do, what they're learning, and what they're getting out of the tutorial.

It's implied that you're going to walk them through it – so you don't need to include yourself with "we" unless it's a general statement about circumstances or something similar (how I said "We won't get into the details of x or y..." above in the second example).

Keep it positive, and relatively PG

freeCodeCamp is a friendly, welcoming, and inclusive community. The free resources we provide are open to everyone everywhere, and we want to make sure our articles, tutorials, and videos are accessible to all.

Because of this, we want the articles we publish to be free from negative language, gatekeeping, overly sarcastic language, and any hurtful or offensive remarks. The articles we publish on the publication are meant to be educational, inspiring, helpful, and encouraging – so your tone should reflect that.

No one should feel stupid or embarrassed when reading your articles. They should feel inspired, curious, and ready to dive in deeper.

Even if your reader is a complete beginner and might be in over their heads, your tone and language shouldn't discourage them or turn them away. Help them know what to expect by writing a clear introduction to the topic, laying out any prerequisites or requirements you have of them before they start, and so on.

And finally, it should go without saying that there's no room for hate speech, racism, bashing or belittling others, swearing, or trolling in the freeCodeCamp community. So keep all that out of your writing.

Let's see an example of how NOT to write:

If you want to understand Redux, you need to be smart. After all, it's hard, especially for people who don't have a CS degree. Older devs might not understand Redux, either, because they're just not mentally quick enough.

Obviously, you'll need to go through tutorials and courses and build a project with it to learn it thoroughly – duh. Just don't be an idiot and skip the fundamentals.

Ok – DON'T write like that! I hope it's clear why this is overly negative, condescending, gatekeeping, and just generally offensive.

Remember – keep it positive, encouraging, clear, and educational!

Thanks for reading, and happy writing!

Want to know more about how to craft a great article? The freeCodeCamp community's publication has a Style Guide full of writing tips and publication guidelines.

Technical writing helps you share your technical knowledge and experience with others. It also helps you reinforce your knowledge of the topic you're writing about while demonstrating your technical abilities and talents.

In this article, I will explain what you need to know to become a technical writer. We'll learn about what technical writing is, the skills you need, how to become a technical writer, and tips to help you become really good at it.

What is technical writing?

We can define technical writing in a number of different ways. But the definition by Grammar is the most helpful and explains exactly what technical writing is all about:

"Technical writing is a type of writing where the author writes about a particular subject that requires direction, instruction, or explanation."

Simply put, technical writing involves straightforward, easy-to-understand explanations of and instructions for a particular subject.

What skills should technical writers have?

A common assumption among many would-be writers is that they can't write well because they were not born with the gift or skill of writing. This raises the question: are writers born or made?

I was curious to know what other people thought about this popular myth, so I tweeted about it.

It was fascinating to read everyone's opinion on this popular myth. Most people said they believe writers were born, while others disagreed and said writers were made. Interestingly, another set of people thought writers were both born and made. Crazy right?

I am sure you are curious to know what I think about this, so I will tell you. 😉

I believe that anybody, whether born with some sort of innate ability or not, can learn how to become a great writer. I know that I wasn't born with the gift of writing, so I decided to be more intentional about learning how to write.

Truth be told, most of the technical writers you see today likely had to develop or learn specific skills to become good at writing.

Now to the point 😃, here are five essential skills you should develop to be a successful technical writer:

Know How to Write

I know it might be confusing to see that writing is one of the skills required to be a technical writer. You might think that technical writing and writing are the same, but they are not.

Think of writing in general as the process of using symbols (letters of the alphabet, punctuation, and spaces) to communicate thoughts and ideas in a readable form. Technical writing, on the other hand, is the more specific process of sharing or conveying your ideas, views, instructions, and suggestions logically and technically.

The first and most important skill every technical writer needs to be able to write in their preferred language for communication. For example, if you intend to use English to write technical articles, you need to understand how to compose words and communicate with the English Language.

Want to get better at writing? Follow the steps below:

• Learn the grammar and language rules for your preferred language for communication.
• Understand the power of illustrations in writing.
• Read more! Trust me, reading will help you expand your vocabulary.
• Most importantly, write using your preferred language of communication.

Know Your Audience

Identifying, understanding, and tailoring your content for a specific audience will make your articles or documentation stand out. That's why you need to know your audience.

When you understand the audience, you will be able to tailor your article to meet their needs and automatically pass the message effectively.

So, how can you get to know your target audience?

Ask yourself questions about your readers

You need to ask yourself questions like: "who are my readers, and why are they reading the article? What do they expect from it?"

For instance, before I started writing this article, I asked myself these questions and came up with the answers below:

• Who are they? People that want to become technical writers
• Why are they reading this article? To learn the necessary skills needed to become a technical writer.
• What are they expecting? Everything they need to get started and eventually become technical writers: skills, tips, steps, advice and more!

Once, I figured out the answer to these questions, I was able to identify my audience, and it was beginners. This helped me tailor this article to benefit you.

Use the right terms

If you are writing an article for beginners, you should use terms that are easy to understand. You can also add concrete examples to help your readers understand you.

Give your article or documentation a helpful title/name

Name your articles in a descriptive and helpful way.

For example, don't name an article “A Deep Dive Into Understanding React” (when the content is about Rendering Elements in React), and risk disappointing readers who were expecting to learn everything about React after reading your article.

Instead, come up with a specific title that describes exactly what you wrote in your article like “How to Render Elements in React”.

Develop Your Technical Skills

As a technical writer, your goal will be to help readers understand highly complex processes or concepts in a straightforward way.

To achieve this, you'll need to be familiar with the topic you're writing about. That means if you want to write a technical article or documentation on React.js, you should be able to use React personally.

I'll end this section with this popular quote by Albert Einstein:

If you can't explain it to a six-year-old, you don't understand it yourself.

This quote also echoes the need to understand the technical details of your topic thoroughly before explaining it to someone else.

Be Able to Do Good Research

Yes! Technical writers don't know everything. So even though you might be familiar with a technology, sometimes you'll have to research a language or framework to understand it better before you start writing about it.

This will make sure that your text is accurate and communicates the necessary data most efficiently. You definitely don't want to be sharing false or confusing information.

How should you go about conducting research?

Researching involves asking questions on your preferred search engine, reaching out to someone who is knowledgeable about the subject matter (if you know any), or reading a book.

If you decide to follow the search engine route, ask questions targeted at what you want to discover. For instance, if you want to learn about how to use the GSAP ScrollTrigger Plugin in React, your question should follow this format "How can I use GSAP ScrollTrigger Plugin in React".

If you decide to ask someone knowledgeable about the subject matter, always be polite and go straight to the point. Instead of saying "Hi" and waiting for the person to respond before asking your question, you can follow this format:

"Hi Rita, my name is Edidiong. I know you are very knowledgeable about using the GSAP ScrollTrigger Plugin. I have seen some of your CodePen demos over the years and they all looked really amazing. I'd love to know how can I manipulate the GSAP tween to make the animations trigger on the scroll? I'd totally understand if you can't respond because of your busy schedule but I will be glad if you do."

You might think that this was a pretty long message, but it covered the most important things: your name, your admiration of their work, what you need, and that you understand that you are not entitled to the person's time.

There's also an option of reading a book during the research phase. To do this you can go to a library or find a book online and read it.

Develop a Unique Voice

Have you ever wondered why people drop comments like "wow, I've finally understood this concept thanks to your article" or "I read other articles but I didn't understand this concept until I read yours, thank you!" on an article?

If you ask me, I'd say its because the author's unique voice spoke to them in a way others didn't.

What does this mean? It means everyone is unique.

So, if two devs write about the same topic, some readers will understand one of their articles more than they understand the other. While others will understand the second article more than the understand the first. Why? Because they both have a unique voice that will work for some people and not for others.

So, how can you develop a unique voice?

By staying true to yourself, and letting your thoughts flow freely as a writer instead of copying other writers' content. Yes, get inspired by others. But don't forget who you are!

The truth is, people learn in different ways and your content might be what one developer is hoping to read before they finally understand a concept.

Now that we've discussed the basic skills you need to become a good technical writer, I should point out that these skills can be learned over time. Please don't wait until you have all of them to start writing – go ahead and give it a try.

How to become a technical writer

Now, let's talk about how to become a technical writer. 💃🏽

The secret of getting ahead is getting started.  - Mark Twain

Yes, I had to start with Mark Twain's quote because it is something we all need to remember when we take up a new challenge. Deciding to become a technical writer is great, but putting in the necessary work to get started is even greater.

Let's talk about four important things you need to do to become a technical writer.

Take a course in technical writing

Technical writing is an in-demand skill, and employers want to hire the best writer for their team. Taking a course on technical writing is highly underrated, but it is essential because you will discover many tips that will help you become a better writer.

My technical writing skills significantly improved after I took a technical writing course from Google, and I highly recommend you take the course (or something similar) as well.

Read books and tech articles

Read a thousand books, and your words will flow like a river.  - Lisa See

Reading is essential because it will help you enrich your vocabulary, keep you abreast of current trends, discover what's going on in the writing world, and also helps keep the spirit of writing alive.

For this, I highly recommend reading tech-related articles from sites on freeCodeCamp, Hashnode, The Writing Cooperative, and others.

Start writing

You learn to write by writing, and by reading and thinking about how writers have created their characters and invented their stories. If you are not a reader, don't even think about being a writer.  - Jean M. Auel

Even if you take all the technical writing courses and read all the tech articles you can find, that won't make you a writer. You need to actually write to be a writer.

You might be wondering how you can actually start writing. Well, I'll tell you.

First, you need to think of a topic you want to write about. Then you should carry out the necessary research, write a draft of the article, and proofread the article (more than once). When you're ready, you can finally publish the article on your blog.

You don't need to build your blog from scratch because it takes a bunch of time and will distract you from your actual focus, which is writing. In my case, I created my blog with Hashnode because it is super fast, has a strong community, and allows you to map the blog to your domain.

After you've gotten comfortable with writing, you can apply to become a guest author on freeCodeCamp. If you get approved, you can publish articles on the platform and reach a wide audience.

Stay consistent

Writing consistently plays a huge role in helping you become a better writer. It unlocks your productivity, transforms your perspective, and builds your confidence.

You don't start out writing good stuff. You start out writing crap and thinking it's good stuff, and then gradually you get better at it. That's why I say one of the most valuable traits is persistence.  - Octavia E. Butler

Just like every other skill, you get better at writing when you keep writing consistently. Aim to write at least one article every month, and you will be shocked at how your writing skills will improve if you keep doing it consistently.

If you need some accountability with your consistency as a technical writer, you can try the #2Articles1Week Writing Challenge.

What is the #2Articles1Week Challenge?

The goal of this challenge is to encourage technical writers to define their writing goals, understand writing standards, and most importantly become consistent at writing.

Participants are expected to publish a minimum of 2 articles per week for 4 weeks on their blog. If you do this, you will be able to create and publish 8 articles on your blog in just one month. Amazing, right? 😉

I've seen a lot of people talk about the benefits of participating in this challenge and I believe it will help you kick off writing consistently.

Contribute to Open Source projects

The documentation for Open Source projects is arguably just as important as the software itself. So if you're a technical writer, you can contribute in a significant way to a project because humans can't use what they don't understand.

Yes, you may be working on a project or for an open-source organization for free. But Open Source contributions can help you improve your writing skill, expand your network, and help you get recommendations and referrals from the maintainers.

It can also help increase your chances of getting accepted into the Google Season of Docs program.

What is Google Season of Docs and why is it important?

Season of Docs is an annual program organised by Google. Its goal is to bring technical writers and open source organisations together to foster collaboration and improvement of documentation in the Open Source space.

This initiative is extremely important because the documentation of an Open Source project provides an avenue for users to not only understand the project but also make contributions to it.

During the program, accepted technical writers spend between 3-5 months either building a new doc set, improving the structure of the existing docs, developing a much-needed tutorial, or improving the contribution processes and guides of an Open Source organisation.

The interesting thing about this program is that you can get paid between $3000 - $15000 to contribute to Open Source projects as a technical writer. You'll also stand a higher chance of joining the Technical Writing team at Google and possibly get retained by the Open Source organisation to keep working as a technical writer after the program is over.

6 Technical Writing Tips to Help You Start Writing

Here are some things to remember when you've completed your first draft your next article:

• Follow a style guide when writing. It helps you stay on track and follow the best writing principles.
• Make your paragraphs short so they support a single idea. Don't cram everything into one paragraph.
• Write short, clear, and precise sentences because simplicity is the ultimate sophistication.
• After writing your first draft, read your content out loud while assuming you are the reader. This will help you spot things that can be rephrased.
• Edit your first draft only when you are focused.
• Seek feedback by consulting with experts in the field you are writing about because no technical writer knows every technical detail about every topic.

Summary

Technical writing continues to be a highly coveted skill in the professional workplace. Demand is expected to grow at least 10% from 2014 to 2024.

Writing, like many other crafts, takes years of practice to hone. The best part of writing is that you can see your improvement. You can look at your previous works and see how much better you've gotten over time if you work at it.

Also, technical writers have the great benefit of becoming lifelong learners because they need to be well-versed in whatever field or topic they are writing about to communicate the content clearly to readers. I strongly encourage you not just to start this journey but also to stay consistent with your writing as well.

That's all, folks! I hope this was helpful? If yes, follow me on Twitter to access more contents like this.

Publishing articles and creating video content are great ways to share what we learn as developers. You may have your own blog or you may write for a publication. In either case, you should follow specific processes to write well and feel great about it.

This article will cover the fundamentals of blogging to help you write great articles while not dropping the ball as a developer.

TL;DR

This tweet summarizes most of the points at a high level. However, we will talk about some real-life experiences and learning how to blog in more detail. Please keep reading and enjoy.

Know your purpose

Know your purpose

We all need a purpose when we start something and the motivation to continue it. The intent behind our actions and our motivation may be different for everyone. You need to find your intent or purpose that explains why you want to start a blog or share your content.

In most cases, the simple answer could be Passion. Fair enough! It could also be a business strategy, or perhaps you want to teach others. Maybe you want to keep learning – practically anything that gets you started will work.

As a developer, we learn something new all the time. It is close to impossible to memorize every piece of what we've learned. When we document those lessons and bits of information, we might as well make that knowledge reusable.

This is why writing an article about something you've learned recently is an excellent idea, and gives you very clear intent for your progressive documentation.

💡 Tips: Create a private GitHub repo with a markdown file. When you encounter something new, add a note about it (with code, if needed) in the file.

The contents of this file will then become an excellent source for your future articles. I maintain a file called TIL_2021.md (Things I Learned in the year 2021) for the same purpose.

When I decided on blogging, I intended to learn by sharing knowledge. If you want to learn something deeply, start teaching it. Blogging is a great way to do that.

Find Your Motivation

Do not give up, stay motivated

Motivation can do wonders when you have it, but it can be hard to continue without it. As a content creator, your biggest motivation is likely to hear feedback from your readers. Positive feedback and constructive criticism always help you improve the content you create.

But there is a problem. Initially, you may not have very many readers to give you feedback. The chances of disappointment are higher if you are an individual blogger. So it helps to have a lot of self-motivation to sustain and continue your work.

Remember – do not give up, stay motivated. As a developer, you have plenty to learn, share, and write about.

💡 Tips: If you want to start blogging as a developer, the developer community is helpful to stay connected and motivated. There are many incredible communities around like Hashnode, Dev.to, Codenewbie, Hackernoon, freeCodeCamp, GirlsWhoCode, and many more.

Do Your Research

Research is the key. Content rules all.

In blogging, content rules all. As developers, we may have multiple ideas, problem-solving steps, and new learnings we want to get down. But the most crucial part is being able to turn it into quality content. It's usually necessary to take the time required to research your topic thoroughly.

Let me take an example of content research here. Say you have solved a problem using Linked List, and it is the first time you have used one. You are so excited that want to share what you've learned. Here are a few points to consider:

• You need to understand Linked List generically and beyond the context of the problem you have solved.
• You need to understand both the pros and cons of using Linked List.
• You need to set up a few examples that demonstrate how best to use it.
• You need to make sure you explain the way you've solved the problem clearly so people can use it in their own use cases.

💡 Tips: Once you figure out what you need to know, you can learn about it from any well-established resource. Perform a search wionth Google, Quora, Reddit, and so on. Stackoverflow is another excellent platform to check for info on the topic as well.

Make sure you note down what you learn as you make progress. These notes will eventually turn into the article you write and publish.

Plan the Content Structure

Plan the content structure

Once you have your content research done, the next thing is to plan the structure of the article. Excellent article content can go ignored by readers if you have an inadequate and messy content structure.

Here are a few tips to help you structure your article content in a readable way:

• Title: A compelling title can help influence many readers to visit your article. No matter what, people hardly miss reading the title of the article. Keeping it catchy will increase the traffic to your content.
• Cover Image: A relevant cover image makes your article very attractive. When you share your articles on social media like Twitter, Linkedin, or Reddit, a creative cover image may attract your readers.
• Introduction: this section describes the content at a high level. It can be an initial paragraph or a Tl;DR section explaining what you plan to cover in the article.
• Headings and Sub Headings: You should break the content into logical sub-topics. To do that, create sections and provide relevant headings and sub-headings. For example, I have created multiple sections with headings like Know Your Purpose, Find Your Motivation, and so on in this article.
• Graphics: "A picture is worth a thousand words." This is often true, so think of supporting your content with some graphs, pictures, and so on.
• Summary: A summary section at the end helps your reader recap what they have learned from the article so far. It is also helpful for a returning reader to recollect the content by going through the summary.
• Important Links: You may want to end your article with a list of related links for further reading. You can use the same section to list the links to your previously published articles as well.

💡 Tips: Try to use a consistent content structure for your articles. Your readers will get used to it and find it easy to follow.

Writing Tools

Using tools to make you efficient and smarter

Creating quality content takes time. You can make yourself a productive and efficient content creator by using some of the tools available for free. Here are a few that you may find helpful,

⚒️ Notion: this tool can help you manage your personal and professional work TODOs in an efficient manner. Anytime an article idea occurs to you or you solve an interesting problem, create a task in the tool. You can prioritize, schedule, and assign tasks with ease.

Task planner with Notion

⚒️ Grammarly: If you are a non-native English speaker like me, there are times when you might not be familiar enough with the language's grammar rules.

In this case, a tool like Grammarly is a life-saver in many ways. It detects grammatical and spelling mistakes, suggests re-phrasing for complex sentences, corrects passive to active voice, and more. You can start with the free version and go for the premium based on your usage.

Correction suggestion with Grammarly

⚒️ Hemingway Editor: This is another excellent tool to support you with your English writing. You can use this editor along with Grammarly if you want. I love the way it indicates inadequate use of adverbs, active/passive voice, and complicated words and phrases.

Categorized suggestions with the Hemmingway Editor

⚒️ Canva: Canva is a tool where you make designs, art, and unleash your creativity. You can create cover images, article graphics, animated gifs, and more without any prior experience with Canva. The generous free plan is sufficient to get started.

Create and organize your creativity using Canva

⚒️ Pixteller: This is an alternate suggestion for creating cover images, graphics, and so on.

Pixteller to create images

⚒️ ShareX: It is a super cool productivity tool for screen captures, making animated images, file sharing, and so on.

Create, gifs, screenshots, videos

⚒️ OBS Studio: this is a free, open-source video recording and streaming tool. You may be wondering, why do I need this for blogging?

At times, you may want to create a video, upload it to YouTube or Vimeo, and link to it from your articles. You can use the OBS Studio tool to create quality videos with lots of customization options.

Create high quality videos

⚒️ SERP Snippet Generator: SERP (Search Engine Result Page) is the page we see after entering a query into search engines like Google or Bing. A SERP snippet generator helps you finalizing a suitable title and meta description of your article post before you publish it.

See the image below to figure out a title and description within a limit to show the search result correctly.

SERP Generator

Do Lots of Proofreading

Review, re-review, re-re-review, and so on...

When you write something, you need to check for errors and get your article reviewed before publishing or sharing it. This process of checking and making sure your content is ready to publish is called proofreading. In general, you should check for:

• Spelling errors
• Grammatical mistakes
• Formatting issues
• Punctuation
• Accuracy
• Language Consistency

When it comes to proofreading and reviewing, here is a famous quote for some inspiration:

“I've found the best way to revise your own work is to pretend that somebody else wrote it and then to rip the living sh*t out of it.” ― Don Roff

Publish Your Article

Don't keep it to yourself, just publish it

If you are happy with the article after your proofreading, the next logical step is to publish it. You may want to schedule it to publish on a particular day of the week, or you may want to publish right then – it is up to you.

As a general principle, it is better to publish when an article is ready from your side. Similarly, you should never rush to publish an article to meet a deadline.

💡 Tips: Publishing your article should be part of the entire plan. If you have to publish an article by a specific date, work backward to plan the content accordingly. Do not compromise the quality of the content in the rush of publishing it.

Share Your Article on Social Media

Social media platforms are a big booster

Social media is an extremely powerful tool. And you should make positive use of it as a blogger.

Publishing your article may not be enough if you want it to reach as many potential readers as it can. It's therefore a good idea to share your article on various social media platforms.

Here a few platforms where you should share your article links:

• Twitter
• LinkedIn
• Reddit
• HackerNews
• FaceBook

There are a few more platforms where link sharing alone may not work very well. You can create a cover image/graphic suitable to the topic and upload the image (and share the link) to places like Instagram and Pinterest using the right hashtags.

💡 Tips: Make sure you follow the policies and guidelines specified by each social media platform when you share your blog link. If you don't, your account could be flagged or banned.

Another exciting way to share your content is by republishing it. You can republish your article on another blogging platform if you are allowed to do so. For example, an article written on the Hashnode platform can be republished on the Dev.to platform and vice-versa.

💡 Tips: You can set the Canonical URL to the link of the original article when you republish it. This is a way to tell the search engines like Google which is the original copy of the content and eliminate duplicate content.

Good Blogging Platforms

A Blogging platform to get you started

Alright, now we know how to write an article and share it so others can read it. Now let's learn about a few blogging platforms where you can get started.

Here are a few platforms to start blogging and grow as part of the community.

• Hashnode
• DEV Community
• freeCodeCamp News
• HACKERnoon
• daily.dev
• Codenewbie Community
• Educative Edpresso Shorts
• CoFoundersTown

There are many publications and organizations who hire and pay content creators. As a developer-blogger, this may open up many freelancing opportunities and let you get compensated for sharing your content. You can also contribute to open-source documentation and other projects.

In Summary

To summarize,

• Blogging as a developer is manageable as a side activity without compromising your work output.
• Problems you've solved and your searches on Google, Quora, and Stackoverflow could be a helpful source of writing ideas.
• Find your purpose before you start a blog and write articles. The intent behind your work can be trivial or more significant – either way is fine.
• Stay motivated.
• Use the right tools to make you a productive writer.
• Plan your content structure, proofread your articles, and publish them.
• Use social media as a tool to share your articles.
• There are some fantastic blogging platforms out there. Give them a try and be part of the developer communities.
• Keep learning, keep writing, and keep sharing.

Before We End...

I hope you've found this article insightful, and that it helps you start using these concepts more effectively in blogging.

Let's connect. You will find me active on Twitter (@tapasadhikary). Please feel free to give a follow.

You may also like these articles:

• How to find blog content ideas effortlessly?
• Where to begin? Some practical tips from a beginner
• Why do you need to do Side Projects as A Developer?
• 16 side project GitHub repositories you may find useful
• How to Learn Something New Every Day as a Software Developer

In my time building and devising products – apps, websites, and graphics makers – I have come across two types of people in general: those that prefer qualitative narratives and those that prefer data and analytics.

The first group is comfortable framing product development in the context of more subjective user feedback and perspectives. The second group, wary of this approach, wants to apply “excel models” to work backwards from numbers.

For ease of categorization, let’s call the first group “storytellers” and the second group “quants”.

Both groups want to construct meaningful product visions, understand users, and build tools at scale. Both groups are well intended but have a different approach to leveraging insights to make decisions.

Yet the way they go about collecting, analyzing, and deploying these insights varies.

It is likely useful to pause for a moment and ask yourself which camp do you more readily side with? Are you more of a storyteller or a quant?

Regardless of the answer, there is a unifying approach that I believe can bring these two personas together and help them find common ground in the pursuit of building better, more well thought out products.

And that approach is through writing.

Why writing is critical to product design

Writing is defined as the activity or skill of marking coherent words on paper and composing text. Learning to write starts with foundational principles: you must learn an alphabet and how to organize letters to make words.

These words, in turn, are then placed together to make sentences.

Sentences, when taken together, can start to convey deeper meaning.

Writing is a forcing mechanism. It makes us think deeply about what we want to communicate and why.

Writing helps us focus on what is most important.

And writing – when done well – mitigates obfuscation.

How many times have you seen a product presentation and been convinced about its merits due to the quality (both good or bad) of the presenter? A charismatic argument, for example, can mask what really matters to users and sway judgements.

Amazon founder Jeff Bezos once wrote:

“Powerpoint-style presentations somehow give permission to gloss over ideas, flatten out any sense of relative importance, and ignore the interconnectedness of ideas.”

Writing forces us to see what really matters: the strength and coherence of an argument and how that argument is supported or substantiated by evidence.

Product development is inherently messy because oftentimes products, even if they appear simple, are inherently complex.

This is true for both hardware and software. Massive complexity exists in common items we take for granted.

Lufthansa claimed that it took 6 million parts for Boeing to build the 747-8.

A simple drive-off-the-lot car might have 30,000 parts.

By some estimates the Android operating system runs on 12-15 million lines of code.

The Large Hadron Collider uses 50 million lines.

Not including backend code, Facebook (the front end and various landing pages) runs on 70 million lines of code.

Well-structured narrative text (as opposed to bullet points or plain text) can help the writer or product designer explain the “why” behind an argument.

Strong and active writing forces more reflective thought and a better understanding of what’s most important and how things – parts, people, plans, budgets, product – are related.

Lastly, writing helps create an even playing field.

All too often ideas (and how or who explains them) can lead to bias. Imagine being given a memo advocating for a product feature or Go To Market plan and you knew nothing of the author, including their background, role, or team.

And all you were allowed to do was evaluate the quality, durability, and clarity of the author’s words. This might lead to better business outcomes and product design decisions.

How to get better at writing

Writing is a skill that can be improved through practice. I remember in 5th grade my mother sitting down with me and using a red ink pen to edit and correct an essay I had written for homework.

Editing words is not easy. It wasn’t fun then and more than two decades later it's still not always fun. But by chipping away at it, we can embrace writing and get better at it.

The old expression “practice makes perfect” certainly didn’t apply in my case. Nevertheless, by forcing myself to write frequently, I was able to improve.

If you are building products and want to use written words to share your vision, win over internal stakeholders, and help communicate more effectively, there are a few things that you can start doing today.

Create an outline

Firstly, you can take out a piece of paper or open an online document, and start building an outline of what you want to communicate. Lead with they why.

You can use an outline to sharpen your thoughts and sketch out your product vision.

Try different types of writing

Secondly, you can play around with fun and different ways of writing to communicate about your product.

For example, you can write a press release. What would the New York Times say about your product if you were a journalist writing for the technology section?

Writing a futuristic press clipping is fun, gets the creative juices flowing, and is an enjoyable way to think through how others might see what you are building.

Jot down some FAQ

Thirdly, you can improve your product writing skills by drafting and completing Frequently Asked Questions (FAQs). What do people not understand about your product and why? Try to think through the questions users have and answer these questions.

The benefits of writing out FAQs are two-fold: you can improve your writing while also more deeply understanding those aspects of your product that users might struggle with. And as a result of this insight you can preemptively solve these problems.

Bringing It All Together: Writing and Product Design

At the beginning of this article I described “storytellers” and “quants”. These two groups represent different approaches to using inputs (data, numbers, feedback, credentials, and so on) to draw conclusions and make inferences.

Writing can bring “storytellers” and “quants” together and provides a level playing field for the expression of ideas.

Writing helps us avoid premature optimization.

While writing might be a challenge for you today, it is worth practicing. If you need prompts to get started try outlining the future of the gig economy or futuristic trends in mobile apps.

If you don’t write about the future state of your products, you should start. It will help sharpen your thinking and enable you to build for better outcomes.

In the end of the day that should be the North Star for all builders.

It's how you convey your ideas, influence people, advocate for your skills and pay raises, as well as produce comments and documentation to assist others.

“What many people underestimate is that being a good writer,
whether that is through emails or through documents, allows you
to be more impactful. I see many engineers ignore that skill.

You might be proud about your code. You should also be equally proud
of the craft of writing… Writing is a highly underestimated skill
for engineers.” –Urs Hölzle (Google’s first VP of Engineering)

Writing can:

• Impress future employers
• Help you solidify what you recently learned
• Share insights to other developers
• Save others the pain of hours of research

freeCodeCamp can really help develop your writing skills too. They can help give you ideas based on what people are searching for, and they proof-read and edit your writing to make sure everything is explained well. Then they help publish it to a wide, diverse audience.

All this is done by the Editorial team and they're all really friendly and (most importantly) really useful. As you write more articles, you will learn more about who everyone is and how they can help you.

I'm going to briefly explain how I started writing for freeCodeCamp and my experience with it so far. We'll also touch on freeCodeCamp's publication style guide which you can find here.

Who writes for freeCodeCamp?

There are all sorts of people who write for freeCodeCamp.

Some are professional teachers who run programming courses, some are indie developers, some are still learning programming, others are full-time employed software engineers...and the list goes on.

There are people from all different places in the world who speak many different first languages – lots of voices are represented on freeCodeCamp.

There are no hard prerequisites for becoming a contributor to freeCodeCamp News. They don't check whether you have a Computer Science degree (in fact, many self-taught programmers write articles on News), submit you to a test, or expect you to finish their entire curriculum before writing.

You just need to have some prior writing experience so you can provide samples of your work when you apply to become a contributor.

But there are some guidelines about the content you contribute (maybe freeCodeCamp isn't the place for your lasagne recipe).

I'm a full time software engineer. I write to learn more about topics I find interesting.

freeCodeCamp distributes their articles so widely that last month alone (January 2021) people spent 600 hours reading the articles I wrote. That's pretty cool.

What does freeCodeCamp's style guide cover?

The style guide is the way freeCodeCamp standardises their expectations and guidelines so that all contributors know how best to research, write, and present their articles. It also helps ensure that what is published is high quality.

The style guide covers topics like article length, composition tips, how to write a good headline, how to choose a cover image, how not to plagiarize others' work, some rules about cross posting, and a lot more.

I also found it useful to take a Google technical writing course that you can find here. If you don't want to take the course, you can read my summary of it here if you don't have the 4 hours to do it all.

This course helped me learn some common helpful tips for technical writing, but it's not mandatory for freeCodeCamp.

How do freeCodeCamp authors apply?

If you want to apply to become a contributor to freeCodeCamp News, you should first read the style guide. In it, you'll find the application form.

When you're filling out the application, you are asked to link to 3 articles you have written in the past.

If you don't have three samples, or the work you've done is private, make an account on dev.to or Hashnode and write some articles. This helps the freeCodeCamp Editorial team learn about your writing style, what you like to write about, and whether you'd be a good fit for the publication.

I just want to really emphasise that you should read freeCodeCamp's style guide. Read it two or three times and email the team if you aren't 100% sure about what something means.

If you write those 3 articles following freeCodeCamp's style guidelines, you will hugely increase your chances of being approved as a contributor.

But they do also "only approve a small percentage" of contributor applicants, so don't be discouraged if you don't make it the first time around.

My best advice to get approved is to try and find what is missing from articles you are currently reading. Are you going to write the articles for total beginners or intermediates? How much detail are you going to put in? Do you have a favourite programming language? How much do you use humour? None, or lots of jokey references? How should readers apply this knowledge?

When I first started writing I got the genre wrong a few times (I wrote satire for one article, and some article ideas I had weren't great). But through some practice and speaking to the team, I started to improve and understand what freeCodeCamp's genre is.

But I can't write well

So what? The best way to improve is by writing! If you feel like your writing skills are weak, try and set yourself a specific goal – for example to write 50 words a week on any topic. Something achievable for you, and on a topic you will enjoy.

Give yourself 6 months to see if you are making improvements. Reflect on what you don't like about your writing and try to address it.

My only other advice to improve your writing is to read more. The more I have read, the better my writing has become over time by seeing how others do it.

I don't know what to write about!

Write about something you want to learn about. You don't have to be an expert in something to write about it. You develop expertise by writing, discussing, and researching topics you're passionate about.

You can also ask the Editorial team too if you want some help once you get your contributor account.

What if I'm wrong?

It's proof read by the team so you aren't alone. They offer a second pair of eyes, and you are able to make edits post-publishing if you misunderstood something in your research.

It's a good way to learn, too. When you publish something and you're wrong, people will direct message you to correct you. I have been messaged about things people thought were unclear. I thanked them and reviewed what they said, which often helped me improve that article.

Don't feel too scared about failure to try it!

I write too slowly

freeCodeCamp doesn't have a schedule for you. They don't email you to chase you about writing an article a week.

You just write as and when you want to, and the Editorial team are there to proof read and help in any way they can when you're ready. If you only want to publish once a year, go for it!

English is not my first language

This is the case for many freeCodeCamp News contributors. They're practising English by writing, and contributing to the freeCodeCamp audience.

I hope you feel encouraged rather than intimidated to push your comfort zone boundaries if you have always wanted to try technical writing.

Conclusion

You can apply here to contribute to freeCodeCamp News.

Part of my writing was influenced by a talk Quincy did here about writing technical articles. I would encourage you to watch if you plan to apply to freeCodeCamp in the future. He also gives some fascinating case studies of people who began writing and some benefits that came from it.

I have enormously enjoyed writing for freeCodeCamp and it's been an incredibly positive experience for me. I would encourage anyone to try their hand at writing.

Even if you don't end up doing it at freeCodeCamp it's a skill worth investing time in, and makes you a well rounded developer.

I share my writing on Twitter if you enjoyed this article and want to see more.

I'm going to briefly explain what I learned from completing the course, and I'll summarise the best bits so you can get a good overview of what's covered.

We'll go over some grammar rules and linguistics for the English language, but I'll explain everything upfront so we're all on the same page. The only thing you need to complete the course is a "little writing proficiency in English", but "you don't have to be a strong writer".

Let's dive in.

Introduction

Let's define some terms we are going to use throughout this document:

• Nouns are used to name something such as Mrs Kay, Eiffel Tower or manager.
• Pronouns are used instead of a noun such as I, you, we, them, he, or it.
• Adjectives are used to describe nouns such as friendly Mrs Kay, the rusty Eiffel Tower or the good manager.
• Verbs are doing words such as fight, run, type and eat.
• Adverbs describe verbs such as strongly fight, cowardly run, aggressively type and timidly eat.

Be Clear

Clarity describes how clear your point is in your writing. Your number one priority in technical writing is clarity.

Pronoun use

Whenever you use pronouns, make sure they are clear. It's easy to get confused. Something like:

C++ is a pretty old language, but JavaScript is old too. I really like it though.

Huh? You like what? C++ or JavaScript? The pronouns used here don't help the clarity.

Clarify pronouns usage like:

C++ is a pretty old language, but JavaScript is old too. I really like C++.

Generally, when proof reading, if it's unclear to what you're referring, use the noun instead of the pronoun. This or that are especially prone to this issue. Make sure whenever you use these words it's clear what is being discussed.

Idioms

Idioms are common phrases used to describe something. But some idioms mean nothing to an international audience. Because idioms are so specific to your region/language, try to avoid them in your technical writing.

No one understands what walking around the porridge, chewing the fat, or inflating a cow means intuitively. Just say exactly what you mean, and try to keep your analogies simple and idiom free.

Be Succinct

Succinctness is how brief and clearly expressed your writing is.

Good software engineers spend as much time deleting code as writing it when polishing their work. It's the same in writing. Shorter code generally:

• Makes it easier for others to read
• Makes code easier to maintain
• Extra lines of code add extra points of failure

All of these points also apply to your technical writing.

Sometimes polishing and saying what you want to say succinctly takes time, and you have to really craft the document. You might even end up proof reading multiple times – but it is worthwhile.

Shorter sentences also encourage readers to continue reading. How intimidating is one huge paragraph? It can sometimes intimidate readers, and some readers will just bounce straight off your page when they see huge 1,000 word paragraphs.

Remove "there is" and "there are"

As you go through your writing, "there is" and "there are" can almost always be removed to more briefly express your point.

Both terms are generally very generic and bore readers. Rework the sentence. Here are some examples:

• There is a lot of overlap between software and hardware.
• There are not multiple threads in JavaScript.

I hope you agree how much better these now read:

• Software and hardware have a lot of overlap.
• JavaScript does not have multiple threads.

Minimise use of adjectives and adverbs

Adjectives and adverbs are used a lot in descriptive, creative writing like fiction and poetry.

Google's example is turning "grass" into "verdant, prodigal grass" or turning the lifeless-sounding "hair" into "silky, flowing hair"

The trouble is that adverbs and adjectives are generally too loosely defined, and they can also make your technical writing sound like marketing.

Running the code in production mode makes the code run screamingly fast.

As opposed to:

Running the code in production mode will result in a 225% performance gain.

I hope you agree the second is more precise and quantifiable.

Make use of lists

When you have a long sentence with lots of elements in it, you should split it up into a list. For example, if you're listing the benefits of a particular technology, you could say, X is a great choice because:

• It's lightweight
• It's fast
• It's easy to use

While this is a simple example, you get the idea. This is now far more readable than an overly long sentence and you won't lose readers or your flow.

Use the right list

If you do find a good place to use a list, it's important to use the right list. You could use either a numbered list, like this:

1. Here's my numbered list
2. Isn't it pretty?

Or you can use a bulleted list, like this:

• Here's my bulleted list
• Different, but still cool

So which one should you use?

Use a numbered list, where the order matters, like say a recipe. Try to start each number with a commanding verb to reinforce the step by step instructions of the list, too:

1. Turn on the oven.
2. Bake the cake.

Bulleted lists work well for everything else.

Keep your lists parallel

Now you're hopefully using the right lists! The next step to help you use lists to their maximum potential is to keep them parallel. What does that mean?

Your list items should all have the same:

• Grammar and punctuation
• Logical categorisation (the list items reasonably all belong together)
• Capitalisation

Let's provide a bad example:

• c++
• JAVASCRIPT?
• Rust!
• chocolate chip cookies

All of the above rules have been broken. The item "chocolate chip cookies" doesn't logically belong in the list, the capitalisation/casing of each element is different, and the punctuation isn't consistently applied (It's not clear why "JAVASCRIPT" ends in a "?", and "Rust" with an "!")

Use Active Voice

Sentences are generally made up of subject, object and verb. Let's do a few as a test:

I wrote a story.

I am the subject, story is the object, and wrote is the verb.

I really admire Jake's work

I am the subject, Jake is the object and admire is the verb.

• The subject is the one doing the thing.
• The object is the thing being done to.
• The verb is what is being done to the object by the subject.

All of the above examples use active voice because the subject does the verb to the object. So let's flip those above examples to passive voice:

The story was written by me

Jake's work has my admiration (or Jake's work is admired by me)

You should use active voice because, in addition to being more powerful and direct:

• It's much easier to understand. Whenever people read the passive voice they have to make the mental effort to transfer passive voice to active voice. So for ease of reading, skip that step and write in the active voice.
• Active voice is far more familiar to the reader, as we read active voice writing most of the time
• Passive voice sometimes forces the reader to guess who did what in the sentence and obscures the meaning
• Active voice is generally shorter than passive voice.

General Writing Tips

Let's look at how to maximise each component of a well crafted written piece.

Sentences

Developers are familiar with keeping their code single responsibility. Keep the same formula in mind for sentences.

Express one idea clearly and briefly, before moving onto the next sentence. Don't have lots of and also this and that too and even further splitting on our final sentence. If you end up doing that, split each text after the and into its own sentence.

Paragraphs

Paragraphs should have a clear opening sentence to explain the paragraph's central point.

You also should clearly answer:

• What are you trying to convey?
• Why is it important?
• How should the reader use this knowledge?

Let's have an example that does all the above:

The garp() function returns the delta between a dataset's mean and median. Many people believe unquestioningly that a mean always holds the truth. However, a mean is easily influenced by a few very large or very small data points.

Call garp() to help determine whether a few very large or very small data points are influencing the mean too much. A relatively small garp() value suggests that the mean is more meaningful than when the garp() value is relatively high.

Jargon and context

Jargon is the specialised terminology that a particular field uses.

Investors might talk about a W8-BEN form or SPACs. But if you're outside that field, you have no clue what's being discussed.

Where possible, remove all jargon and acronyms and briefly explain what something is.

Try to make your writing as plain and simple as possible, still giving due credit to the complexity of what you're discussing (don't oversimplify!). If your writing is difficult or complex to understand, it won't help anyone.

Don't assume knowledge either. If you want to talk about something, either explain it, or try to link to a good resource on it. Some refer to this as the Curse of Knowledge.

Assume your reader knows less than you, so experienced readers can just skim the parts they already know, and newbies don't get lost.

Word choice

English is the dominant language for technical writing, but English is not always the first language of the reader. Try to stick to commonly used, simple English words.

You don't have to discuss the exuberance you find from polysyllabic words, flaunting your magniloquence.

Meta info

Write an Introduction

When you write something, briefly explain at the beginning what you're going to cover. This can help people understand exactly what you're discussing before reading more.

Tailor your Contents to your Audience

Try and fit your document to your audience. When you write on dev.to you may write one way, and when you write on freeCodeCamp News you might write another way.

Compose your document to best suit the audience. For example, if you're explaining your company's architecture to a wider audience, you will have to explain things more thoroughly as there's less shared knowledge there than with your colleagues.

Sometime you may not even be writing for technical people, and you'll need to explain things in a less-complex way to aid their understanding.

Summary

Let's do a brief overview of what we covered:

• Try to be consistent through your writing
• Avoid ambiguous pronouns
• Prefer active voice
• Be succinct.
• Focus each sentence on one idea
• Make use of lists
• Focus on deleting unnecessary words
• Don't use complex English or jargon
• Keep lists parallel
• Open paragraphs with an overview of what you're covering
• Scope your document to your audience.
• Establish your key points at the start of your writing.

Conclusion

I hope this article has explained some helpful concepts Google taught me when I completed their technical writing course.

I am going to try and pick and choose the relevant parts of their advice as and when it applies to the writing I do, and I hope it helps you too. I found quite a few helpful rules here for me to apply to documentation or any technical writing I produce.

The course I referred to throughout this article can be found here.

I share my writing on Twitter if you enjoyed this article and want to see more.

And if you're writing in Microsoft Word, there's an easy way to add page numbers to your work. Let's see what it is.

How to Add Page Numbers in Word

When you have a Word document open, you'll see the main Word menu along the top of your screen, like this:

Main Word menu at the top of your screen.

Step 1: Click the "Insert" Tab in the Main Word Menu

Just click on the "Insert" tab, and you'll get a dropdown menu with lots of options. About two thirds of the way down, you'll see a "Page Numbers" option, like this:

Just click on "Insert" on the main menu and then scroll down to "Page Numbers".

Step 2: Scroll Down and Select the "Page Numbers" Option

When you click on "Page Numbers" a little box will pop up asking you how you want to format your page numbers.

Step 3: Format Your Page Numbers

You'll have options for where you want to place the numbers ("Position"), how you want them aligned on the page ("Alignment"), and other formatting options. It'll look like this:

How you can format your page numbers.

Step 4 (Optional): Customize Your Page Numbers

If you just click on the dropdowns by each option, you'll be able to choose exactly where and how you want your numbers to appear.

For example, if I want my numbers to appear at the bottom right, I'll just leave those options at the default. But if I want them, say, at the top and insides of each page, I can make the following adjustments:

How to customize your page numbering.

You can also choose whether you want a number to show on the first page (perhaps not if it's a title page, and so on).

If you really want to get into the details of your page numbers, you can click the "Format..." button. There you can choose how your numbers look (you can have Roman numerals if you want!), whether you want to include chapter numbers, and how your numbers should start.

More page number options.

And voilà – now your pages are numbered!

How to Find the Page Numbers Tab in Word

Here's something cool about Word: if you go to the "Help" tab to search for some functionality, it'll show you where to find it in the main menu.

Here's what I mean:

Say I want to find where to add page numbers (and didn't have this handy tutorial). I could just click on the "Help" tab in the main menu and type in "Page numbers".

But that's not the cool part – as you're typing, you'll see a match pop up (highlighted in pink below). When you hover over that option (don't click yet), Word displays where to find that tool or feature (in the red box below) and points to your query with a pulsing blue arrow! Like this:

Click "Help", type in "page numbers", hover over "Page Numbers", and the menu will pop up to the left.

Then if you actually click on your page numbers query in the Help tool, it'll just take you straight there and you'll see the "Page Numbers" box pop up.

Now you know how to add page numbers in Microsoft Word and you can customize those numbers to your heart's content. Happy writing!

Technical writing might also be for you if you love learning by teaching others, contributing to open source projects and teaching others how to do so, too, or basically enjoy explaining complex concepts in simple ways through your writing.

Let's dive into the fundamentals and learn about what you should know and consider when getting started with technical writing.

Table of Contents

In this article, we’ll be looking at:

• What Technical writing is
• Benefits of Technical Writing
• Necessary skills to have as a Technical Writer
• The Technical Writing Process
• Platforms for publishing your articles
• Technical Writing Courses
• Technical Writing forums and communities
• Some amazing technical writers to follow
• Final Words and references

What is Technical Writing?

Technical writing is the art of providing detail-oriented instruction to help users understand a specific skill or product.

And a technical writer is someone who writes these instructions, otherwise known as technical documentation or tutorials. This could include user manuals, online support articles, or internal docs for coders/API developers.

A technical writer communicates in a way that presents technical information so that the reader can use that information for an intended purpose.

Benefits of Technical Writing

Technical writers are lifelong learners. Since the job involves communicating complex concepts in simple and straightforward terms, you must be well-versed in the field you're writing about. Or be willing to learn about it.

This is great, because with each new technical document you research and write, you will become an expert on that subject.

Technical writing also gives you a better sense of user empathy. It helps you pay more attention to what the readers or users of a product feel rather than what you think.

You can also make money as a technical writer by contributing to organizations. Here are some organizations that pay you to write for them, like Smashing Magazine, AuthO, Twilio, and Stack Overflow.

In addition to all this, you can contribute to Open Source communities and participate in paid open source programs like Google Season of Docs and Outreachy.

You can also take up technical writing as a full time profession – lots of companies need someone with those skills.

Necessary Skills to Have as a Technical Writer

Understand the use of proper English

Before you consider writing, it is necessary to have a good grasp of English, its tenses, spellings and basic grammar. Your readers don't want to read an article riddled with incorrect grammar and poor word choices.

Know how to explain things clearly and simply

Knowing how to implement a feature doesn't necessarily mean you can clearly communicate the process to others.

In order to be a good teacher, you have to be empathetic, with the ability to teach or describe terms in ways suitable for your intended audience.

If you can't explain it to a six year old, you don't understand it yourself. Albert Einstein

Possess some writing skills‌‌

I believe that writers are made, not born. And you can only learn how to write by actually writing.

You might never know you have it in you to write until you put pen to paper. And there's only one way to know if you have some writing skills, and that's by writing.

So I encourage you to start writing today. You can choose to start with any of the platforms I listed in this section to stretch your writing muscles.

And of course, it is also a huge benefit to have some experience in a technical field.

The Technical Writing Process

Analyze and Understand who your Readers are

The biggest factor to consider when you're writing a technical article is your intended/expected audience. It should always be at the forefront of your mind.

A good technical writer writes based on the reader’s context. As an example, let's say you're writing an article targeted at beginners. It is important not to assume that they already know certain concepts.

You can start out your article by outlining any necessary prerequisites. This will make sure that your readers have (or can acquire) the knowledge they need before diving right into your article.

You can also include links to useful resources so your readers can get the information they need with just a click.

In order to know for whom you are writing, you have to gather as much information as possible about who will use the document.

It is important to know if your audience has expertise in the field, if the topic is totally new to them, or if they fall somewhere in between.

Your readers will also have their own expectations and needs. You must determine what the reader is looking for when they begin to read the document and what they'll get out of it.

To understand your reader, ask yourself the following questions before you start writing:

• Who are my readers?
• What do they need?
• Where will they be reading?
• When will they be reading?
• Why will they be reading?
• How will they be reading?

These questions also help you think about your reader's experience while reading your writing, which we'll talk about more now.

Think About User Experience

User experience is just as important in a technical document as it is anywhere on the web.

Now that you know your audience and their needs, keep in mind how the document itself services their needs. It’s so easy to ignore how the reader will actually use the document.

As you write, continuously step back and view the document as if you're the reader. Ask yourself: Is it accessible? How will your readers be using it? When will they be using it? Is it easy to navigate?

The goal is to write a document that is both useful to and useable by your readers.

Plan Your Document

Bearing in mind who your users are, you can then conceptualize and plan out your document.

This process includes a number of steps, which we'll go over now.

Conduct thorough research about the topic

While planning out your document, you have to research the topic you're writing about. There are tons of resources only a Google search away for you to consume and get deeper insights from.

Don't be tempted to lift off other people's works or articles and pass it off as your own, as this is plagiarism. Rather, use these resources as references and ideas for your work.

Google as much as possible, get facts and figures from research journals, books or news, and gather as much information as you can about your topic. Then you can start making an outline.

Make an outline

Outlining the content of your document before expanding on it helps you write in a more focused way. It also lets you organize your thoughts and achieving your goals for your writing.

An outline can also help you identify what you want your readers to get out of the document. And finally, it establishes a timeline for completing your writing.

Get relevant graphics/images

Having an outline is very helpful in identifying the various virtual aids (infographics, gifs, videos, tweets) you'll need to embed in different sections of your document.

And it'll make your writing process much easier if you keep these relevant graphics handy.

Write in the Correct Style

Finally, you can start to write! If you've completed all these steps, writing should become a lot easier. But you still need to make sure your writing style is suitable for a technical document.

The writing needs to be accessible, direct, and professional. Flowery or emotional text is not welcome in a technical document. To help you maintain this style, here are some key characteristics you should cultivate.

Use Active Voice

It's a good idea to use active voices in your articles, as it is easier to read and understand than the passive voice.

Active voice means that the subject of the sentence is the one actively performing the action of the verb. Passive voice means that a subject is the recipient of a verb's action.

Here's an example of passive voice: The documentation should be read six times a year by every web developer.

And here's an example of active voice: Every web developer should read this documentation 6 times a year.

Choose Your Words Carefully

Word choice is important. Make sure you use the best word for the context. Avoid overusing pronouns such as ‘it’ and ‘this’ as the reader may have difficulty identifying which nouns they refer to.

Also avoid slang and vulgar language – remember you're writing for a wider audience whose disposition and cultural inclinations could differ from yours.

Avoid Excessive Jargon

If you’re an expert in your field, it can be easy to use jargon you're familiar with without realizing that it may be confusing to other readers.

You should also avoid using acronyms you haven't previously explained.

Here's an Example:

Less clear: PWAs are truly considered the future of multi-platform development. Their availability on both Android and iOS makes them the app of the future.

Improved: Progressive Web Applications (PWAs) are truly the future of multi-platform development. Their availability on both Android and iOS makes PWAs the app of the future.

Use Plain Language

Use fewer words and write in a way so that any reader can understand the text.‌‌ Avoid big lengthy words. Always try to explain concepts and terms in the clearest way possible.

Visual Formatting

A wall of text is difficult to read. Even the clearest instructions can be lost in a document that has poor visual representation.

They say a picture is worth a thousand words. This rings true even in technical writing.

But not just any image is worthy of a technical document. Technical information can be difficult to convey in text alone. A well-placed image or diagram can clarify your explanation.

People also love visuals, so it helps to insert them at the right spots. Consider the images below:

First, here's a blog snippet without visuals:

Here's a snippet of same blog, but with visuals:

Adding images to your articles makes the content more relatable and easier to understand. In addition to images, you can also use gifs, emoji, embeds (social media, code) and code snippets where necessary.

Thoughtful formatting, templates, and images or diagrams will also make your text more helpful to your readers. You can check out the references below for a technical writing template from @Bolajiayodeji.

Do a Careful Review

Good writing of any type must be free from spelling and grammatical errors. These errors might seem obvious, but it's not always easy to spot them (especially in lengthy documents).

Always double-check your spelling (you know, dot your Is and cross your Ts) before hitting 'publish'.

There are a number of free tools like Grammarly and the Hemingway app that you can use to check for grammar and spelling errors. You can also share a draft of your article with someone to proofread before publishing.

Where to Publish Your Articles

Now that you've decided to take up technical writing, here are some good platforms where you can start putting up technical content for free. They can also help you build an appealing portfolio for future employers to check out.

Dev.to is a community of thousands of techies where both writers and readers get to meaningfully engage and share ideas and resources.

Hashnode is my go-to blogging platform with awesome perks such as custom domain mapping and an interactive community. Setting up a blog on this platform is also easy and fast.

freeCodeCamp has a very large community and audience reach and is a great place to publish your articles. However, you'll need to apply to write for their publication with some previous writing samples.

Your application could either be accepted or rejected, but don't be discouraged. You can always reapply later as you get better, and who knows? You could get accepted.

If you do write for them, they'll review and edit your articles before publishing, to make sure you publish the most polished article possible. They'll also share your articles on their social media platforms to help more people read them.

Hackernoon has over 7,000 writers and could be a great platform for you to start publishing your articles to the over 200,000 daily readers in the community.

Hacker Noon supports writers by proofreading their articles before publishing them on the platform, helping them avoid common mistakes.

Technical Writing Courses

Just like in every other field, there are various processes, rules, best practices, and so on in Technical Writing.

Taking a course on technical writing will help guide you through every thing you need to learn and can also give you a major confidence boost to kick start your writing journey.

Here are some technical writing courses you can check out:

• Google Technical Writing Course (Free)
• Udemy Technical Writing Course (Paid)
• Hashnode Technical Writing Bootcamp (Free)

Technical Writing Forums and Communities

Alone we can do so little, together, we can do so much ~ Helen Keller

Being part of a community or forum along with people who share same passion as you is beneficial. You can get feedback, corrections, tips and even learn some style tips from other writers in the community.

Here are some communities and forums for you to join:

• Hashnode
• Dev.to
• Technical Writing World
• Technical Writer Forum
• Write the Docs Forum

Some Amazing Technical Writers to follow

In my technical writing journey, I've come and followed some great technical writers whose writing journey, consistency, and style inspire me.

These are the writers whom I look up to and consider virtual mentors on technical writing. Sometimes, they drop technical writing tips that I find helpful and have learned a lot from.

Here are some of those writers (hyperlinked with their twitter handles):

• Quincy Larson
• Edidiong Asikpo
• Catalin Pit
• Victoria Lo
• Bolaji Ayodeji
• Amruta Ranade
• Chris Bongers
• Colby Fayock

Final words

You do not need a degree in technical writing to start putting out technical content. You can start writing on your personal blog and public GitHub repositories while building your portfolio and gaining practical experience.

Really – Just Start Writing.

Practice by creating new documents for existing programs or projects. There are a number of open source projects on GitHub that you can check out and add to their documentation.

Is there an app that you love to use, but its documentation is poorly written? Write your own and share it online for feedback. You can also quickly set up your blog on hashnode and start writing.

You learn to write by writing, and by reading and thinking about how writers have created their characters and invented their stories. If you are not a reader, don't even think about being a writer. - Jean M. Auel

Technical writers are always learning. By diving into new subject areas and receiving external feedback, a good writer never stops honing their craft.

Of course, good writers are also voracious readers. By reviewing highly-read or highly-used documents, your own writing will definitely improve.

Can't wait to see your technical articles!

References

Introduction to Technical Writing‌‌

How to structure a technical article‌‌

Understanding your audience, the why and how

‌‌Technical Writing template

I hope this was helpful. If so, follow me on Twitter and let me know!

Recently, I wrote my first technical book – yes, I finally finished it. ?
This project was on my list for a long time. And now that I've finally completed it, I'd like to share my experience with everyone.

In this post, I tried to document my complete journey of writing the book. I discuss everything motivation and hurdles to tools, techniques and resources.

My book focuses on the Hyperledger Composer Blockchain tool. It is completely free and right now is only available in PDF format.

All these points are equally helpful for technical blog writing. So let's get started and dive into what I learned.

Motivation

I have been writing technical articles and tutorials since late 2018. By now I am quite comfortable with the process of writing an article or a tutorial. I understand how to approach the article and which tools I should use.

But when it comes to book writing – and especially a technical book – the arena is quite different.

My motivation was curiosity. I wondered how authors write books. What is their thought process? What tools do they use? And of course, how does it feel to write a book? ?

I am a Software Engineer and I have been working on Blockchain since 2018. I have learned about different blockchains like Ethereum and Hyperledger Fabric. I have also used many tools like truffle, remix and hyperledger composer.

There were a few different things I wanted to write about, like Ethereum or Hyperledger Fabric.

But since it was my first book, these topics were not ideal for me. They would've required a lot more time and effort than I could give. So, I picked a simple one: Hyperledger Composer.

First Hurdle

Before getting started, I wondered which tool or editor I should use to write the book.

Should I write in MS Word, Google Docs, or use something else?
The major issue was how to format code snippets correctly. These editors are not designed for technical writing.

There are different work arounds to add code, but it would require additional formatting.

I read lots of articles about what good tools are available for technical book writing. I tried many of them, but I wasn't happy with any of them. I wasted a lot of time finding the perfect tool.

In the end, I realized that editors only ease the writing process and make managing the book simpler. But what really matters is the content. So, I stopped searching for the perfect editor and went to the basics.

The basics: VS Code

I used my favourite code editor to write the book. Yes, VS Code ?.

After spending days searching around on the Internet, not a single article suggested that you need any specific tool or editor to write a technical book. VS Code or Atom would be more than enough.

I wrote the whole book in VS Code in my favourite markdown format. To make my writing easier, I used a couple of markdown plugins like Markdown All in One and Markdown Preview Enhanced.

The first plugin helps you write markdown while the second helps in preview mode. It shows how the markdown will look and behave after converting it into HTML or other formats.

Markdown All in One also has a preview mode, but Markdown Preview Enhanced has multiple themes and options to export the markdown file in HTML, PDF, and other readable formats like epub or Mobi.

Just a heads up – those other formats require that you install Pandoc on your machine.

I am a Windows User. For Mac Users, I found there are many great editors available like bear, ulysses and many others.

Recently, I discovered that there are many markdown editors available on Windows and MacOS which you can use for book writing. Check out Notion, Typora, iA Writer, and SimpleNote.

Bottom line Don't waste too much time finding the perfect editor. Just start writing in your editor of choice. With time you'll figure it out.

Second Hurdle

Then I started asking myself, from where should I start writing? How should I write? How should I approach it?

In short, I wanted to know how exactly I should write this book so that the reader would get the most out of it.

These questions made me scratch my head a lot. In the beginning, I changed my approach 4 or 5 times.

At this point, I suggest spending some time to really ponder your approach. Because once you're in the middle of the book, it is not going to be an easy task to change it.

Ask the questions

I asked myself these questions about the book and noted my thoughts down.

1. Who is my target audience? Are they beginner, intermediate, or expert?
2. Do they need some prior knowledge of the subject?
3. How should I organize the book?
4. How should I name the files or chapters so it's easy to find each topic?
5. How should I track my progress?
6. How should I maintain the versions of the chapters and drafts of the book? There will be a number of occasions that last edit was actually much better than the current version.

These are a few basic questions which I asked, and they were helpful.

My approach

I'll now describe the approach I took to writing this book.

Create a todo list

First, I created a to-do list. In this list, I noted down all the main points, topics, sub-topics, references, preface, cover, title and so on.

I pretty much added all the thoughts that came to mind about the book.

I would suggest creating 2 todo lists: one on paper and the same as a soft copy.

First, note down all the points on paper. Once you note down everything, read it 2-3 times. Then whatever new ideas pop into your head, note them down.

For example, if you think about how you're going to explain a particular topic, note it down. It will make your work much easier. Then when you start writing about that topic, you can refer to these notes.

Once you have a todo list on paper, create a soft copy and save all the points in chronological order.

This is what my todo list used to look like:

Tasks

• [x] Index
• [x] Cover
• [x] Title
• [x] Subtitle
• [x] Preface
• [x] What is Blockchain and Hyperledger Fabric?
• [x] Introduction to Hyperledger Composer
• [x] Environment Requirements and Setup
  • [x] Azure
  • [x] AWS
  • [x] GCP
• [x] Project Objective
• [x] Project Setup in Composer
• [x] Model File
  • [x] Definition
  • [x] Modeling Language
  • [x] project code
• [x] Script File
  • [x] Definition
  • [x] syntax
  • [x] project code
• [x] Query File
  • [x] Definition
  • [x] Query Language
  • [x] project code
• [x] ACL File
  • [x] Definition
  • [x] syntax
  • [x] project code
• [x] Deployment in Composer Playground
• [x] Testing in Composer Playground
• [x] Export the .bna
• [x] Composer Rest Server
• [x] Frontend
• [x] Conclusion
• [x] References
• [x] About Me
• [x] Grammar Check 1
• [x] Grammar Check 2
• [x] Read the draft
• [x] Read the final draft
• [x] PDF format
• [x] Add page no. to PDF
• [x] New chapter starts from the new page
• [x] Thank You Note
• [x] License
• [x] End cover

I used markdown format for my todo list. You can use whatever format is easiest for you.

Start Small but Do Start

Keep in mind that you don't need to write about each topic in order. There might be many topics which depend on previous topics, but others won't.

Also, you don't have to finish writing about the topic all at once either. Whatever topics you are feeling comfortable with, start there.

Your goal should be to start the book. Aim to write 10-20% of your book within a couple of weeks. Once you start, it will keep reminding you that you have to complete the book. In time you'll realize that this turns into a great motivator.

If there is a topic you don't know as much about, don't worry. Don't hesitate to get help from the Internet. Read how other people explained it. Take inspiration and then write about it in your way.

And remember – If you use any content from other people's work, make sure you inform them, cite it properly in your text, and list their work as a reference at the end.

Consider this as a professional courtesy. -- John Wick ?

Chronological Order

It took me a while to understand the importance of having a file naming convention.

At first I started following a Chapter 1, Chapter 2 naming convention for each topic. It turned out to be a terrible idea.

The problem with this naming scheme is that you have to maintain a separate file where you explain what is in the file. Or you have to open each file to see what it contains.

Another problem is that if you add a new chapter in between then you have to rename all the following chapters.

There are two conventions I found helpful, but each has its disadvantages.

One option is to use chapternumber-topic: Name the file as a chapter number followed by the topic of the chapter. Like this 10-Introduction-of-Blockchain.

Name the chapter number in 2 digits. This will help you add sub-sections to the same chapter in different files. Like this 11-History-of-Blockchain.

Another benefit of this naming convention is it will show all the files in the order of your book chapters.

Disadvantage: Adding new chapter in between requires that you rename all the following chapters.

The second option is to use filename as topic: Name all the files as the topic name. This will give you the freedom to write topics in random order. And you can maintain the order of the book in your todo list.

Disadvantage: All the files will be arranged in alphabetical order. After 10-15 files it will be difficult to track all the files, and it'll be harder to put them together in a draft.

In the end, I followed the second method. It worked alright for me.

To create a draft, I created a Node.js script. In this script, I entered all the topics in an array. Then I created a draft file and appended all the topics in it. Of course by reading them first ?. A few perks of being a Software Engineer ?.

This script was a saviour when I was editing. Many times I updated the topics or pictures within them. I fixed grammatical mistakes. Here Grammarly really saved me...but not completely as I was using the free version. ?

Chronicle of the book journey

Writing a book is not a sprint, it is a marathon. Always save your work when you complete a topic or are done for the day.

The next day, you might get a new idea for the same topic which you already completed. You might spend an hour on it, but it doesn't look good. In this case, UNDO is great but it also has limitations (and its limits vary from editor to editor). Do not test its limits too much.

Instead of relying on the editor or making duplicate copies, I used Git for version control. Don't think that git can only be used for managing your code. It is a versitile tool and its applications are only limited by your imagination.

For the readers who don't know about git:

Git is a distributed version control system for tracking changes in source code during software development. It is designed for coordinating work among programmers, but it can be used to track changes in any set of files. --Wikipedia

You don't have to learn everything about git to use it for writing. The basic commands like init, add, commit, logs and checkout are more than enough for you to maintain your versions and keep your text accessible and safe.

There are many Git code hosting platforms available, like GitHub, GitLab and others. To host your book on one of these platforms, you can follow the below steps:

1. Create an account. My personal choice is GitHub.
2. Create a private repository with default choices. You can change its visibility to public in the future.
3. Follow the instructions provided once the repository is created. Basically, in this step, you're connecting your local Git to your hosted repository.
4. Learn 2 more commands, push and pull. Use push to push the local changes to the cloud repo and use pull to get the content from the cloud.

After this, whenever you make any changes, just add, commit and push. Simple, isn't it? ?

After a couple of commits, you will feel comfortable with git.

Check out this amazing article to learn more: Learn Git and Version Control in an Hour

The tools and resources I used

I used many tools and resources while writing, editing, formatting and designing the book.

Writing

For writing, I used the VS Code editor with a couple of markdown plugins, as I've discussed above.

For emojis, I used copy and paste emojis.

Editing

For correcting grammatical mistakes I used the free version of Grammarly. In the free version, it corrects all the basic mistakes like incorrect or missing articles, prepositions, commas, and so on.

I used the online pdf editor to add page numbers to the book.

Formatting

I used the Markdown in Preview plugin in VS Code to generate the PDF format. I used the default Git markdown formatting. You can change the formatting in the settings.

Page breaks in the PDF

As I was writing in markdown format, the PDF output was inconsistent. For example, it starts a new topic from the last page instead of from a new page.

To fix this, I used the page break html code at the end of each topic.

<div style="page-break-after:always;"></div>

This will make the content that follows it start on a new page.
You can also add the end of the page-sequence like ***** this.

<div style="page-break-after:always; display:block; text-align:center; border:none">*****</div>

About Me Page

In the About Me section of my book, I divided the content into two columns: a brief about me and a profile picture.

It took me a while to realize the full capabilities of the markdown format. We can add plain html code in it. Here's what my "about me" page says:

<div >
  <img align="right" style="padding-left:65px" src="../images/profilepic.JPEG" width="400px" height="450px" />
</div>

Hello, I am **_Shubham Kumar Chadokar_**.

I am a Software Engineer and in my short career of almost 4 years, I've had the opportunity to work on Blockchain, Nodejs, Golang, and Docker.

I've learned about other tech as well, but these are my primary focus. I love to write articles and tutorials on new tech by following a hands-on approach. This is my first book.

Front end development isn't my specialty, and that's why I didn't include it in the book.

If you have any queries or questions, please feel free to drop me an email.

:e-mail: [hello@schadokar.dev](hello@schadokar.dev)
:globe_with_meridians: [schadokar.dev](https://schadokar.dev)
<img src="https://github.githubassets.com/images/icons/emoji/octocat.png" style="width:20px;" />[github.com/schadokar](https://github.com/schadokar)

For octacat, I used the img tag.

It looks like this.

Thank You Page

I added a thank you page to express my gratitude to the Hyperledger Composer Community for their work. I tried to add the content in the middle of the page.

<div style="padding-top:40%; text-align: center; font-size:35px;">
Thank You <img src="https://emojipedia-us.s3.dualstack.us-west-1.amazonaws.com/thumbs/240/microsoft/209/person-with-folded-hands_1f64f.png" style="width:40px" />
</div>
<div style="text-align: center; font-size:25px;">
I especially want to thanks the entire
<a href="https://github.com/hyperledger/composer/graphs/contributors">Hyperledger Composer Community</a> for creating such
an amazing tool. Many developers entered into the blockchain domain because of the simplicity of the composer. <br />
It is unfortunate that it is deprecated but it sets a great example of easy automation,
wrapping a complex Hyperledger Fabric into the easy to use Hyperledger Composer.
</div>

It looks like this.

Book Title and Sub-title

The book title should make the contents of the book clear in a few words or one short sentence.

While you're writing the book, note down all the keywords you use. This will help you to come up with a great title. You want to capture the essence of the book and let readers know, for example, whether it's theoretical or more hands-on.

A sub-title should give readers more detail about what they will get from this book or what they are going to learn.

A one sentence sub-title is ideal, and shouldn't be any longer than two sentences. Don't overdo it – let readers read the book. The idea is to give readers a taste of the complete book in one sentence but still not to tell anything ?.

My book title is Playtime with Hyperledger Composer and sub-title is Create a supply chain management project in Blockchain using Hyperledger Composer.

When you start writing your book, don't spend much time on the book title. When you finish writing, you'll be in a much better position to decide the book title. Everything is written, you know what it is all about, and what others will get from it.

In my case, I changed the book title and book cover at the last moment before publishing it. Before that, it was so boring ?.

Designing the Book Cover

You might have heard the idiom Don't judge a book by its cover.
But the harsh reality is, a book's cover is very important. It is the face of the book.

Try to keep it simple and informative. Don't overdo it. A simple title and a short subtitle with an image or two is more than enough.

I started designing the book cover by taking references from other books, and trying to edit them in Paint. The result was a complete disaster, and I couldn't think of anything good.

Then I realized that designing is not my cup of tea. I decided to hire a freelancer for this, so I checked out freelancing sites like UpWork and Fiverr.

Then, I found Canva. It's such a great tool. Amazing! ? ? ? ?

Canva is a graphic design platform that allows users to create social media graphics, presentations, posters and other visual content. It is available on web and mobile and integrates millions of images, fonts, templates and illustrations. Wikipedia

I used one of the templates from the canva book cover section and created my book cover. Not bad, right? ?

License

I wrote this book out of curiosity and for fun. So, I wanted it to be free, and open-source, but I didn't want others to monetize it. Without a license, there are no restrictions.

I searched for a while and found a great answer on StackOverflow regarding free licenses, Creative Commons Licenses.

Creative Commons is a nonprofit organization that helps overcome legal obstacles to the sharing of knowledge and creativity to address the world’s pressing challenges.

They have provided a form with a couple of questions related to what kind of license you want. Fill out the form and voilà ?, your license is ready. Copy and paste it or use the embedded link.

Publishing your book

There are many options you can choose from to publish your book. You can approach a publishing house and send in your draft. If they want to publish you can go ahead and secure a deal.

After this, the publishing house takes care of other processes like formatting, editing your book, creating an attractive book cover, all the licensing, the publishing process, and most importantly marketing.

In short, if you want to monetize your book and you're expecting a good amount, then a publishing house is the best option available.

Another option is self-publishing. Yes, we can self-publish our own books. Amazon's Kindle Direct Publishing provides a great platform for this. It is free and it publishes the book worldwide.

You'll get 70% of the profits for each sale. The kdp take cares of all the publishing process. You just have to write the book, upload it and format it.

You simply enter the price you want to charge, along with some basic info about the book and and yourself. You can follow their tutorials for more info – they have done a great job.

But I wanted to keep my book free and didn't have the patience for the above processes. So, I self-published it without using any third party.

I just converted the book to PDF format and saved it in an AWS S3 Bucket so that anyone can download it. Then I hosted the book on my website. Simple. ?

Share your work

Once you complete your masterpiece, it is time to show it to the world.
If you haven't teamed up with a publisher or even if you did, you have to spread the word.

These are the few platforms I used, but don't limit yourself.

LinkedIn

LinkedIn is a professional platform and many developers are on it, no matter their specialty in the tech world. You'll also find people of every profession, you name it.

Share your work with them, ask for feedback. 90% of the time you'll get a reply. I shared my work with Dan Selmon, one of the Hyperledger Composer contributors, as well as Srinivas Mahankali, who wrote many books on Blockchain.

They were both very helpful and gave their honest feedback. I am thankful to Dan, who even offered to share the book among his network on LinkedIn and Twitter. ?

Reddit

Reddit is a community hub. You will find many active communities on various subjects here. You just have to join the community that's relevant to your work and share it there.

You'll find a lot of active members on Reddit, in these groups, and they are not shy to share their opinion. If there is a room for improvement, some of them might offer to help.

But before sharing, DO READ THE GUIDELINES. If you violate any of them, they will remove your post.

Twitter

Twitter is not just a social platform where people share their opinions. So don't underestimate it.

If you like facts and figures, here you go: there are 1.3+ billion accounts on Twitter, 330 million monthly active users, 152 million daily active users and 500 million tweets per day. This is huge.

You just have to craft your message and select the right keywords within the 280 characters limit and you can potentially reach a large audience.

Blogs

Do some research and figure out which publications or digital magazines publish articles in your book's category. Share your book summary and details with them.

Ask them if they can write an article about your book. Or you can write an article about your book and share the draft with those publications.

There are also many other platforms you can try – just do a bit of digging.

Conclusion

This was my first experience writing a book. It took some time but it was worth it. Now, I have another badge on my portfolio. ?

I learned a lot from this experience. This article serves as documentation of all my learning for anyone who wants to write their first book or their next book.

Below is the final list of tools I've used so far.
Any suggestions for others are most welcome.

Thank you for reading and don't forget to share your first book with me. ?

Final List of Tools I used

• Editor: Visual Studio Code with 2 Markdown plugins
• Versioning Tool:Git and GitHub
• Emojis: Copy and Paste emojis
• Grammar Check: Grammarly
• License: Creative Commons Licenses
• Cover Design: Canva
• PDF page number: online pdf editor
• eBook storage: AWS S3 bucket.
• Book Hosting: On my blog

Thanks for Reading

If you have any feedback or suggestions to help me improve this article please connect with me on twitter or email me.

• Read my other articles
• Subscribe to My Newsletter

Cover photo by Thought Catalog on Unsplash