Why technical writers should learn to code... and build things!

Last month, I prototyped an AI tutor that helps new developers run their first Docker container. It's a React app powered by Docker Model Runner that guides users through docker run hello-world with conversational AI assistance. The whole thing took me a day to build.

Here's the thing... I am not a software engineer. I started my career with hopes of becoming a software engineer. Five years later, I've found my passion in technical writing and developer experience. But those coding skills I developed along the way? They've shaped how I approach documentation in ways I didn't expect.

The unexpected insight

When I built that AI tutor, I wasn't trying to prove anything about technical writing. I was just curious about Docker Model Runner and wanted to understand it better. But the process taught me something I couldn't have learned any other way.

The most confusing part wasn't running local AI models, it was designing effective system prompts. That insight didn't come from reading product specs or talking to engineers. It came from spending hours iterating on prompts, watching the AI tutor fail in weird ways, and figuring out how to make it actually useful for beginners.

That experience taught me that we might want to change how we document AI features. Instead of focusing primarily on technical setup, we might want to spend more time on prompt engineering guidance. But I only discovered this gap by building something myself.

The different perspective

Most technical writers come from journalism, English, or communications backgrounds. They bring crucial skills like content strategy expertise, user research methods, and strong writing craft. All things I have to work harder at.

My path was different. I stumbled into technical writing through code, and it's given me a particular lens on developer experience. Not better or worse, just different.

When I document APIs, I'm thinking about authentication flows I've implemented. When I write setup guides, I remember the environment issues I've debugged. When I explain error messages, I can picture the developer staring at their terminal in confusion because I've been that developer.

What building teaches you

There's something about actually using your company's products that changes how you write about them. You stop describing features and start explaining experiences.

Take error handling. Most documentation treats errors as edge cases. Brief mentions at the end of guides. But when you've built something, you know errors aren't edge cases. They're Tuesday afternoon. Half your development time is dealing with things that don't work as expected.

Building the AI tutor meant wrestling with Docker Model Runner. I discovered network errors and system prompting nuances. Each time I hit a roadblock, I could provide specific feedback to the product team based on my actual experience.

The workflow shift

I've developed a habit over the years: before documenting new features, I try to build something small with them. Not comprehensive testing, just enough to understand the developer experience.

For Docker Model Runner, I built the AI tutor. When I work with APIs, I write queries and run them in a simple app.

These aren't production-ready applications. They're learning exercises that happen to improve my documentation. The AI tutor helped me understand system prompt design. Writing API queries helped me understand use cases.

This approach works for me, but it's not the only way to understand products. User research, developer interviews, and support ticket analysis all provide valuable insights too. Building things is just one tool in the toolkit.

The industry context

I've noticed job descriptions for technical writing roles increasingly mention "hands-on experience" with developer tools. Teams expect writers to understand CI/CD pipelines, work with version control, and contribute to overall developer experience.

This might reflect the broader changes I wrote about in earlier posts. Developers are working in AI-native environments. Documentation is getting embedded directly into development workflows. The line between "using tools" and "understanding tools" is blurring.

Whether this trend continues or shifts in another direction, having multiple ways to understand your products seems valuable.

Getting started

If this resonates, start small:

• Set up your company's development environment and actually use it
• Pick one feature you document frequently and build a simple example with it
• Join engineering standups or code reviews as an observer
• Ask developers to walk you through their actual workflows, not just the happy path

The goal isn't to become an engineer. It's to understand your products from a developer's perspective, which might influence how you document them.

Some technical writers thrive on user research and content strategy. Others excel at information architecture and clear writing. I've found my niche in the intersection of building and explaining. Your niche might be entirely different, and that's valuable too.

The meta-lesson

Building the AI tutor reminded me why I love technical writing. It's not just about explaining how things work, it's about making complex things accessible. When you understand something deeply enough to build with it, you can explain it in ways that actually help people.

The defensive energy I wrote about in my first blog post starts to shift when you focus on becoming more capable rather than more protective. Whether that's through coding, user research, content strategy, or any other skill that helps you serve developers better.

Learning to code isn't going to make any of us irreplaceable. But understanding the products we document from multiple angles might make us more effective at our actual job: helping developers succeed.