There is wide agreement that in an API (SDK), perhaps the most vital element (and the one the uninitiated programmer always looks for) is the samples. So what is the writer's role in all this? A technical writer must always come to grips with the problem and the proposed solution, from the customer point of view.

Representing the users, the technical writers, then, should be intimately involved with every word in the documentation set. And if the documentation set must include samples, the tech writer should create those too.

This is purist theory. Practically, this is not a requirement.

In all my time as an API writer, I was never once required to write an example myself. Moreover, I would not trust myself to do so. I have learned several programming languages, have worked daily in software engineering environments for over 15 years, but still wouldn't say, "I can code in Java!"

My approach to documenting an SDK is to represent the user, guide the engineers through the topics a user would seek and have the engineers provide the rough source material. That is true for the overview, the reference material and the examples. In encouraging the engineers to come up with examples, I point them to the same tests they developed to QA their own units, or to code developed by Integration teams in the field (more often than not, SDKs grow out of customized APIs developed for specific users). The result of this approach is true-to-life samples that demonstrate broad applicability and that are accessible--again--to the users.

So, for the purposes of API documentation, I would prefer being a programmer-tech-writer to being a tech-writer. Notwithstanding, even if I were a programmer, I might defer to the field engineer or technical support engineer for accurate, practical and applicable samples.