DEV Community

Cover image for The 5 writing tells that make a post feel machine-made, and how I catch them before publishing
frank chu
frank chu

Posted on

The 5 writing tells that make a post feel machine-made, and how I catch them before publishing

Before I publish anything, a short script reads the draft and tells me where it sounds machine-made. The pattern it catches me on the most, every single time, is the em-dash. I love them, I overuse them, and a column of em-dashes is one of the fastest ways to make writing feel generated instead of written.

None of these tells mean the writing is wrong. They mean it has a texture readers have started to associate with low-effort output, and that texture makes people bounce before they reach your point. The good news is the tells are specific and quick to fix. Here are the five my checker flags most, and what I do about each.

1. The em-dash pileup

The em-dash is a fine tool and a terrible habit. When every paragraph has two of them, the writing takes on a breathless, aside-after-aside rhythm that reads as autopilot. The fix is almost always to downgrade: most em-dashes want to be a comma, and a few want to be a period.

Before: The API is fast — really fast — but its rate limit will surprise you.
After: The API is fast, but its undocumented rate limit will surprise you.

The second one is shorter, calmer, and sounds like a person who decided where the sentence should end.

2. Bold-for-emphasis, everywhere

Bolding a phrase mid-sentence to signal that this part matters is a marketing tic, and models reach for it constantly. It causes two problems. It quietly tells the reader you did not trust the sentence to carry its own weight, and a page speckled with bold reads as a listicle even when it is prose. I cap myself at two bold spans in a whole post, and let sentence structure do the emphasizing that the bold was standing in for.

3. Booster words

"This is really important." "A very clean API." "It actually works." The booster word in front is usually doing the opposite of its job. If the claim were strong it would not need propping up, so I cut the booster on sight. "A clean API" lands harder than "a very clean API," because it reads like someone stating a fact rather than selling one.

4. Press-release vocabulary

Every product launch reaches for the same cluster of words: the verbs that mean "use" but cost two extra syllables, and the adjectives that mean "good" but sound like a spec sheet. When they show up in your writing, the reader hears the announcement, not the person. Nine times out of ten the plain word is stronger and shorter. Here is the swap I keep in my head, the tell on the left and what it almost always meant on the right:

A two-column table of common press-release words on the left and their plainer everyday replacements on the right

Reach for the right column. It is what you would say out loud explaining the thing to a coworker, which is the voice you actually want on the page.

5. A vocabulary that circles the same words

Generated text tends to reuse a narrow set of nouns and verbs, and my checker warns when a draft's word variety drops too low. This one has a real caveat, so I am careful with it: technical writing should repeat its key terms. If the post is about caching, the word "cache" will appear a lot, and that is correct. So I only act on this flag when the repetition lives in the connective tissue, the transitions and the filler verbs, not the domain terms. Vary how you move between ideas, not what you call the thing.

The script is a mirror, not a judge

I run all of this through a small script before every post. It prints a score and the exact lines it flagged, and the score is useful the way a bathroom scale is useful: it points in a direction, it does not hand down a verdict. Plenty of its flags are wrong, a domain term it dislikes, a piece of emphasis that earns its place. I fix the true ones and ignore the rest.

The number going down is not the goal, and chasing it will wreck a sentence that was fine. The goal is prose that sounds like a person made decisions, and these five tells just mark the spots where people most often stop deciding and let the sentence write itself. A checker is one way to find those spots. Rereading your own draft with these five in mind is the other, and it is the part that actually makes you a better editor.

Which tell do you catch yourself on? Mine is the em-dash, and writing this whole post with only the two in that first example was harder than I would like to admit.

Top comments (1)

Collapse
 
officialmailkr profile image
오피셜메일

전문 용어의 반복과 문장을 연결하는 표현의 반복을 나눠 보는 기준이 좋네요. 캐시나 권한처럼 같은 개념을 가리키는 단어까지 바꾸면 오히려 독자가 다른 개념으로 오해할 수 있겠습니다. 자동 검사 결과에 제외한 이유를 함께 남겨두면, 다음 글에서도 단순히 점수를 낮추려고 의미를 바꾸는 일을 줄일 수 있을 것 같습니다.