coding – TechCommGeekMom

I’m a writer. So, explain to me why I should know HTML?

Posted on August 4, 2021 by TechCommGeekMom

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.

Uncategorized

Microsoft Wants Autistic Coders. Can It Find Them And Keep Them? | Fast Company | Business + Innovation

Posted on September 7, 2016 by TechCommGeekMom

Job interviews can be especially hard if you’re autistic. A Microsoft effort aimed at a wider spectrum of the workforce wants to solve that.

Source: Microsoft Wants Autistic Coders. Can It Find Them And Keep Them? | Fast Company | Business + Innovation

This article, posted originally by Microsoft Careers on Twitter, excited me. I could related to this article on so many levels, especially with the non-disclosure part, and the tracing my route before I got there. I did that yesterday with my son for school. We were allowed to come in a day early, see his schedule, and do a dry run of his day, meeting the teachers one-on-one rather than a busy, hectic, first day with all the kids. Thank goodness we did that–his bus never showed up, so I had to drive him to his school, and he was a half an hour late. At least he knew where to go. Even on the way home, I knew that a place where I may be interviewing was nearby, so I passed by on our way home, just so I knew where to go when the time comes.

Microsoft really did an excellent job with this article, and appropriately told the good and the bad of being an autistic employee. Autistic people usually are very good with technical things, so naturally a fit with Microsoft makes sense. The method they use of letting the candidates hang out and help for a few weeks before the real interview is something I wish all employers did with employees. I know I’d benefit from it, for sure! I hope that other companies adopt similar plans for autistic workers, whether they are coders or tech writers or anything else. It gives me hope that my son has a chance to get into a job that can be fulfilling to him, if he chooses (he’s more of a computer hardware guy, but still–there’s a need for guys like him, too, at a place like Microsoft!).

Read this, and let me know what you think in the comments below.

–TechCommGeekMom

Uncategorized

ENIGMA Decoders Have Nothing On We Tech Comm Writers

Posted on June 6, 2014 by TechCommGeekMom

An ENIGMA coding machine, found at the Computer History Museum (photo credit: TechCommGeekMom)

Technical communicators truly do have skills that most others don’t have, and it’s a simple set of skills. We take for granted that we can display writing and documentation clearly.

What brought this to my attention most recently–as if I didn’t know this fact already–was dealing with emails from work. I was trying to interpret emails from several educated, fairly influential people from the company, and I didn’t have the faintest idea what they wanted because of unclear directions. Granted, it didn’t help that the email system that we are forced to use at the moment (Lotus Notes) is not exactly user-friendly when it comes to formatting content within an email. Even when I could wade through the quagmire of formatting fogginess, what was being requested of me was not completely clear, and I had to send emails back clarifying the requests.

Although we are often required to work on reducing the number of words used to relay our messages and act as translators of content, it shouldn’t be at the cost of miscommunication. Sometimes having more is less, because more detailed directions can provide less back-and-forth of emails, thus more efficiency in getting the work or task done. From a customer perspective, having accurate documentation–even if it’s long–can reduce call centers help requests significantly.

A great example of making sure that content–whether it’s an email or any other documentation–is efficient is when I worked at the Princeton University Press. The CMS I had to use was an in-house Frankenstein monster of an application, but it worked for better or worse. There was no printed documentation, so when I first started working for the company, I took lots of detailed notes to make sure I understood how to do tasks on the system. I left the company after a few months, but left my notes for my successor. About two years later, my successor left, and my former manager asked me back to fill in temporarily, since she knew my contract had ended, and my ramp-up time wouldn’t be the same as if a new person was coming in during the pinch of getting the new fall catalog posted online. Sure enough, the two-year-old notes were still at the desk, and I could still follow them clearly. (This was when I knew that techcomm was truly my calling!) This reduced the number of times I had to ask my manager to refresh my memory on how to do certain tasks. As a result, the fall catalog information went up quickly, and everyone was happy. Mind you, the documentation I had was pages and pages long–all handwritten, no less, but it was accurate enough that I didn’t need much help in re-learning the system. My second successor was able to use these notes as well, since they were so accurate.

As I said, we take for granted that we have the ability to write cogently and clearly since we all do it on a regular basis. It’d be nice if more people can get the basics of this skill down so that we technical communicators can do our jobs more efficiently. The fact that we can decipher and clarify messages better than anyone should put us in the same ranks of ENIGMA coders, in my mind!