mjang

Discussion from WtD Slack

Bear with me, documentarians. I’ve a big thought to share, and I want to use separate paragraphs/entries so that people can respond to points separately. (Vs. me just dumping five paragraphs into one Slack message.)
I’ve been troubled by several aspects of a seemingly prevalent _imposter syndrome_ among a lot of documentarians. Well, more among the technical writers among us documentarians. And although I considered posting to the #career-advice channel, (or the meetpus channel becasue this is the subject of an upcoming presentation), I chose the #watercooler for a bigger audience.
While I’m certainly not advocating that anyone exaggerate their knowledge or deliberately mislead others into thinking we’ve more abilities than we do, it seems that the catchy phrase _imposter syndrome_ contributes to too many people short-changing themselves in discussions with others. And, very importantly, it contributes to the lack of respect for tech writers that we all rightly complain about.
When 

zsup

Documentation-Driven Development

The philosophy behind Documentation-Driven Development is a simple: from the perspective of a user, if a feature is not documented, then it doesn't exist, and if a feature is documented incorrectly, then it's broken.

• Document the feature first. Figure out how you're going to describe the feature to users; if it's not documented, it doesn't exist. Documentation is the best way to define a feature in a user's eyes.
• Whenever possible, documentation should be reviewed by users (community or Spark Elite) before any development begins.
• Once documentation has been written, development should commence, and test-driven development is preferred.
• Unit tests should be written that test the features as described by the documentation. If the functionality ever comes out of alignment with the documentation, tests should fail.
• When a feature is being modified, it should be modified documentation-first.
• When documentation is modified, so should be the tests.