Writing a technical book: from idea to print
sararobinson.dev
Writing a technical book: from idea to print
1–10 of 36 posts
Re: Writing a technical book: from idea to print
#2This is a nice summary, and shows the benefit of working with a publisher, when you are writing a book that is similar to ones they have published already. You get a lot of support, and will definitely benefit distribution-wise later as well. Congratulations to the author - especially on publishing relatively quickly, in 10 months from the idea! And it's very nice to read that all royalties are going to Girls Who Code.
I've worked with O'Reilly and a few other publishers on a proposal that was slightly different to what they usually publish. I went through the same submission process, working with an acquisitions editor, similar to how it happened in this case. In my case, O'Reilly rejected the proposal after a month and half. The feedback in my case was that the book competes with another project, which project got priority. Sure enough, I took the proposal without any changes to another publisher, worked with the acquisitions editor there, had the proposal accepted and we went ahead with the writing process with a development editor.
In the end, working with the other publisher did not work out for me. They did not publish the type of book I was writing, and the feedback from the editors kept nudging me to "shape" the book into the type of book this publisher knew would sell, and would sell well. Unfortunately, it didn't feel like the type of book I was excited to write.
A year and some time later, I'm still writing the book -The Software Engineer's Guidebook[1] - and if all goes according to plan, I'll publish it early next year.
What I've learned with working with a book publisher, is just how involved the process is. Now, instead of taking a $5,000 royalty upon completion of the manuscript, I'm budgeting to spend around $5,000 out of pocket on development/copy editing, cover design and production editing. The things that the publisher would have otherwise paid for. It's a bit simpler to hire professionals these days for these areas thanks to sites like Reedsy[2], which I do recommend for fellow authors self-publishing in finding support on various publishing tasks.
Re: Writing a technical book: from idea to print
#3This is a nice summary, and shows the benefit of working with a publisher, when you are writing a book that is similar to ones they have published already. You get a lot of support, and will definitely benefit distribution-wise later as well. Congratulations to the author - especially on publishing relatively quickly, in 10 months from the idea! And it's very nice to read that all royalties are going to Girls Who Cod…
I've had mixed feelings about publishers in the past. There is probably still some cachet in a name brand publisher. And they do some things for you which would otherwise take time. On the other hand, for better or worse, editing was pretty lightweight and more errors crept through copy-editing than should have. I did go ahead with a v2 of one book but I probably wouldn't actively pursue a publisher if I do another book at some point.
The summary makes it sound as if the co-authors worked together pretty well although I'm sure it wasn't completely friction-free. It's very easy to end up with a co-author who likes the idea of having written a book more than they like the act of writing it.
Re: Writing a technical book: from idea to print
#4I am also now writing my first book (https://efficientdeveloper.com/) and it is really difficult, especially during Covid times (my original idea of writing this book was writing it on a transatlantic cruise... )
What you realise when writing a book is that every sentence gets rewritten 3 times, even before you start caring about proofreading. With all the research and decision making, publishing etc. it takes much more time than it looks.
Re: Writing a technical book: from idea to print
#5I am also now writing my first book ( https://efficientdeveloper.com/ ) and it is really difficult, especially during Covid times (my original idea of writing this book was writing it on a transatlantic cruise... ) What you realise when writing a book is that every sentence gets rewritten 3 times, even before you start caring about proofreading. With all the research and decision making, publishing etc. it takes much…
It really is. I've been going through a fairly significant book revision the past few months. Of course it's been more work than I thought--even though I should have known better.
However, even though I'm making quite a few changes/additions including a new chapter, it's a lot easier to patch something that exists than starting with a blank page. The fact that I don't need to churn out a huge number of words lets me focus on the new material and refactoring as needed.
When I was an industry analyst, I used to joke that the effort to write something went up by something like the square of the page count. There are counter-examples but mostly I think it's at least somewhat true given that you need to sort of keep your head around the whole project.
Re: Writing a technical book: from idea to print
#6I am also now writing my first book ( https://efficientdeveloper.com/ ) and it is really difficult, especially during Covid times (my original idea of writing this book was writing it on a transatlantic cruise... ) What you realise when writing a book is that every sentence gets rewritten 3 times, even before you start caring about proofreading. With all the research and decision making, publishing etc. it takes much…
> It took an hour to read, I thought it would take an hour to write.
Re: Writing a technical book: from idea to print
#7This is great and really useful to me! I am also, like others here, in the process of writing my first "book": https://redis.pjam.me/. Mainly inspired by https://shop.jcoglan.com/building-git/, rebuilding Redis, instead of git, in Ruby.
> For my first few sections I wrote the code as I wrote the sections, but then Lak made the suggestion that it would probably be easier to write the code first and then write the chapter
I can echo this a thousand times, I've written the last three chapters this way and this has made a huge difference, wish I had known that earlier!
I will also add that it really made me learn so much because even though I thought I knew quite a bit about Ruby (I knew early on that I didn't know much about Redis). So many times I found myself trying to explain something and realizing that I didn't actually know how it worked and ended up spending hours (days?) researching the inner workings of said thing
PS: Using quotes around book mostly because that's the imposter syndrome kicking in, I was calling it "a series of blog post" for a while, to kinda downplay it
Re: Writing a technical book: from idea to print
#8This is a nice summary, and shows the benefit of working with a publisher, when you are writing a book that is similar to ones they have published already. You get a lot of support, and will definitely benefit distribution-wise later as well. Congratulations to the author - especially on publishing relatively quickly, in 10 months from the idea! And it's very nice to read that all royalties are going to Girls Who Cod…
I've been working on my first book with Manning (should be out in the next few months).
Without the structure a publisher provides it's likely I would not have come even vaguely close to finishing.
The marketing is icing, really.
Re: Writing a technical book: from idea to print
#9This is great and really useful to me! I am also, like others here, in the process of writing my first "book": https://redis.pjam.me/ . Mainly inspired by https://shop.jcoglan.com/building-git/ , rebuilding Redis, instead of git, in Ruby. > For my first few sections I wrote the code as I wrote the sections, but then Lak made the suggestion that it would probably be easier to write the code first and then write the ch…
> So many times I found myself trying to explain something and realizing that either I didn't actually know how it worked and ended up spending hours (days?) researching the inner workings of said thing
This has been, by far, the best thing about writing.
It is also, by far, the worst thing about writing. The constant terror that I am full of shit.
Re: Writing a technical book: from idea to print
#10This is a nice summary, and shows the benefit of working with a publisher, when you are writing a book that is similar to ones they have published already. You get a lot of support, and will definitely benefit distribution-wise later as well. Congratulations to the author - especially on publishing relatively quickly, in 10 months from the idea! And it's very nice to read that all royalties are going to Girls Who Cod…
I've been working on my first book with Manning (should be out in the next few months). Without the structure a publisher provides it's likely I would not have come even vaguely close to finishing. The marketing is icing, really.
Deadlines are definitely a double-edged sword. On the one hand, they can be really inconvenient if something takes longer, other priorities pop up, you just feel you need to release a chapter even though you're not really happy with it, etc. On the other hand, in the absence of deadlines, it's easy to put things to the side for a "week" that turns into a month or two.