Every once-in-a-while I get this question, "Hey, should I become a programmer writer?" There's a simple answer, "no." Here's why: it's not really a job anymore.

Let's dispense with the title itself: programmer writer, for most, has always been a bit of a misnomer. Do you program? Not really. You don't develop software in the way other people do, but you occasionally write sample code. Do you write? Not really. In the job that I have done for over 15 years, you very rarely write anything that would pass for your own words. Certainly, this blog is more representative of my thoughts than any technical document that I've ever "written."

Over the past decade, I've seen the profession change a lot. I think it was inevitable. The more self-explanatory any piece of technology is, prima facie1, the less words are needed to explain it. Software development has itself matured and people expect certain aspects of any technology to follow certain predictable forms. For instance, there is now always an object model. That wasn't true in 1994.

In a managed world, there are types and members. Language has become standardized around that and less around specific constructs in the programming languages themselves. Bootstrapping a language from the chip up is no longer reasonable. To that end, the more standardized things are, the fewer words are needed to explain it all. Think Ikea. As frustrating as that stuff can be to assemble, the fasteners are the same. The assembly principles are the same, no matter what piece you choose.

On top of that, we have another more personal dimension of where/how the work will be done. As a profession, the pay has gone down for many people. Anyone who contracts knows this. Anyone who has ever worked on an a project involving outsources or off-shoring to a subsidiary can see this. Regardless of the results, the net result is steady downward pressure on the total cost of the documentation.

In some ways, that's how it should be. The more managed (as in .Net) an effort is, the more you can apply automation to the creation of the basic documentation. Spending the money on documentation auto-generation will pay-off too as you have more general purpose tooling to apply to all projects of the same nature.

As for the programming part, the more automated the documentation process is, the more time the real software engineers can spend showing real code, not made-for-TV code examples that we used to find in SDKs. The blogosphere helps here. There are so many ways for dev-to-dev communication that you find yourself, as a technical writer, discovering a lot of source material that way.

Legal requirements on intellectual property also increase this pressure. Developers now plan to spend time in creating documentation. While that was always true in the smaller companies where I worked, that was hardly ever true in the big companies. It made sense, as a division of labor, to have writers and developers. It makes less sense now.

I think, and it's just my humble opinion, that the halcyon days were 1991 to 2000 for creating SDK content. There's still lots to do in the content realm, but it is more like multimedia stuff you'd see on video-friendly websites.

]For example, I needed to repair my kids' Wii because it had an annoying, vibrating DVD drive. The dude who created that video was immeasurably helpful. That video and a tri-wing screwdriver was all the SDK I needed.