It’s been a while since I’ve written here. It’s been a very busy year! I’ve started articles for the blog, but then forget or don’t finish them. I’ll catch up eventually.
In the meantime, this topic has been really relevant to me lately, and I figured that I’d share my thoughts on it.
My first disclaimer is that I am not a developer in any shape or form. I leave that to my husband who’s been doing it professionally for about 30 years now. However, as I’m often known to say, I know enough to be dangerous. And that amount I know has actually helped me immensely in my career.
I originally started learning HTML about 22-23 years ago. Yes, HTML hasn’t changed that drastically since the 1990s. I was working for one of the early e-learning dot-com companies. It was the position that in my mind truly started to launch me into a tech comm career, although I didn’t know what tech comm was or know this would be the launching point at the time. We were building a continuing education portal for various financial companies, and in order to make customizations of the splash pages, I needed to learn a little bit of code. As I started helping out with some of the customizations more and more, I asked my manager if the company would be willing to pay for me to take a course at the local community college so I had a better understanding of what I was looking at, and could do a better job with these customizations that were being used in both the splash pages and building the content for the learning sites. They agreed, and off I went. I still have the textbook because the basics were so easy, and if I forget something, then I can still look it up. But taking that course and applying it to that e-learning platform for our clients was just the start of something that helped to propel me in my career.
Years later, I started a content management job using SharePoint. Now, this was long enough ago where the content author/managers could still go into the backend of editing fields into the HTML. People were always being told that they could copy and paste directly from Word, and the formatting would stay the same, but the reality was (and still is) that Word adds all sorts of extraneous code that’s not needed, and when that combines with the CSS (Cascading Style Sheets for those who don’t know–the code that set the general formatting for the page(s)), it wouldn’t always look all that good, especially when it came to tables. This job was at a financial company, and boy, did they like their tables, and they would always look horrible. I would grab the HTML code for the pasted tables, put it into Dreamweaver where I could look at both the code and the front view at the same time, and I would either rebuild the tables or work on taking out that extraneous code that Word would leave in. Once I’d get it to where it needed to be, I’d copy the code back into SharePoint and…voila! A perfect table! I got a reputation for being the “Table Queen”, always fixing everyone’s tables on their pages and fixing the formatting.
Fast forward to now. I’m liking my job, and I’m part of a team that’s worked in SharePoint (no access to the HTML, though) and a new knowledge management system (KMS–similar to a CMS), and sure enough, the CSS that’s been provided by the outsourced developers to customize the system they are using is, well, terrible. We figured out some tricks to work around it, but it’s not unusual for me to get a request from someone on my team asking me to–again–fix a table, fix the bullet points, or the section alignment, or something along those lines. Just today, my manager couldn’t figure out why the bullet points she wanted to make in a text field weren’t working. And so I went into the HTML code on the backend, went through the section line by line (fortunately, it wasn’t a big section), and had to tweak the code and manually fix it so that it aligned properly again and the bullets were done correctly. I’ve turned into the go-to person to fix these things in the system.
Am I a developer? Oh, heck no. Not by a long stretch. There are times even the HTML baffles me, and I’ll ask my husband to look at something and see if he sees something I can’t. He’ll be able to show me where there’s an issue (it’s usually something small in JavaScript, which I can kind of read, but couldn’t write), or determine that it’s not on my side with the HTML, but must be part of the CSS that I don’t have access to. But having a basic understanding of HTML has also helped me understand what I’m looking at in PHP, JavaScript, and definitely understand how XML and Markdown work. In fact, when I taught Technical Editing a few years ago at NJIT, I included several weeks of a crash course in HTML, XML, and Markdown, because so much editing these days–if not done through comments and “track changes” in Word, is done fixing code–not always with an text editor.
HTML, XML, and Markdown are pretty easy to learn once you get the hang of it. Does it help you as a technical writer or technical communicator? Yes, absolutely. You don’t have to be a writing software documentation or writing API documentation to know that having these basic coding languages under your belt can be helpful. Just using standard CMSs and KMSs often will use these. Knowing how to go into the code to add that Oxford comma in the sentence, or to realign the row of a table–it makes a big difference. It also opens up opportunities to learn more and take on more important and interesting projects down the road. It’s a game changer for technical writers because this allows them to be more than just writers–it allows them to be more multi-functional in a technological world. (And again, to put this in perspective, the KMS that I’m helping to build is about Human Resources stuff, and I still help to write the knowledge articles, too!) So I’ve found learning these basic web languages to be instrumental to my growth and my career as a technical communicator. I’m needed not only because of my regular technical writing skills, but I have that extra “something” to contribute as well.
What do you think? What are your experiences? Include your comments below.
TechCommGeekMom 
I couldn’t agree more, Danielle. Just enough technical knowledge is fine with me.
I documented programming languages at DEC in the late 70s and API and SDK stuff a little later, but that was more about software than it was about writing and I wasn’t a programmer. I was working for an online publishing company that was way ahead of the WWW at the time, but it was a proprietary system, and since open systems always win out, we got tsunamied. And I remember where I was the first time I looked at an HTML source file. I grokked HTML formatting right away because it was a first cousin of the first editor I used: C-Script. HTML used and C-Script used .b to bold the following characters, for example. At a string of web app startups, I got pretty good at HTML coding. We created our online help content directly in Dreamweaver at one.
I like where I’m working in now a lot more though, and one of the reasons is that I don’t miss the constant war with the technology one bit. The tool we use – Confluence – is a breeze. All I have to worry about now is making sure I’m working in the right version of the doc for the right version of the software. I get the guys in testing to set me up to use their test environment – one that has all sorts of data already entered that I can use to play around and figure out how things work. I can really focus on the writing which is what I’ve wanted to do all along,
Irony in action.
Where the text starts to appear bolded I had entered the characters less-than, the letter b, and greater than. Who knew the reply software would recognize and obey the HTML command to start bolding the following characters – the very action I was using as an example.