Writing a book, still the same pain 15 years later
1–10 of 85 posts
Re: Writing a book, still the same pain 15 years later
#2At risk of sounding like a low-effort critic, I have to say I'm not sure what we're supposed to take away from this post. It's got about zero useful information or interesting insight.
It really does come across as "How not to write a book" but without any sort of...life...to the writing.
I say that with nothing but respect and admiration for what Kent has contributed to the world of software engineering. As for this blog post in isolation, I just can't figure out who would read this blog post and feel it deserved to be shared around.
Re: Writing a book, still the same pain 15 years later
#3At risk of sounding like a low-effort critic, I have to say I'm not sure what we're supposed to take away from this post. It's got about zero useful information or interesting insight. It really does come across as "How not to write a book" but without any sort of...life...to the writing. I say that with nothing but respect and admiration for what Kent has contributed to the world of software engineering. As for this…
I think it's written for other writers. To help communicate the pain and process. It's easy to feel like it's "just you" and everyone else just shits perfect chapters, one per week, and hits publish.
I enjoyed it.
Re: Writing a book, still the same pain 15 years later
#4"Smalltalk Best Practice Patterns" was a good book
Re: Writing a book, still the same pain 15 years later
#5"Smalltalk Best Practice Patterns" was a good book
s/was/is/g
One of the biggest insights I gained was reading about "intention revealing selector".
Before that I had thought that we needed "higher level" programming languages, whatever that meant, exactly.
This made me realise the importance of naming (one of the two, three? hard things I computer science). If I could find an intention-revealing selector, I didn't need any higher level, because the current level was just fine.
This was the case much more often that I would have thought, it just required work. (eek)
And it also gave you an indicator that you might, in fact, need a "higher" language level, or more accurately an architecturally more appropriate one: when you can't create intention-revealing selectors.
Re: Writing a book, still the same pain 15 years later
#6Writing a book is easy. You sit down by the keyboard, slit your wrists, and pour your self out. (That's not a typo, btw.)
I've written one, and in the process acquired a near limitless admiration for those who can do it for living, book after book, decade after another. Even for a topic you feel should be easy - every page that ends up being in the final result, you have written at least 3x. The editing process alone is brutal, and the harsher, more demanding editor you get to work with, the better the results.
Re: Writing a book, still the same pain 15 years later
#7Ain't that the writer's life, though!
Re: Writing a book, still the same pain 15 years later
#8(Aw, I was hoping this would be about publishing a book with LaTeX...)
Re: Writing a book, still the same pain 15 years later
#9"Smalltalk Best Practice Patterns" was a good book
s/was/is/g One of the biggest insights I gained was reading about "intention revealing selector". Before that I had thought that we needed "higher level" programming languages, whatever that meant, exactly. This made me realise the importance of naming (one of the two, three? hard things I computer science). If I could find an intention-revealing selector, I didn't need any higher level, because the current level was…
If anyone else was wondering: http://wiki.c2.com/?IntentionRevealingSelector
> Name methods after what the method does, don't name methods after how it works.
Re: Writing a book, still the same pain 15 years later
#10(Aw, I was hoping this would be about publishing a book with LaTeX...)
I myself write books in Markdown. Each chapter has a markdown file, the book is version controlled with Git, there is a "build script" that does a "build" (in this case it's a shell script that concatenates the markdown files and runs them through pandoc and calibre CLIs to generate eBooks and PDFs).
When I send to my editor I just tell her to modify the files as she sees fit. When I get them back I put the new files on a branch and create a PR so I can start discussions on changes, etc.
I think the process is pretty darn efficient but it's hard to sell it to non-techie writers/editors.