Ask HN: Is it possible to live off technical writing?
I co-authored a book on Python last year and it was a lot of work, but also a lot of fun. Does anyone have experience with writing part time or full time on technical topics? How would one get started?
66 comments
[ 2.6 ms ] story [ 138 ms ] threadIn regards to money...no, you can't pay your mortgage from it.
In regards to fun .. yes, it is fun, usually I learn a lot with every book.
In regards to development....yes, it can help me get better job since it is some kind of marketing, and there are not so much candidates with same portfolio. Another thing is that it helps me develop my skills, language and thinking.
In regards how to start ... get in touch with some chief editor, they have a list of topic they and possible readers are interested in. I always send them resume with short description of my previous work and projects.
But writing books (if it's not bestseller) isn't so highly evaluated. You receive only 8-15 % (depends on contract) from final book price.
I think you may have been asking if it's possible to live off of freelance technical writing, in which case, I can't answer that based off of personal experience. But there absolutely are jobs out there that require a competent developer with exceptional communication and teaching ability.
In terms of getting a job at a company, I've seen people pursue technical writing certificates. Though, I think a long list of open source contributions will speak for itself when it comes to modern software gigs. It seems like you have a bit of experience pursuing the second route already, so it's not a bad idea to keep doing that, then lateral into a place of employment.
I think the likelihood of making a living as an indie developer is greater than as an indie on the App Store for example. Tracy Osborn (Hello Web App) said herself that one book wouldn't provide a living, though she surmised that someone with multiple books might. The speaking engagements, networking, and new opportunities will help overall in filling the gaps.
An in depth book may take 6 months to a year to write, but if the writing process can be scaled down to 1 - 2 months per book, with the quality not suffering too much, I don't see why it's not possible that a person can be doing this full time/exclusively after a year of publications, with other contract engagements. To clarify, a number of these books will likely address to a specific framework du jour, or learn X in 1 week, but there can be some that are absolute gems/labor of love.
Disclaimer: I'm just an observer, hoping to explore the same path.
I really enjoy it. I am always looking for ways to improve what we write. One downside is that I don't get a lot of freedom to chose what I write. The topics are usually given to me.
I found something else, though, through that search: http://www.nackerhews.com/news. Be sure to follow the link to https://en.wikipedia.org/wiki/Spoonerism at the bottom (or here where I just repeated it) to understand what it's all about.
I was close - it's been a while since I had a swim in the Reddit pool. Apologies for sending you on a wild goose chase initially.
It doesn't always need a technical background -- a friend of mine found a job writing drug trial instructions even though she had no background in medicine or biology. But she was pretty exceptional, and very quick on the up-take so she probably absorbed a couple of years of medtech education in the first few months she was there.
So yes, you can make a career out of that. Apply for jobs and say "I want a role where I can program 50% of the time and write all your public-facing words the other 50% of your time". There are many employers who would pay a premium for that unique combination of skills which you have already demonstrated.
As for freelance authoring... I'm writing book #8 now. The first 6 are all deeply technical books on backup and managing IT (http://www.ifost.org.au/books/ ); the seventh was a collection of mathematics/computing/physics poetry ( http://www.ifost.org.au/books/outlinks/medusa ).
These are rather small niches, but in most of these areas I'm one of the leading experts in the field -- usually because there's no-one else writing anything.
Based on what I'm getting from my work so far, I'd estimate that I would need to get to 50-100 books written before I could stop relying on other sources of income. I live in an expensive city and have a family, so you might be able to do slightly more easily than me. Also, if I wrote something less niche, I might have a bigger market (but probably face more competition).
In other words, I might be able to write full-time in 10-15 years' time if I keep up the current output. That is something I am aiming to do, but it's obviously not a short-term goal.
For an anecdote, as a product person, I would kill for a technical writer who works really hard to understand our product, our customers and personas, and keeps up with our roadmap and release process with on-the-ball documentation updates and copywriting. I see tons of opportunity there internally.
To get started, find industry blogs or websites with an aggressive content strategy that are willing to pay. Build up that resume and keep moving up and making contacts within your field.
All the better if you can snazz up the content with good-looking HTML/CSS and images so that the editor has less work to do.
To be a product architect you need to:
- Express interest/expertise in learning (constantly) about existing and emerging products/systems/technologies
- Be creative (product definition is your job after all)
- Understand all the moving parts of software development (what do the BE developers do, what do the UX designers do and when, etc)
- Be business savvy
IMO the broad skill-set requirement and critical nature of the position makes it a hard job, but if you love technical writing and already know a bit about software/programming then you could easily fall in love with this line of work.
I'll speak regarding the "sell your own stuff" option, which is fairly well-represented in my social circles.
Short version: yes, you can write part-time or full-time on technical topics as an independent technical writer. It requires operating a technical writing business, the key word in which is more often business than technical writing.
There exists a tremendous demand in the world for industrial inputs. Technical writing is often an industrial input. If your book/e-book/video course/screencast/sample source/etc saves an engineering team weeks, it is worth tens of thousands of dollars. If it saves a single team member two days of reading Free Information On The Internet (TM) it handily sails over $50.
You're going to want to write things which are chosen to be about topics which are actually required by folks trying to get things shipped at their day jobs. This suggests aiming at a sweet spot of technologies which are past their up-and-coming-hotness phase and getting taken up rapidly, but are still not terribly understood. Think React, but perhaps not Rust. (Though one could certainly make a lot of money with Rust books.)
Writing independently involves, above all things, cultivating an audience and then selling into it. This almost invariably means get people's email addresses and sell primarily via email. The easiest way to get people's email addresses voluntarily is to write about related topics in a free and open fashion (on your own web presence to maximum extent possible) and include a call to action which gives people some valuable thing for free in return for their email and permission to email them ~2X a month with other things they'll enjoy. That "valuable thing" is often a short, concise guide on a topic (maybe a downloadable React cheatsheet or 10 quick anti-patterns) and the "things they'll enjoy" is simply blog posts about the topic delivered regularly until you launch.
This provides your future customers with demonstrative evidence that you know what you're talking about and that they'll enjoy your writing, which makes it vastly easier to sell them a book in the cozy little space you've created for yourself than putting the book with 250 other books on a shelf at Barnes and Noble.
You're typically going to sell your book in a multi-package format: $49 for the book proper, $99 for book-plus-something, $249 for book-plus-more-somethings. Often those options include multimedia -- screencasts of you walking through things or executable code samples are fairly common, as are recorded interviews with people relevant to your audience. I tend to think screencasts/code samples are higher value but interviews are high perceived value and very easy to produce.
After you've launched, congratulations! Now you just keep doing what you're doing -- write more blog posts, send more emails, occasionally add new products to the mix using the same rough formula.
There exist quite a few people who make substantial money as self-published technical authors. Many come out to events like BaconBiz and/or Microconf. I'm not sure whose numbers I have permission to quote off the top of my head, but people post postmortems to HN on a fairly regular basis. Suffice it to say many did better than I did last year, or "competitive with mid-career software engineering jobs in the Bay Area" as a different (higher) bar.
Amy Hoy, Brennan Dunn, and Nathan Barry have copious blog posts about the practical life of an Internet-enabled author, virtually all of which extends directly to technical writing. (All of them write or have written in a self-published format on topics directly adjacent to technical writing. I'm recommending them less to tell you how to break down concepts about Python and more for advise on sales/marketing of information as a product.)
[Edit to a...
If you have a technical background and you've coauthored a book, you already have what it takes to find full time work as a technical writer. There are really two ways into this field. You start with a background in English or professional writing and learn the technology, or you can start with a computer science degree or something similar and learn how to write. It sounds like you've done the latter.
The pay is good if you work for a company full time. Many technical writing jobs these days are remote. (All of the tech writers that work for Fastly and GitHub are remote, for example.) You could probably do freelance work, but I've never been able to make that work. Most companies don't outsource their documentation and I'm not entirely sure why, although I suspect it has something to do with them wanting to build long term relationships with the individual(s) documenting their products.
You will need to do some networking. You may want to consider attending Write the Docs (http://www.writethedocs.org/), a conference for technical writers. Depending on where you live, you might also be able to find an active STC group.
Or just start applying for jobs. :) Really good technical writers are hard to come by, so if you know technology and you can write, you'll probably have the job offers flooding your inbox. This recent posting at DataDog is a good example of something you will want to keep a lookout for:
https://www.datadoghq.com/careers/detail/?gh_jid=169167
Hit me up if you have questions.
However, technical writers who write books can share in an income stream, an advantage in the long term.
There are also other benefits. Technical writing positions are generally extremely low stress jobs where you have ample time to finish your work, learn new technologies, etc. And as I mentioned before, many of these positions are remote, so you have the opportunity to live in places with low costs of living.
[1] https://compose.io/jobs/#technical-content-creator
Could you please recommend some good resources for learning to write, in the context of technical writing or more generally?
The first item is really easy. Just go out and find companies that have documentation that you like. You'll probably find you like the way some technology companies write docs -- I personally like the documentation provided by Heroku and Apple -- but you can find good documentation in other places too. Study these docs! Read them again and again. Try to to soak it up like a sponge. After a while you'll start noticing patterns in how they use language and how they organize the information. Just as important, of course, is studying documentation that you don't like. Try to figure out why it doesn't work and then avoid making those mistakes in your own documentation.
Finding mentors is a little more difficult. I cold emailed several authors back when I was started out and almost all of them responded and provided a lot of help. Owen Linzmayer, an author at No Starch Press, responded with this advice: "The most important thing to remember about technical writing is that the goal is not necessarily to be understood, but rather to avoid misunderstanding. As such, consistency and clarity are paramount, and you should never assume your reader has the knowledge you possess. I try to make sure to tell readers not only how to do something, but why. That way they are not just following instructions and learning by rote, but rather, they're building their understanding of the system you're explaining, and perhaps can devise solutions to problems you haven't covered." I also emailed author Robin Williams, and she invited me out to lunch. She was kind enough to have me do some ghost writing with her on a book at Peachpit Press. You need these kind of breaks to learn the ropes and get into a position where you can author books and work in the industry full time.
Obviously practice is really important. The best thing to do is probably create or contribute to some kind of blog or open source guide about something you know. There are plenty of them out there. The Hitchhiker’s Guide to Python (http://docs.python-guide.org/) comes to mind. Keep working at it. It's frustrating and difficult work, but you'll get better over time. In many ways learning to write good technical documentation is just as difficult as learning to code.
Another thing you'll want to do is find a good style guide. Microsoft has one, as does Apple. Apple's is available for free: https://help.apple.com/asg/mac/2013/ASG_2013.pdf
http://www.conversion-rate-experts.com/writing/
I absolutely love the first half of the one by Stephen Wilbers (Keys to Great Writing):
http://www.amazon.com/Keys-Great-Writing-Stephen-Wilbers/dp/...
Disclaimer: I work at DO!
The small startups where I have worked have had woefully bad documentation. Developers and support reps never have time or want to write it. I would say the most useful thing I have done for these companies has been to set them up with a basic Zendesk account and just start writing articles to answer the most basic support issues and how-to guides.
I have found these topics to be not very prone to political word-smithing. People are just grateful for the documentation to be written. The company word smiths and bullst artists would rather fight over the copy for the front page of the website than type up "Troubleshooting CentOS Client Installation". It's uncontroversial stuff.
You would have to offer a turnkey solution (set up a Zendesk or Confluence knowledge base for them, perhaps as a value-added reseller), propose a list of articles to be written, then knock it out in a couple weeks, with add-on work to keep the documents fresh with future releases.
Your sweet spot would be companies with 25 employees or fewer who don't have the money to bring in a full time technical writer.
I don't think you could make F-U money, but you could do much of it remotely, and it would be less stressful than other types of work. Your clientele would have to come largely based on personal reference.
Curious if others think this is viable...
Doing this properly is often not the most fun thing that people can be doing, but is extremely important for getting others using your, well, whatever. I remember working with an older colleague who was excellent at building up good documentation and we'd follow whatever instructions were there, hit problems and solve them, add something to the docs then go back to the beginning and go through everything again. In doing so, we could often create scripts to automate sections and improve the setup process itself.
It's a task that can be hard to get devs to spend their time on, requires skill in a few different areas and has some clear benefits (reduce dev setup time / onboarding costs, improve customer support, etc). There's no lock-in and progress and completion can be pretty clear.
There might be a good source of bounties for the same kind of thing for open source projects too.
I've tried self-publishing books, but they don't sell. I can't afford to market them. If you build up a lot of social network followers you can promote your books and blog links to them.
I had websites but they are down now because I couldn't afford to keep them up. It is really hard to get noticed and your writing and grammar has to be near perfect.
I am writing a book on technology trends, but as soon as I write a chapter it is obsolete. For example I was writing about Windows 8.1, Mac OSX 10.9 and others and new versions came out and changed how they worked. I was writing about the operating system wars between commercial companies and FOSS projects. It changes so fast that what I write is obsolete before I can get it ready to publish.
If you're interested: samstern [at] google