How to start a technical book?
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).
This post was sourced from https://writers.stackexchange.com/q/9792. It is licensed under CC BY-SA 3.0.
1 answer
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.
0 comment threads
0 comment threads