Communities

Writing
Writing
Codidact Meta
Codidact Meta
The Great Outdoors
The Great Outdoors
Photography & Video
Photography & Video
Scientific Speculation
Scientific Speculation
Cooking
Cooking
Electrical Engineering
Electrical Engineering
Judaism
Judaism
Languages & Linguistics
Languages & Linguistics
Software Development
Software Development
Mathematics
Mathematics
Christianity
Christianity
Code Golf
Code Golf
Music
Music
Physics
Physics
Linux Systems
Linux Systems
Power Users
Power Users
Tabletop RPGs
Tabletop RPGs
Community Proposals
Community Proposals
tag:snake search within a tag
answers:0 unanswered questions
user:xxxx search by author id
score:0.5 posts with 0.5+ score
"snake oil" exact phrase
votes:4 posts with 4+ votes
created:<1w created < 1 week ago
post_type:xxxx type of post
Search help
Notifications
Mark all as read See all your notifications »
Q&A

How to start a technical book?

+0
−0

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).

History
Why does this post require moderator attention?
You might want to add some details to your flag.
Why should this post be closed?

This post was sourced from https://writers.stackexchange.com/q/9792. It is licensed under CC BY-SA 3.0.

0 comment threads

1 answer

+1
−0

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.

History
Why does this post require moderator attention?
You might want to add some details to your flag.

0 comment threads

Sign up to answer this question »