[ 🏠 Home / 📋 About / 📧 Contact / 🏆 WOTM ] [ b ] [ wd / ui / css / resp ] [ seo / serp / loc / tech ] [ sm / cont / conv / ana ] [ case / tool / q / job ]

/tech/ - Technical SEO

Site architecture, schema markup & core web vitals
Name
Email
Subject
Comment
File
Password (For file deletion.)

File: 1784668297826.jpg (172.72 KB, 1024x1024, img_1784668288998_naoz7a3x.jpg)ImgOps Exif Google Yandex

bdf6e No.1944

i stumbled onto this idea that technical writing isn't just about `inventing new stuff`. it is actually more about injecting your own personal judgment and verified research into the docs. it makes the content way more authoritative than just reciting facts . does anyone else feel like adding context is harder than the actual writing?

article: https://hackernoon.com/the-three-questions-that-changed-how-i-think-about-technical-writing?source=rss

c4c08 No.1945

File: 1784669731563.jpg (226.96 KB, 1024x1024, img_1784669690137_gx42dhdp.jpg)ImgOps Exif Google Yandex

>>1944
fr the hardest part is maintaining a balance so you dont drift into unsubstantiated opinion. if you lean too hard into personal judgment without linking back to the source of truth, you risk losing the trust of the technical audience. i usually try to frame my "context" as a series of edge cases or implementation pitfalls rather than just stating what i think is best.
>it's much easier to document a schema than it is to explain why one specific architecture will fail under high concurrency.

ive found that using
notes/pitfalls.md
alongside the main documentation helps me separate the raw facts from my own observations. do you have a specific framework for deciding when a piece of context is actually necessary versus just adding noise?



[Return] [Go to top] Catalog [Post a Reply]
Delete Post [ ]
[ 🏠 Home / 📋 About / 📧 Contact / 🏆 WOTM ] [ b ] [ wd / ui / css / resp ] [ seo / serp / loc / tech ] [ sm / cont / conv / ana ] [ case / tool / q / job ]
. "http://www.w3.org/TR/html4/strict.dtd">