While the title of this blog is SDK writer, I do not write for an SDK team at this time. My job responsibilities have evolved. Presently, I write Help documentation for our product, Team Foundation Server. My job title at Microsoft is Programming Writer, a title that my division seems to hold quite dear. I have never liked this job title. No one really knows what the job title means except those who do the work. That kind of "priesthood" approach to anything rubs me the wrong way. Plus, it's inconvenient in social introductions.

My title is the same but my work is changing. But all this change got me thinking: Why would an SDK writer think that he or she is different than any other kind of writer?

Usually, different names indicate a perception that the writing is for a different audience or requires different skills. It does not mean that we ought to take short-cuts.

Let me borrow an example from another discipline. We might have a bunch of tests that were developed to provide good code coverage during development or we might have some code that we used in a demo for upper management. Shipping that code might be helpful. That code might be better than no code at all, but it would definitely be a short-cut. Most of the time, code like that does not represent a good customer scenario.

What I am discovering by not being an SDK writer is that most of the documentation needs are the same. The details change, but the requirements do not change. Geometry does not change for the plumber. He is bound by the same geometry rules as the carpenter. The precision might be different, but one must cut things to the right length and make sure the angles come together.

I will continue to call the blog SDK writer for now, even though I am not writing for an SDK. I do not think my job has changed that much. Certainly the geometry hasn't changed.