Aaarrrrrrggggghhhhh!!! It’s exhausting when the only way you know how to express negative emotions is through WRITING!... or sometimes crying, eating junk, cutting off all your hair, seeing movies in a dark room all day and slowly falling into depression but let’s stick with the writing. I genuinely HATE being in a new space because to be honest, I hate being a novice/beginner (or whatever “derogatory”— no, seriously what the heck is “JavaScript for D. U. M. M. I. E. S ?!”— term used on people just starting out on something)
The irony of it all is, I’m never satisfied! Soon as I finally start getting the hang of digital marketing, content creation and graphic designing, I’m taking classes on technical analysis, technical writing and drum rolls programming for software/blockchain development! Ugh, If only there was an easier and faster way to simply download all the information I need from the universe into my brain! But nope, I have to take the pains of trying to figure out the valid points from a boring 3hr lecture, executing it—and failing—and then going back to the lecture! But not today, I won’t vent about programming today because it’s third on the list of my problems now.
I’ve been following my own advice and applying to jobs with which to fill my knowledge gaps and boy, have I been underrating the whole concept of technical writing! I thought having a good command of English language, empathy by putting yourself in the shoes of a complete novice and the ability to break down complex tech subjects was enough to bring me some few thousand dollars as a technical writer (and it could but that’s not the point).
Making real money as a technical writer goes beyond just making tutorials and how-to guides, matter of fact, there are some distinguishing factors that separates technical writers from every other type of writer (yunno, anyone could write!) and these “factors” are my bone of contention so let’s take a look at them.
… but first, WHAT EXACTLY IS TECHNICAL WRITING?: A summary of literally all the definitions of technical writing that I’ve read, shows that technical writing is all about writing about a particular subject (sport, medicine, technology etc.) to provide a set of clear and concise guidelines, directions, instructions and explanation which can be in form of a report, whitepaper, user manuals, API and software documentation etc.
Now, WHAT EXACTLY IS MY PROBLEM?:
Well, let’s start with API (Application Programming Interface) AND SOFTWARE DOCUMENTATION. Prior to my job hunt I didn’t know what it meant so imagine my shock when 90% of job descriptions for a technical writer role had “To document APIs” included. huh? APIs? So I did some digging and found out that apparently dummies weren’t the only ones who needed a guideline. Programmers too needed their fair share of instructions on how to go about things and of all persons, it is the job of the technical writer to provide them with this instruction!
This automatically means that as a technical writer, you have to be able to read, understand and write codes because disturbingly, programmers don’t speak or understand plain English! (you know I’m kidding right? They do speak and understand but they prefer not to. Oh, I’m still kidding, programming is programming and codes makes programming programming).
Now even though I started taking some classes on HTML, CSS and JavaScript recently, it’s all still new and foggy and I still have to incorporate MARKDOWN into the learning process since it is the prominent programming language for technical writers, it’s the language they use to document this API for our programmer dummy friends.
But it doesn’t end there, for heaven’s sake! You still need to have a substantial knowledge of the use of something called a VERSION CONTROL TOOL and the most popular one for both technical writers and programmers is GIT. This is basically the platform where you’ll submit your software/API documentation written in markdown for the programmers to make use of.
To think you thought that was about it, Sike! For your own good (though this is not mandatory, really nothing in this article is) you have to contribute to OPEN-SOURCE PROJECTS to build your experience and portfolio, it makes you look good and appealing in the eyes of employers. Imagine learning how to document APIs and the use of markdown and git to contribute to a project that isn’t yours for totally free.
Dummy tip: The best way to look at version control tools and open source projects are as a complex word document where anyone, anywhere has access to contribute to and modify the document. In this case, Google docs is the version control tool like git and the document you’re editing is the open source project.
Now I know all I’ve vented about may be soul-crushingly easy but the fact is that I’m a dummy—sorry—beginner in this area and other areas because I wouldn’t just stop learning! I’ve always been this way, as a child, my answer to “what do you want to be in future?” left my teachers in utter confusion! Because, I simply wanted to be everything. If I hadn’t read this article, I would’ve continued believing there was something horribly wrong with me.
And I know at the start I said one way I know how to express emotions is through writing but writing abstractly is not the same as putting up a coherent document on an important topic. It could be only 200 words but would take weeks of putting your soul in it and trying to get it right but then you start experiencing blocks and feeling frustrated and the only way you know how to ease the blocks and frustrations is through writing! really it’s just an unending loop of stress writing.
Isn’t it magical though, how it all turns out into one fine article. Any way, I’m getting my shit together and soon I’ll leave articles on guidelines to API DOCUMENTATION, MARKDOWN, HOW TO USE GIT AND HOW TO CONTRIBUTE TO OPEN SOURCE PROJECTS.