How to start a technical book?

Question

Well, I am a experienced software developer and looking at question made by friends that are learning, questions over the internet and StackExchange, I noticed that I eventually could help more people by writing a book. Not an advanced, a book for beginners that should be fun and nice to read an to learn how to program basic things using C/C++.

But there's a huge problem. I am a Software Developer, not a writer. I just do not have a clue how to start building a book.

So here I leave the question: how to get started? I'm asking about writing the text itself, not other factors (like marketing).

Answer 1

Since you're a software developer, I encourage you to think about the book the way you think about a significant application. You (probably) don't just start writing code; you do some requirements analysis, maybe some use-case analysis (please don't shatter my dreams :-) ), some high-level design... and then, if you're like most of us, you start implementing, discover some things you can improve and other things you didn't think about, and iterate. This isn't that different other than that you're producing text instead of code.

As this answer says, an early step should be brainstorming about content and starting to organize it into an outline. This outline isn't cast in stone; think of it as being cast in Jell-O. But you need a starting point. You will probably end up with a list of specific topics (chapters? sections?), along with an introduction. Skip the introduction. Intros are hard; save it for later. Instead pick one of the concrete topics you've identified and start writing that in isolation. Think of it like a blog post on steroids or a single lecture in a class: you know there'll be other context and that you'll have to add some connective tissue, but what do you need to get across on this topic? Write that. Don't polish yet; just get stuff down as coherently as you can. Then do another one. Then one more.

After you've done a few, you'll start to see where you have cross-dependencies, what questions you didn't consider, and what patterns are starting to arise in your writing (like how and how much you talk about code samples). Great -- now you can pause the writing, assess where you are, refactor, maybe throw some stuff out, and proceed with a better idea of where you're going. Books take time and tend to turn up surprises; don't assume your first outline will survive contact with reality. But you've got to start somewhere, so pick something and go.

I've been in the software world, as both a tech writer and a programmer, for, um, rather a few years. This answer is based on my experience and observations of the field. Oh, and I still write my introductions last.

Answer 2

The first step I would always recommend for any writing, but in particular for technical writing is to brainstorm and outline. Start by simply compiling a list of topics that you want to cover. Once you have that list begin putting them in a logical order. When you start putting them in order you will likely identify transition topics and support topics that didn't come to mind while you were brain storming.

I work in a software development shop and as a piece of advice don't assume your readers know certain facts or points. If your intent is to create a beginner's guide make sure you cover the basics. I have troubles with some developers who assume people know some of the basics of programming just because it is so second nature to them (by no means are developers the only people who over look the basics of their expertise).

Good luck.

Answer 3

When you make the outline, think about the scope of the book as well: what would you expect in such a book? What would you rather not see? For example, if this a book on advanced C++ techiques and threads, you probably don't want to explain what a class is. Think about your target audience.