Search
What the female reader expects to see is a good story without gender stereotypes or sexism. Lauren's advice applies. Female readers are going to be very sensitive to sexist tropes and female stere...
"When a woman picks up a fantasy novel with a female protagonist today – and that is all she knows – what would she expect?" I expect growth in characters regardless of gender and I don't care (to...
As my name probably makes clear, I'm not female. However I'm a keen reader of fantasy and SF, and I'm particularly interested in anyone with new things to say, because the power of fantasy and SF i...
You can try Japanese Transliteration which will take English words and *transliterate them into Hiragana, which you can hear spoken (lower right hand option). This means it will show you the Hiriga...
(FTR, 21 nods, 53 smiles, 95K. We're pretty close.) I had a beta read on a few chapters and they said the word usage itself was fine. You may be fine. A few ideas. Some nods can be qualifie...
I'm a little wary of purely data-driven writing changes. Without reading your book, I can't say if 62 smiles is 3 smiles too many or 5 smiles too few. But in terms of a warning sign of possible de...
I had a similar concern once when, having happened upon this image, I thought to check how often characters sighed in one of my manuscripts. It happened about 1.5 times per chapter, which I felt wa...
If you're writing in a style then your writing is a "proper writing style". Perhaps you meant to ask "does this conform to an existing style?" Having a first person narrator who directly addresse...
Clarifying as per discussion below: It depends on how far you are planning to go in terms of addressing the reader. As pointed out, it is quite common in a first person narrative for the narrator ...
If you've ever played D&D, think of this character as having low wisdom, high intelligence: smart, but not knowledgeable. Curious. Interested in obtaining new information, looking at new things...
I would approach this be doing the following (in order of preference) If you follow a style guide, consult it. If you are writing about a specific coding language, consult that language's officia...
The general rule in tech comm is to avoid humor, and I think the main points of consideration are: audience, context, and localization - if you're considering this at all. Speaking specifically a...
The Microsoft Manual of Style puts it well: Don’t try to be funny. Jokes, slang, and sarcasm are context-specific and hard to translate and localize. What’s funny to you might offend or alienat...
No. Don't repeat yourself is a good content management rule, which is what it is in programming as well. If you have two instances of the same thing it becomes harder to manage them. If it were not...
Identifying a commit A universal identifier for each commit is its SHA1 — a 40 digit hexadecimal number, like this one: 3e0b5fb09d70d0457d7e5ae7892504f6e1b45f33 This commit is from the Sphinx d...
Humor implies an intimacy and casualness that's typically not appropriate for technical communications. Whether it's a tense bug-fix or something-broke-on-me situation like Mark Baker describes, a...
I've worked on a few doc sets like that. While API reference documentation is one case where you see this problem, the problem occurs at the "module" level too. Your question is about microservic...
While there are strategies such as the use of analogy and simplified language that can help somewhat, the real issue is that a non-technical audience is non-technical (for a given domain) because t...
In language, when a mistake becomes common enough, it's standard usage. One way to check whether the original meaning of a word has evolved beyond your preferred usage is to check a dictionary or ...
To automate any data manipulation task you need two things: Access to the metadata or pattern in the source data that you want to act on. The ability to change the metadata or data of the source...
I'd recommend using a glossary. You can use the glossary to clearly define each term that you apply in a certain way in your document. Almost every specialisation has its own set of terms, and an ...
Your logic makes sense -- the hyphen seems to join them together (a unit of if-else statements), the slash often means "or". However, the slash can also show connection between two words. (I might ...
I think there is one thing to be said on this that is not covered by Does DRY (Don't Repeat Yourself) Apply to Documentation? and that is this: It is not uncommon that there are common operations ...
As somewhat alluded to by Chenmunka, if your documentation is generally in the context of a specific programming language and/or compiler, it is probably best to stick to what is required by those....
I concur that Does DRY (Don't Repeat Yourself) Apply to Documentation? pretty much answers the question on what is best for the user. However, the question was: Which one is more futureproof? ...
