My Heart in The Art of Technical Writing
Why I started writing, what's kept my pen dancing, and my ultimate goal as a technical writer
Photo by Wilhelm Gunkel on Unsplash
Technical writing may seem like just another term or role that refers to doing a specific thing, in this case - creating technology-related content while making them available and accessible to the right audience. But like every form of art, the art of technical writing does relate differently to individuals who practice it, either professionally or as a hobby.
In this piece, I will talk about my art of technical writing in terms of what it means to me, why I go in it in the first place, what has kept me in the game (my motivation), and finally, I will talk about what I aim to achieve as a technical writer.
How I became a technical writer
My first official article was published sometime last month - August 2021, on my Hashnode blog and it wasn't so technical as it was written to be submitted in response to an entry-stage task for an internship program I was participating in. In that piece, I shared my preparations and expectations for the program and tried as much as possible to express myself in my best capacity. The program commenced on the back of me completing two writing-heavy courses in my degree program at the UoPeople, one on Literature and the other, an introduction to Psychology, with knowledge from both courses proving useful in these early stages of my life as a technical writer.
Prior to writing technical articles, I have been excelling at writing well-crafted posts for the weekly discussion forums, written assignments, and learning journals in my degree program at the university, so I can say writing generally has to be a thing of interest for me or at least I knew I was going to feel at ease while I'm at it.
What motivates me?
My deep attention to best practices and not just implementations that work is the primary drive that made me start writing about software engineering in particular. Every time I go on a search for a solution to a particular problem, I spend so much time trying to find the right one with the fewest or no side effects at all, also I prioritize solutions from the official documentation of the tech I am using as it tends to be less of a hack - as hacks usually come with a load of side effects but many developers don't seem to know that. The motivation to put out not just what I know but also help people find the perfect solutions to software engineering problems and dilemmas while also saving them the time it took me to arrive at that almost perfect solution by making my contents available and accessible to the right audience, this is what keeps me going as a technical writer and also why I chose to blog on Hashnode.
My goals as a writer
Like many developers would say "facing a problem? Just google it!", also many of us do know that there is almost an infinite amount of possible implementations and solutions to any software engineering problem. And the fact that many of these solutions are just a google search away shows good accessibility to these resources, but do we care enough to filter the dirt? Although platforms like stack overflow and geeks for geeks do have algorithms to help us rank the best solutions higher in the pecking order but then, what exactly is a good solution really? From my years of experience using these problem-solving platforms, I have come to discover that the highest-ranked solutions aren't always the best, in some cases, it is the solution with the shortest line of code that takes the lead, while in other cases a solution that works for a use-case may largely fumble when tried on another similar use-case hence the question, what is the right solution or implementation amongst this large pool of options that present themselves to us? My primary goal as a technical writer is to go deep into solving common software engineering problems make these full-proof implementations from my technical researches available and accessible to every developer out there and also to preach the difference between an implementation/solution that "just works" and the right implementation/solution.
Conclusion
I have been able to describe what the art of technical writing means to me, how I'm holding it in this early stages of my career as a technical writer also stating my motivation to keep going as well as what I do aim to achieve down this path.