If you've read The Placeholder for some time, you may have notice I don't much talk about specific tools or technologies. This seems pretty strange for a technical writing blog. But there's a good reason why I shy away from such details. It's because these are just details that shift like the wind. I am more interested in the bigger picture of technical writing.
There are some other technical writing blogs that may talk about these specific things. And if you're looking for these specifics, then go to them. But I intentionally created The Placeholder with a different angle.
I created The Placeholder because I felt the principles of technical writing were getting lost in the seas of ever-shifting currents of tools and technology and in the mire of the aspiring technologist. When I saw the ever-growing requirements for technical writing jobs to know such and such tool and you must know such and such programming language rather looking at years of writing experience, I felt technical writing was morphing into something it's not. I created The Placeholder to be a small (probably quixotic) bulwark against this ever-growing tsunami of technological requirements and other obscure oddities for a writing job.
A technical writer is a writer, first and foremost, who documents about how certain technologies, products, or services work. A technical writer is not a technologist who merely writes. That may offend some for me to say this. But when you strip a technical writer of their odd exterior, that person is a writer underneath.
I have no interest in writing about things with a short shelf life. I am interested in writing about things that will last. Principles, if they are good, will last. But virtual tools and technologies change with the direction of the wind. For example, when I first started as a technical writer I used Pagemaker. Then, the hot tool to use was FrameMaker. FrameMaker was a great tool to use for creating big technical documents. I used to create technical documents with a lot of equations that were thousands of page long. I was even FrameMaker's defender when the powers that be at a company I used to work for suggested shifting over to Word. I told them no because Word, at that time, didn't have the capability to handle the technical documents we were doing. FrameMaker was the go-to tool for a technical writer. If you were doing help-authoring, at that time, you would use Robohelp.
Now fast forward, FrameMaker has lost its preeminence. Also, where's Robohelp these days? Many are requiring InDesign to create technical documents or use Wordpress for bloggish-type technical writing or maybe for help documents. By the time you get a handle on a platform or tool, it shifts to something else. It's almost hopeless to stay completely current with this. But tools are tools. They are not essential to technical writing itself. What's essential is quality writing.
Principles of good technical writing stay about the same. Principles like active voice, concise language, and presenting information where it's easy to follow stays the same. And these are the principles technical writing should be built upon, not upon tools or technology. They have been here before I became a technical writing. They will last when I am gone. But I also recognize technical writing principles don't stay frozen in time and that's fine, they shouldn't. These principles should evolve when needs arise. For example, more recent concerns like greater accessibility to documents for those with impairments. We should incorporate accessibility into the "technical writing rubric" because we need to make documents that are accessible to as many people possible. These are the things I care to write about.
Technology is a double-edged sword. So, I am not so interested in singing praises about any particular tool or technology. There are two only reasons why I enjoy technical writing. One, I get to write. Two, I get to help others. If the technologists want to take over the technical writing world and push folks like myself, then I will take my two passions elsewhere. If God makes it clear for me to leave technical writing, then I will graciously bow out. Otherwise, I will stay in it. And while I'm here, I do what I can to create quality documents.
As for programming or markup languages, I don't mind talking about them. Like the written language, they evolve but the principles stay the same. Like the written language is behind good pieces of literature, the programming languages are behind some helpful pieces of technology and software. In recent years, I have taken a liking to Markdown. I am happy to see some technical writing jobs out there now asking for those who know Markdown. I like Markdown because it helps focus on creating good writing, not get lost in the trappings of tools.
As for programming or markup languages, I don't mind talking about them. Like the written language, they evolve but the principles stay the same. Like the written language is behind good pieces of literature, the programming languages are behind some helpful pieces of technology and software. In recent years, I have taken a liking to Markdown. I am happy to see some technical writing jobs out there now asking for those who know Markdown. I like Markdown because it helps focus on creating good writing, not get lost in the trappings of tools.
So if I am not writing about the latest such and such the STC is talking about, it's because these things fluctuate. They can do that and that's fine. But, I will do my own little thing here. Remember, tools change but principles of good technical writing stay the same.
Focus on your craft and learn how to best the serve the audience you're writing for and the rest will follow.
Focus on your craft and learn how to best the serve the audience you're writing for and the rest will follow.
