I didn't plan to become a technical writer
I stumbled into it out of curiosity, the way most good career decisions actually happen. I had a background in data science, and somewhere along the way I found myself more interested in explaining technical concepts than just working with them. One thing led to another, and before I knew it, I was deep into API documentation, white papers, and developer content.
Nobody handed me a roadmap. I took a free online course early on, which helped but honestly, self-learning taught me more than any structured curriculum did. The biggest thing I wished I had? A mentor. Someone who had already walked the path and could tell me what actually mattered versus what I could skip.
This post is my attempt to be that for you.
If you're considering a switch into technical writing whether you're a developer, a recent graduate, someone from a non-tech background, or just curious like I was. Here's what I wish someone had told me from the start.
First, What Is Technical Writing Actually?
Before we talk about how to get in, it helps to be clear about what you're getting into.
Technical writing is the practice of translating complex information into clear, useful content for a specific audience. That sounds broad because it is. Technical writers produce:
- API documentation — reference guides and tutorials for developers integrating software
- User guides and manuals — step-by-step instructions for products and software
- White papers — long-form strategic documents that educate and persuade
- Release notes — concise summaries of what changed in a software update
- Blog posts and tutorials — educational content for technical and semi-technical audiences
The common thread is clarity. Your job is to take something complicated and make it understandable without dumbing it down to the point of being useless.
What technical writing is not is purely creative writing. You're not writing novels or marketing slogans. You're writing for people who need to do something install a tool, call an API, make a decision. Their time matters. Your words should earn their attention.
Do You Need a Technical Background?
This is the question everyone asks first, and the honest answer is: it depends on what type of technical writing you want to do.
For developer documentation and API writing, a technical background helps enormously. If you've never written a line of code, understanding what a REST API does let alone documenting one is going to be an uphill climb. You don't need to be a senior engineer, but you need enough technical literacy to read code, understand what it does, and ask intelligent questions of the engineers you work with.
For user guides, product documentation, and instructional content, the bar is lower. Strong writing skills, curiosity, and the willingness to learn a product deeply matter more than engineering credentials.
My background in data science gave me a head start in the AI/ML documentation space. But I've seen people with backgrounds in journalism, education, linguistics, and biology become excellent technical writers. What they all had in common was curiosity and a willingness to sit with something confusing until it made sense.
The Honest Truth About Courses
When I started out, I did what most people do: I searched for a course.
Courses are useful. They give you structure, vocabulary, and a starting point. Google's Technical Writing courses are free, well-structured, and worth completing. The Postman Student Expert certification is practical if you want to get into API documentation specifically. These are legitimate credentials that signal to employers that you've taken the field seriously.
But here is what no course will tell you: you will learn more from doing than from watching.
The moment I started actually writing documentation building a GitHub portfolio, working with a real API, making mistakes and fixing them, my understanding accelerated in a way that no video lesson could match. Courses teach you the theory. Practice teaches you the craft.
So take the course. Then immediately find something real to work on.
Your First Real Step: Build Something
The single most important thing you can do as an aspiring technical writer is build a portfolio, and the fastest way to build a portfolio is to pick something real and document it.
Here's a concrete starting point:
1. Pick a free public API.
Hugging Face, OpenWeatherMap, and NASA all have free, well-documented public APIs. Choose one that genuinely interests you.
2. Use it.
Make real API calls. Understand the authentication. See what the responses look like. Break it on purpose and see what the error messages say.
3. Document it as if you're writing for a developer who has never seen it before.
Write an overview, an authentication guide, at least two endpoint references with request and response examples, and a quickstart tutorial. Aim for clarity over length.
4. Put it on GitHub.
A public GitHub repository with your documentation sample is your portfolio. It's what you send when someone asks to see your work. It's what hiring managers look at before they call you.
This process use the thing, then explain the thing is the core loop of technical writing. Everything else builds on top of it.
The Skills That Actually Matter
Technical writing sits at the intersection of several disciplines. These are the ones worth developing deliberately:
Writing clarity. This sounds obvious but it's harder than it looks. Read your own sentences and ask: could this be shorter? Could a tired person understand this at 11pm? If not, rewrite it.
Structured thinking. Good documentation has a logical flow. Before you write, outline. Know what the reader needs to know first, second, and third and respect that order.
Technical curiosity. You don't need to know everything. You need to be the kind of person who asks "but why does it work that way?" and isn't satisfied until they understand the answer.
Tool familiarity. Learn Markdown it's the lingua franca of modern documentation. Get comfortable with Git and GitHub. Explore at least one documentation tool like Postman, Swagger, or Notion. These are table stakes.
Empathy for the reader. The best technical writers are obsessively focused on the person reading their work. What do they already know? What are they trying to accomplish? Where will they get confused? Write for them, not for yourself.
What Nobody Tells You About Breaking In
Here's the part I had to figure out the hard way.
Your first opportunity probably won't look like a job. It might be contributing to an open-source project's documentation. It might be writing a blog post that gets shared in a developer community. It might be offering to improve the README of a tool you use. These small, unglamorous contributions build the portfolio and the credibility that lead to paid work.
Niche down as early as you can. "Technical writer" is a broad category. "Technical writer specialising in AI/ML APIs" is a specific one. The more specific your positioning, the easier it is for the right opportunities to find you. Your background, your interests, and the content you create should all point in the same direction.
The portfolio matters more than the certificate. Certifications signal effort and baseline knowledge. A portfolio of real work signals capability. When it comes to getting hired, capability wins.
Community accelerates everything. Find where technical writers hang out. Write the Docs is a good starting point, as is the technical writing community on LinkedIn. Ask questions. Share your work. The field is more generous with knowledge than you might expect.
The Thing I Wish Someone Had Told Me
I spent a lot of time early on looking for the perfect guide the definitive resource that would tell me exactly what to do and in what order. It doesn't exist. Or rather, it exists in fragments scattered across courses, blog posts, YouTube videos, and GitHub READMEs.
What I actually needed wasn't a perfect guide. It was permission to start imperfectly.
Your first documentation sample won't be your best work. Your first API reference will have gaps. Your first blog post will feel rough. That's not a reason to wait, it's a reason to publish anyway and improve from there.
The technical writers I admire most aren't the ones with the most credentials. They're the ones who started before they felt ready, kept building in public, and got better with every piece they shipped.
You can do the same thing. You just have to start.
Where to Begin: A Simple Action Plan
If you've read this far and you're ready to take the first step, here's a simple sequence:
- Complete Google's Technical Writing Fundamentals course — it's free and takes a weekend
- Pick one public API and document it — aim for a GitHub-ready sample within two weeks
- Write one blog post about something you learned — publish it on Dev.to or Hashnode
- Share your work on LinkedIn — you don't need a big audience; you need to be findable
- Keep going — one piece at a time, one skill at a time
That's it. No gatekeeping. No expensive bootcamp required. Just curiosity, consistency, and the willingness to build in public.
The rest follows from there.
If this post helped you, share it with someone who's been sitting on the fence about making a career switch. And if you're already on this path and want to swap notes — I'd love to hear where you are in the journey.
Top comments (0)