Things I learned writing my first technical book
blog.klipse.tech
Things I learned writing my first technical book
1–10 of 34 posts
Re: Things I learned writing my first technical book
#2Most of it could be said about any UX in general
Re: Things I learned writing my first technical book
#3[deleted]
Re: Things I learned writing my first technical book
#4Most of it could be said about any UX in general
Or about making a product
Re: Things I learned writing my first technical book
#5> Mind maps are a great visualization tool. Use them smartly
I’m curious about this, since my experience with mind maps is that they rapidly grow into giant overly-connected graphs that are very difficult to translate to the sort of linear structure a book or blog post needs. What is OP’s workflow for connecting the two?
Re: Things I learned writing my first technical book
#6Highly valuable tips & tricks, all of them encouraging, which is rare. Usually authors start with 'Don't write a book' or 'Think twice before start writing a book'.
I've also started writing a technical book and I find it challenging in the same pleasant way.
Writing is much much harder than programming because you can't test prose and you don't have a programming language. But the deliverables are the same: something which runs flawlessly on a processor.
Writing a book is much harder than writing articles because a book has to stay interesting for hours, while an article for just a couple of minutes.
Getting a writing mindset is far harder than getting a programming mindset: I can write code any day, any time but sometimes I can't write a paragraph a day.
Re: Things I learned writing my first technical book
#7> Mind maps are a great visualization tool. Use them smartly I’m curious about this, since my experience with mind maps is that they rapidly grow into giant overly-connected graphs that are very difficult to translate to the sort of linear structure a book or blog post needs. What is OP’s workflow for connecting the two?
I ran in the same issue. And I've created Coco - a Content-as-Code framework to split large graphs / mind maps into small, understandable chunks.
You can take a look at how Coco works here: http://metamn.io/react/on-design-systems-3/ (All figures except the first were made with Coco)
Re: Things I learned writing my first technical book
#8> Mind maps are a great visualization tool. Use them smartly I’m curious about this, since my experience with mind maps is that they rapidly grow into giant overly-connected graphs that are very difficult to translate to the sort of linear structure a book or blog post needs. What is OP’s workflow for connecting the two?
Yep. Half the fun/challenge of writing a book (I’m on my fourth) is finding the right linear sequence.
Re: Things I learned writing my first technical book
#9This is probably a good list. Some points I don't agree with, but, as a person who kind of invested in the book by buying it while it was in MEAP at Manning, having high expectations for it, I can say I was extremely disappointed with the content. I found some passages unclear at times and the whole idea of mapping the data oriented programming approach taken from functional programming to a general purpose way of designing programs and using JS to convey the message, somehow didn't make it click for me.
It's a good list of tips and I hope the book was successful and helped people!
Re: Things I learned writing my first technical book
#10That’s a good list!
My fave:
> An average writer makes the reader think the author is smart. A good writer makes the reader think the reader is smart.
I am quite surprised to see no mention of the importance of an editor. I have to assume that they are no longer as important, these days, as they once were.
My mother was a scientific editor, and she was brutal. I once wrote a 400-page book (that was never published). She edited it for me, and it may be the most perfect prose I’ve ever produced (but it was out of date and technically irrelevant, by the time it was ready).