How to Write for Google Developers as a Non-Native English Speaker
Google Developers
Are you a non-native English speaker that wants to write for Google Developers? If so, you’re in the right place! In this blog, I want to share my experience on how to write and get published on Google Developers as an international blogger who doesn’t speak English as their first language. I also show how I was able to get started and how I managed to build my traffic and followers during the past year. So if you have similar goals and you want to become one of our contributors, follow along!
What do you need?
First, find a relevant organization that you want to write for. Look at their website and see if they have any information page (usually labeled About us, About us, or similar) that details its mission statement, staff list, press contact info, etc. If so, shoot them an email with your pitch. Tell them why you think their audience would benefit from your perspective. And be prepared: Most organizations will have some guidelines on who they are looking for and what they’re looking for in terms of experience and content needs (for example, some might ask that pitches be 600 words long). Do your research ahead of time so you can meet those expectations.
Keyword research
Before you begin writing, conduct some keyword research. This will not only help you create content that people are searching for (because if they're not, you're wasting your time), but it will also enable you to craft appropriate titles and headlines. If, say, you're writing about how to select an influencer marketing agency in Singapore, typing Influencer Marketing Agency Singapore into Google is probably a good idea! Keyword research is also really useful when it comes to optimizing your post—which we'll talk about later.
Know your audience
To write effectively, you must know who your audience is and make sure you are writing in an easily understandable language. When writing for developers, I have found that it helps to define them. When it comes down to it, developers fall into two categories: onsite and offsite. Onsite developers are those who work at your company or organization in some capacity; they're part of your company's ecosystem. Offsite developers typically work for another company but use your product in their day-to-day activities.
Determine what makes sense for your audience
Before you start writing, do your research. Find out what language and terminology your audience uses, and then make sure you write in their voice. Don’t use technical jargon that you think is appropriate just because it makes sense in an academic setting; rather, try to emulate how a person outside of academia might talk about these topics. You don’t have to pretend that you are not educated—rather focus on choosing words that help someone else understand what you want them to understand. To help with content creation and editing, be sure to leverage technology such as Grammarly or Hemingway App.
Consider important keywords early on in the post.
It’s important to consider what people will be searching for when they find your post. By thinking about potential search terms, you can craft your writing in such a way that it naturally incorporates these keywords. For example, I could write a post on how to use blogs effectively, but if my goal is traffic (i.e., search engine optimization), I might change my title to effectively use blogs. In addition, it would behoove me to include some of those words within my text.
Don't be afraid to make grammar mistakes.
If you aren’t a native speaker, don’t be afraid to make grammar mistakes. The point of your content is to inform readers and share your message. Even native speakers make grammar mistakes. The average native reader spends just 7 seconds scanning an average webpage, so they will likely breeze right over any grammatical mistakes you may have made in your piece. Some say that there is some value in worrying about these details if you’re writing something where credibility and eloquence are key, but for developer blogs or app descriptions (which are informational pieces), all that matters is that people understand what you are trying to convey. This can be done without flawless grammar!
Use shorter sentences.
Shorter sentences make it easier for your reader to understand your meaning. Shorter sentences are also more likely to end with periods, making them easier on the eyes and less daunting. Longer sentences tend to involve multiple clauses (and therefore semicolons or dashes), which can disrupt easy reading. The best way around that? A period at each sentence’s end. That’s not always possible, but if you strive toward shorter sentences, you'll find they give you more freedom when structuring thoughts and ideas.
Revise more than once!
This is something I picked up in grad school that was reiterated by one of my thesis advisors: Good writing isn't written, it's rewritten. You've probably heard of Hemingway's famous six-word memoir, For sale: baby shoes, never worn. In his book The Paris Review Presents The Art of the Short Story, editor Malcolm Cowley reveals that Hemingway took out several key adjectives—the original read: For sale: baby shoes. Never worn. Make an offer. Cowley argued that without those adjectives, we don't get any sense of why these baby shoes are for sale—or why they aren't used. So we rewrite and rewrite until it's just right.
Take advantage of spelling and grammar checkers, but don't trust them 100%.
I’m not one of those purists who think writers should avoid all forms of technology. When it comes to spelling and grammar, though, I do think it’s important that you learn how to use tools like spell checkers and grammar checkers but still be critical when using them. The main problem with these tools is that they’re relying on algorithms. Your sentence may not be correct, per se, but what do you want it to mean? You need context, too! For example, Spell checkers don't recognize context; they just spot words in a row. Spell checkers can never replace human intelligence and insight; at best they can only serve as an additional filter when writing.
