So much of a tech writer's knowledge lives in judgment calls, instinctive edits, and choices that you've developed over years of writing for people in real situations. This tacit knowledge is one of the most undervalued things that an experienced technical writer brings to their work.
This month's topic brings together technical writers to share their insights on what isn't written - the missing context, the assumed knowledge, and the gaps that cost users the most.
When I started using AI for technical writing processes, I thought of myself as someone who builds with AI. Turns out I was just a very enthusiastic prompter. Building real agentic processes changed how I think about what technical writers need to learn right now.
You've made the switch to docs-as-code. Git makes sense. Branches are fine. Then your build fails for no reason. These are the invisible problems that make you question whether you broke something critical, or just don't understand how any of this works.
Docs-as-code. Version control. Git workflows. Pull requests. CI/CD pipelines. If those terms make your stomach flip, you're not alone. Here's what docs-as-code actually means in practice and what your day will look like as a technical writer.
A former colleague reached out: "Any tips for someone starting a job that does docs as code?" Here's what I learned through trial, error, and years of working with teams at AWS.
Managing job applications is hard. I built a job search dashboard to organize my search, track applications, and improve my strategy. And you can use it too.
Your portfolio might be working against you. Learn how to frame projects around problems you've solved rather than deliverables you've shipped.
Thinking about content as infrastructure, not output. How documentation tools keep evolving, and how careers in content adapt alongside them. Exploring sustainable content systems and the real-world impact of AI-powered tools.