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.
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/...
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.
To reiterate patio11's comments, make sure you run the business (80% marketing + 20% pushing the book to distribution channels), as this will give you very interesting margins, like 45% of the list price. In comparison, if you were to write for an established publishing company, you'll get < 5% of list price, so totally not worth it (unless you think they have a magical marketing department that can sell 10x more product than you could on your own).
I totally recommend it as a career option, though keep in mind writing a quality book takes a lot of time, like a year per book... Feel free to email me if you need further advice (or a LaTeX template). Be sure to also check out https://github.com/softcover/softcover Michael Hartl's kick-ass ePub/mobi production toolchain.
In 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.
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 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.
1 - There's an enormous gap between great technical writing and so-so technical writing, but it is hard to get paid for the great work unless you're working for yourself. (Hard for a company to pay one technical writer $50K and another $100K, but they can pay $100/hour part-time vs $50K full-time to someone who can do clearer work in a quarter the time)
2 - Many people write books with secondary agendas (to promote their day-career) so it's hard to just make money off the book. A well-written book is a fantastic calling card, though, and beats any resume.
3 - For better or worse, some of the coolest folks in tech are the writers. I don't know why. Perhaps because they're in it for interest rather than getting rich?
4 - I don't know any dabblers who have made a career of it, but I know several who have said "This is who I am" and have made a decent living.
How to start? Start writing a blog! Then share your portfolio. Meet people until you find one that has a need. It's a different field than engineering where every company has holes. It's more like there's 0 or 1 spot, and you want to be top of mind to someone who has 1.
Good luck!
If you're interested: samstern [at] google
I've been seriously considering some outreach to young startups who wouldn't need a full-time writer. Great docs really help to distinguish great software - would Django have become so mainstream if its docs weren't so good?
Edit: typo
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.
Would you publicize the tutorials and cookbooks to the public (via a blog or project email list) before you sold the cookbooks to the companies?
How many of these did you do?
What was the level of effort for each of the cookbooks?
What did the company do with the cookbook? Put it up on their website?
I did not (only did it a handful of times). Although it would be the smart thing to do. It would put you in an advantageous position to market the book to all interested parties.
>How many of these did you do?
About five in total. None of them were ultra-long and detailed cookbooks. They were short, but to the point. Less than a hundred pages.
>What was the level of effort for each of the cookbooks?
It was rather easy because cookbooks don't require a lot of explanation. They were just me showing people how to do things with whatever technology. If the cookbook was for an API I already had a formula. Start with authentication and work my way through the endpoints. Including code examples for every step in various programming languages (mostly Java, PHP, and Python). Super easy.
What did the company do with the cookbook? Put it up on their website?
They would either put it on their website or distribute it as a PDF. Though all these companies are now dead except one. And that last one did a complete rewrite of their stuff.
Overall, the whole thing was fun and easy money. I've been working with technical documentation since the 80s so it came kind of naturally. I stopped doing it because I wanted to code more. But I would not mind doing it again someday. I'm actually working on some books myself, but those are a scheduled for much later this year. :)
Best of luck!
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.
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.
In short, it's definitely possible to earn a living out of technical writing. Getting started is the hardest part. If you don't have a reputation, you will need to build one. Growing audience will take time, but it will pay dividends.
To keep this comment short, I'll just link to a series of articles (and presentation slides) I've written about my experiences. Hopefully these help! Here we go:
* http://agile.fi/survivejs-writing-a-book-in-a-lean-way/
* http://survivejs.com/blog/succeed-at-technical-books/
* http://survivejs.com/blog/survivejs-interview/
* https://survivejs.github.io/how-to-write-a-book-and-survivej... (Chrome works the best)
Best of luck!
Disclaimer: I work at 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 add: I mentioned self-published several times above, but to reiterate: if you take on the risk of business execution, your upside goes way, way, way up from doing this. If you go through a publisher, you will be offered a $5k advance check and get totally shellacked on royalties. Midlist self-published authors work as authors; midlist published authors need day jobs.]
My experience is that a lot of the good sources of ad-hoc work have dried up. That's not to say there is nothing now, but it's not the shooting-fish-in-a-barrel it was a few years ago. The demand has gone up and down over the years so I'm sure it'll be back.
As you've seen it's a lot of fun. I always treated it as a way to get other people to pay for me to learn the stuff I would normally have done in my spare time anyway. The money was good for the time invested, but I make far more just working a day job.
If I wanted to make an income from it, I'd be finding a company or two to attach myself to rather than piecework.
I've found that the industry is very focused on your portfolio, so continue to build upon that.
Also, be very nice to the editors you work with. They provide a lot of feedback to the people making the decisions, and no one likes a prima donna.
However, for the vast majority of people I know who write computer-oriented books (including myself), it's essentially a branding exercise to support either their full-time employment or a consulting business of some sort.
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.
David Flanagan (java in a nutshell etc) couldn't do it any more, so it seems hard. He blogged about it somewhere...
As always, if you make your expenses low enough, maybe...
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.
From my point of view, since we are not native speakers we are still loosing some points.
As #bebraw mentioned below,it‘s worth to hire or at least cooperate with some native speaker or skikled translator. They can help you correct grammar and give you valuable insight how to in more native manner. Question might be a cost of this cooperation.
One point from my experience. I am publishing via established publisher who has own verified and skilled translators. So i can and they also require to write manuscript in my native language and they will translate it to final language in which books will bevpublished. Even my and 'destination' language are very close and we can understand each other without any issues. Reason of trnaslation is pure business. Second language has better revenue than mine.
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.
It's an incredibly varied field, with a lot of different routes into it. The main markets are:
Print magazines
Online magazines/blogs/sites
Formal corporate technical writing
Mainstream tech publishing
DIY tech publishing
They all have different requirements, schedules, and working relationships.
The first two are probably the easiest to get into. If you have no experience, write a couple of polished sample pieces, and then start contacting editors with ideas that match the magazine/blog. Send in the samples when they ask for them. Mention the Python book too. If you can build a relationship and are good, you will get regular work.
Beware - good writing is harder than it looks. You have to be accurate, concise, and entertaining as well as informative. You may also have to be fast. Payment varies from not much at all to - exceptionally - high four figures at the very top end for high profile journalism.
Formal tech writing is a very specific skill and it's hard to get a job in it without some previous experience and/or a basic qualification. I've never done it so I don't know how to get into it.
Mainstream publishing - list the publishers (there aren't many in tech), find the commissioning editors, and email them with a couple of suggestions for books. Mention the Python book. If you get interest you will probably get an advance - high four to very low five figures is usual for niche tech, maybe double that for consumer tech. Don't accept a project that offers less, because it won't be worth the time. Formatting and editing for print can be torturously specific, so it's not so fun from that POV.
DIY - Leanpub is a popular platform. So is Createspace. Marketing will kill you, so you'll have to do a lot of it. Putting up a marketing site is not enough. Email lists are your friend.
Generally writing doesn't pay nearly as well as coding. I did it for a while after burning out on writing too many projects in assembler in the late 80s and early 90s. It was great for a period, and I had a couple of years where I could have lived off royalty payments. The market now is much broader but much shallower - many more opportunities, but mostly they don't pay nearly as well.
Like other people, I've sometimes used mainstream pub as a way to get paid to learn. You have to pay that back with a book, but it's not a bad deal compared to not getting paid to learn.