Technical writer: an underrated way into IT

What the job is

Writing what the people working with a product read: interface specifications for programs, user guides, internal instructions, help sections.

The task isn't to write beautifully. It's for the reader to read and then be able to do. Good documentation is tested simply: did the reader succeed?

Why it's underrated as an entry point

The programming barrier is low. You need to understand what you're writing about, not to be able to write it yourself.

Competition is lower. Hundreds apply for a developer role; a handful apply for a technical writer.

A humanities background is an advantage here, not a handicap. Clear exposition is a rare skill and it's the core of the job.

You're in the industry. From there you can move into analysis, product management or testing — you're already inside and understand how things work.

What you need

To write clearly. The foundation. Short sentences, active voice, specifics instead of generalities, logical order.

Enough subject understanding to ask questions. Not programming, but knowing what a service call, a database, a version and an environment are.

Working with markup. The simple text markup languages documentation is assembled from.

Version control. In modern companies documentation lives alongside code and is updated the same way.

Documentation build tools. Several exist; the principle is similar throughout.

Reading English. A substantial share of primary sources is in it. Many roles require writing it too.

What distinguishes a good writer

They verify what they write. An instruction written from a developer's account and never performed by hand almost always contains a missing step.

They write for a specific reader. A beginner's guide and a reference for an expert are different texts and mustn't be mixed.

They aren't afraid of stupid questions. If the writer doesn't understand, the reader certainly won't. "Where do I get this key?" frequently exposes a hole in the product.

Building a portfolio

This is the profession where a portfolio is easiest to assemble: all you need is text.

Document something undocumented. Take a small open project with poor documentation and write it. Offer it to the authors — it's often accepted gratefully.

Rewrite a bad guide. Find a confusing manual and make it comprehensible. Attach both versions and explain what you changed and why.

Write a guide from your own experience. How you configured an environment, deployed a project, solved a specific problem. Useful to others and it shows you working.

Write an interface specification for somebody's service. Work out how it behaves and describe it.

Three or four such pieces make a solid application.

What strengthens it

Work with a live project and a live team. Writing documentation for someone's pet project is a rare favour that will be welcomed, and it gives you experience of agreeing with an author, clarifying the unclear and revising after someone reads it.

That's exactly the job, and it gives you something to talk about.