A journey from words to code, and how the platformOS culture made it possible
I’ve always found the tech world fascinating and could see its potential long before I knew how to engage with it or where to begin. As a teenager, when it came time to choose a career, I turned toward the humanities. At the time, it felt like the most accessible path in my country and aligned well with my interests.
Even so, I kept a close eye on the rapid evolution of IT and used as many digital tools as I could. For years, I had the feeling that the path I had chosen was taking me further and further away from technology. As it turned out, I was wrong.
Studying English, then becoming a teacher, and later a researcher and PhD student working with academic texts, language, and communication gave me something unexpected: a strong foundation of skills that translate remarkably well into the IT world. Looking back, I can now see how years of writing, analyzing, structuring information, and communicating complex ideas prepared me perfectly for a career in technical writing.
When I joined platformOS, I came on board as a content writer. After working with the team for several months, an exciting opportunity appeared: I could start learning, developing, and gradually step into technical documentation.
Suddenly, my long-standing interest in IT and my passion for working with texts found a common ground.
One of the things I truly value about platformOS is the way the company encourages people to expand their skills and explore new roles. Our CEO, Adam Broadway, has consistently supported the professional development of the team, stepping in whenever there is an opportunity to help us grow stronger, more balanced, and more confident in our work. This culture made it possible for me to transition into technical writing.
It turned out to be the perfect intersection of my background in communication, language, and teaching, and my interest in IT.
That’s when the journey really began.
Switching roles was not just about writing. It meant learning the technical foundations of how documentation is created, maintained, and integrated into software development.
I started with the basics.
Technical writers working in a Docs as Code environment need to speak Markdown: the lightweight markup language behind modern documentation. I began with tutorials and daily practice using the Markdown Guide.
To support this, I experimented with tools like Joplin for note-taking, which helped me practice consistently. Later, I transitioned to using VS Code, where working directly with .md files and preview panels proved just as effective.
One of the first structured steps after learning Markdown was completing Google’s free Technical Writing One course. It was especially valuable in helping me recognize a key shift in writing style.
In academia, complex sentences and layered explanations are often the norm. In technical writing, however, clarity, simplicity, and precision take priority. I quickly realized that writing in a simple, clear, and factual way is not necessarily easier — in fact, it requires conscious effort and discipline.
This approach is essential for guiding users effectively. When instructions are clear, users can reach their goals without confusion, unnecessary interpretation, or wasted time. This not only improves accessibility but also builds trust in both the documentation and the company behind it.
Another important realization was that documentation is not just a piece of text — it is a system.
One of the first useful frameworks I was introduced to was the idea that documentation is not one single type of text, but a set of distinct content types, each serving a different purpose.
At the beginning, I learned to distinguish between four core types:
Tutorials
How-to guides
Technical reference
Explanations
Understanding the differences between these was an important shift. Each type supports the user in a different way, whether it’s guiding them step by step, helping them solve a specific problem, providing factual information, or offering deeper context.
Although technical writers work with many more content formats in practice, these four categories gave me a clear starting point. They helped me think more consciously about tone, structure, and purpose, and about how to align each piece of documentation with what the user actually needs in a given moment.
At the same time, I found it extremely useful to read blogs written by experienced technical writers. These resources consistently offer practical insights, real-world examples, and actionable advice for writers at every level, especially for beginners trying to understand industry expectations and workflows.
Some of the blogs I explored include:
Regular syncs with Alex, my mentor, played a key role in my learning process. Through our work together, I began to understand not just how to write documentation, but how to write documentation that people actually use.
Technical writing is not just about describing features: it is about understanding the audience. Who are we writing for? What are they trying to achieve? How can we guide them in the clearest and simplest way possible?
A technical writer needs to think like a user: what are their goals, where might they get stuck, and how can we lead them step by step through a process.
To do this effectively, it is essential to become a user of the software yourself. At the same time, it is just as important to remember what it feels like to encounter the product for the first time, whether during a demo or initial exploration. Users may feel lost, frustrated, or unsure at certain points, especially if something is missing or unclear. Good documentation anticipates these moments and provides guidance.
Our collaboration included:
Shadowing meetings, calls, and demos
Taking structured notes together in shared Google Docs
Testing the software collaboratively and exploring features firsthand
One practical lesson I learned early on: having a reliable screenshot tool is essential. Tools like Snagit, while not free, can become an indispensable part of a technical writer’s toolkit.
One of the most exciting parts of the journey was discovering the Docs as Code approach.
This was a major mindset shift: understanding that documentation is treated as part of the software itself: stored in version control, reviewed, and deployed just like code. This approach makes collaboration with developers significantly smoother.
To support this, I began learning Git, GitHub, and VS Code. At first, I used GitHub Desktop as a graphical interface, which made it easier to understand workflows without immediately diving into command-line complexity. As I became more confident, transitioning to using Git directly in the terminal became the next step.
Helpful resources along the way included:
Git tutorials and official documentation
Interactive learning tools
Real collaboration through GitHub workflows
At platformOS, we use DocsKit, an open-source toolkit designed to build and maintain high-quality documentation. It supports the Docs as Code approach, improves consistency, and streamlines workflows.
DocsKit enables teams to manage documentation using familiar tools like Git and GitHub, making collaboration easier and ensuring documentation stays consistent and up to date.
There is also a free Docs as Code Fundamentals course available from platformOS, which provides a practical introduction to this workflow and equips learners with essential knowledge.
Another key step was exploring technical writing style guides.
Across different organizations, these guides share common principles:
Know your audience
Establish a consistent voice
Prioritize clarity
Consistency is one of the cornerstones of technical writing. Without it, structure, readability, and usability quickly break down. Consistent documentation not only improves understanding but also builds trust and supports the growth of communities around a product.
Following established style guides helps create this consistency.
Some of the first resources I explored included:
Google Developer Documentation Style Guide
Write the Docs Documentation Guide
These helped me better understand how clarity, structure, and plain language support both users and engineering teams.
My first real assignment was to create a user guide for a software developed by platformOS for the Department of Buildings (DOB) in Washington D.C. I started by watching a demo by our PM, taking notes in Google Docs, and mapping out the information architecture.
Soon after, I shifted focus to formatting and restructuring content in Markdown using VS Code. This turned out to be exactly what I needed: a hands-on way to practice Git workflows and documentation standards while contributing to real work.
Throughout the process, I continuously refined tone and style based on shared guidelines, aligning with the platformOS voice: clear, helpful, and professional.
One of the most valuable aspects of my work has been collaborating with different teams.
During my first real project, I realized how much technical writers can contribute beyond documentation. By testing the software ourselves, we can provide useful feedback not only on functionality but also on UX writing and interface clarity. Coming from a strong language background, especially with teaching experience, allows us to offer meaningful insights into how users interpret and understand content.
This experience inspired me to start learning UX writing as well. With this additional skill set, a technical writer can become an even more valuable part of the SDLC: contributing during design reviews or later by improving usability through feedback.
Working closely with testers has also been particularly beneficial at platformOS. After demos from SMEs or product managers, testers are often the go-to people for questions about functionality. They also review user guides and help enrich them with important details.
This collaboration works both ways. While testing and documenting, technical writers may discover bugs or inconsistencies, which can then be reported to testers and passed on to developers through established channels. This can save significant time.
At the same time, it’s important to stay connected to cross-functional teams. Regular participation in daily and weekly meetings ensures that updates and changes don’t go unnoticed: helping us keep documentation accurate and up to date.
Changing careers can feel overwhelming, but it can also be empowering in the right environment. At platformOS, I didn’t just learn technical writing: I became part of a community that values growth, collaboration, and continuous learning.
I started as someone who loved language and research. Today, I write documentation that helps users build and navigate software – and I’m still learning every day.
And that’s the best part.
Ensure your project’s success with the power of platformOS.