किताबों की shelf अब learning plan नहीं है

2026 में केवल classic books की सूची जल्दी पुरानी हो सकती है। Git workflows, automated checks और generative AI documentation work का हिस्सा हैं, जबकि public style guides साल के भीतर बदलते रहते हैं। Books audience, quality और structure पर लंबी reasoning देती हैं; living guides आज के UI, code, terminology और procedures के लिए बेहतर reference हैं।

Microsoft और Google public guidance maintain करते हैं, GitHub अपने Docs content models प्रकाशित करता है, IBM quality standards देता है और Diátaxis tutorial, how-to, reference और explanation को अलग करने की practical system देता है।

पाँच living guides जो काम के दौरान खुले रह सकते हैं

Source Strength Practical idea
Microsoft Voice, procedures, UI Simple sentences, active voice, direct actions
Google Developer docs, global audience Condition पहले, instruction बाद में; technical entities को code format
GitHub Docs User goal, article structure केवल जरूरी content और सही content type
IBM Quality review Accuracy, completeness, clarity, organization, retrievability अलग जाँचें
Diátaxis Architecture Tutorial, how-to, reference, explanation को बिना कारण mix न करें

एक ही समस्या को अलग traditions से देखें

Weak sentence: “Operation पूरा करने के लिए users को ensure करना चाहिए कि repository पहले initialize हो और फिर Create button click किया जाए।”

Microsoft इसे direct बनाता है: “Repository initialize करें, फिर Create चुनें।” Google condition पहले रख सकता है: “Create चुनने से पहले repository initialize करें।” GitHub user goal जोड़ता है: “Project बनाने के लिए repository initialize करें, फिर Create चुनें।” IBM पूछता है कि prerequisite सच है या नहीं और expected result लिखा है या नहीं। Diátaxis पूछता है कि procedure reference में होना ही चाहिए या how-to में।

एक समय में एक problem पढ़ें, लेकिन real assignment के साथ

Problem Compare Exercise Artifact
Hidden prerequisites Microsoft + Google एक real procedure rewrite करें Before/after + local rule
Narrative API reference Diátaxis + Google Facts और scenario अलग करें Clean reference + how-to
Inconsistent terms Google + Microsoft 20 terms audit करें Glossary + lint ideas
Repeated review comments IBM + GitHub Machine और human comments अलग करें Review checklist
Localization ambiguity Google + IBM दो pages simplify करें Local examples

Reading को skill में बदलें

Real defect से शुरू करें, दो या तीन guides compare करें, rule अपने शब्दों में लिखें, एक page बदलें और reader या SME से test करें। Solution repeat हो तो local style guide या automated check में डालें। Learning log में book title से अधिक useful original fragment, changed version और review result हैं।

कौन-सी books अभी भी मदद करती हैं और क्या पुराना है

Docs for Developers (2021) audience से maintenance तक अच्छा end-to-end model देता है, लेकिन current LLM wave से पहले लिखा गया। Developing Quality Technical Information (2014) quality model के लिए मजबूत है, भले delivery context पुराना हो। Every Page Is Page One (2013) search से सीधे खुलने वाले pages के context के लिए useful है, लेकिन अब AI answers भी हैं। The Product is Docs product team collaboration पर उपयोगी perspective देता है।

Tested decisions से अपना style guide बनाइए

External guide reference है, constitution नहीं। एक term बार-बार debate हो तो local decision लिखें। API examples अलग-अलग हों तो pattern तय करें। हर rule में problem, decision, good example और exception रखें।

Field Example
Problem log in, login, sign in एक action के लिए
Decision User action के लिए sign in; literal technical names unchanged
Good example “Sign in to the admin console.”
Exception API field login वही रहेगा

इस सप्ताह क्या करें

ऐसा page चुनें जिस पर reader, SME या editor का real comment आया हो। Problem को एक sentence में लिखें, दो sources compare करें और before/after बनाएं। Real user को दिखाएं और rule तभी रखें जब result बेहतर हो। एक सप्ताह में बेहतर page और tested decision मिलना केवल chapters complete करने से अधिक useful है।

संबंधित सामग्री