Core S2 Software Solutions

Writing a self-published book: the good and bad

Last Month I released a self-published book titled “3D Computer Graphics: Software Revealed“. I’ve worked on it on and off  starting about two years ago, with a full re-write beginning six months ago, and a second edition coming in a few short months! It’s been a long adventure to write something I feel comfortable enough publishing, but it was absolutely fun and well worth it! Just like when I tutored friends for various computer-science topics, doing this activity was a great way to better understand a topic. I specifically remember working with friends in my undergraduate systems-programming class learning on how alerts, handles, and system-calls worked. I learned faster in that situation than I could of by just sitting down and reading a book or even attending a lecture or two! This book was a great way to achieve the same effect: by writing down my initial thoughts, and then reviewing them against notes from classes, books I own, and the ultimate help for answering random questions or research: Wikipedia. Overall, it was a great experience, but not without some lessons learned on the experience itself. Let me elaborate a bit more on what I’ve learned:

On a quick tangent, please consider donating to Wikipedia; it was an enormously helpful source during my studies and work on this book. Without Wikipedia, it would of taken a substantial more amount of effort to finish this book! Donate or contribute your time – I’ve done both, so should you!

Developing material is easy, writing to and audience isn’t. The easiest part of writing the book was the actual act of putting down material, either by writing code, text, examples, or random thoughts that I later merged into the appropriate sections. When it comes to turning this raw material into something worth reading, that’s where the real challenge comes! The process of taking your material and making it easy to read and understand is difficult because important ideas are simple and bland, nothing exciting for the reader to see. If you do make something more interesting, you can fall into the trap of over-complexity! You have to make sure every idea is balanced: easy to follow, yet interesting, but complete enough to be an independent thought for the reader to grasp. Writing your material as though you are presenting it in an excited voice really helped me: saying “barycentric coordinates are an easy way to map textures to 3D surfaces” is plain and overly simple, and thus completely uninteresting. What I did was follow each new subject with a clarity of purpose and application:  “barycentric coordinates are not only easy for all types of texture-mapping (textures, bump-mapping, specular maps, etc.), but the related math operators are quickly executed with parallel floating-point hardware”. The language is still bland, but the reader can at least immediately gauge the importance through the mentioned application. For every one sentence originally written, I must of at re-written it twice trying to add clarity or interesting relationships. For technical subjects, I also found it very helpful to constantly relate ideas together: if I mention texture mapping in the previous subject, and I introduce secondary texture maps (i.e. bump-mapping), I might write and independent section explaining all major texture maps used in professional model-skinning. My favorite part of a new tech-subject book is just skipping around and looking for those “Coding Horror” bits like in Code Complete.

I’ve learned to explain every idea in three ways: first conceptually (definition), then through procedure (math / steps), then through application (code). Much like the first point, where writing to an audience is much more challenging than writing the core content, I’ve also learned how to better explain ideas as a whole. While working with friends and tutoring in college, I realized that there are several ways people prefer to learn. I’ve never taken a formal “teaching” course, but with the power of Wikipedia I did learn about teaching methods. Many of the methods boil down to two groups (this is a simplification, but I still found it helpful): logic-based learners (learn as though the idea is a procedure) and application-based learners (learn through example and how the idea is applied). In my book I tried to do both with a middle ground: I always tried to define the idea as cleanly and as independently as possible, then I explained any sort of steps or dependencies of the idea, and finally I always provided some sort of example or code. Doing these three, I believe, works well in explaining all of the core concepts, and reinforces the material for the reader.

Time: takes huge effort and time to re-read material. I hate to sound like a broken record, repeating much of what I’ve already said, but… writing to an audience is hard! It’s hard because much of what you write has to be edited, reviewed, re-written, re-read, etc. This takes a huge amount of time. For better or worse, I spent a significantly more amount of time editing than writing the original material. It also pained me that some time truly does get wasted: I wrote much more than what was in the final version of the text, simply because the text had to be re-written or wasn’t in the scope of the book. What’s interesting to note is that this “lesson” I learned is a true lesson in software engineering: it’s impossible to plan your efforts perfectly, and naturally you will waste time on some feature or block of code that gets removed, changed, or re-implemented.

Distribution is easy, Marketing is hard. I chose to distribute the book through as many mediums as possible, and only spend time for marketing but no real cash. Setting up book sales through Amazon (eBook version), CreateSpace (physical version), and PayPal (PDF version) is fairly easy. There are some hoops you’ll have to jump through, though nothing unreasonable. My only disappointment was that Apple doesn’t allow self-publication through its services, but you can use third party publishers (which are as difficult as Apple was). I never tried to reach out to a formal publishing group simply because I’m well aware of how challenging it is to publish a book and the costs associated with it (I’ve talked to a few professors who have published books – it’s a crazy-nasty business, with authors not getting their fair share back IMHO). As for the marketing itself, I only focused on social-media (thank you Reddit!). It’s free, easy to use, and fairly very quick to push sales! In one day’s worth of marketing on Reddit (by simply posting two submissions), I grew my daily average traffic by 3,000 unique visitors and sold about 40 copies. The day after I sold about 20, then about 10, and after that the sales went back to the regular trickle. Am I making money? Yes! Will it pay back the time and effort put in? No, but I don’t care about sales – I cared more about the experience the the satisfaction from having the physical book in my hands. I’ve now started a secondary marketing push to professors, which seem like the next logical step. I’ve now have two professors who have my materials listed to their students in the course description / class-sheet. I’ll have to now start reaching out to other universities and professors I may not have any relationship with, but it’s at minimum a great way to push out my name. Google Analytic has also played a huge roll in better understanding who is visiting and who is buying! I’m not surprised by any of the data (i.e. most sales are in America, Germany, and France), but it’s a great way to really quantify and track the results of any efforts I do.


On the left is the Reddit-driven spike, the big focus on my initial marketing push. On the right is the average web-traffic, which consists of around 20 to 40 visitors across all my sites (this blog, my other projects, and my source-code repositories).

Listen to feedback, and always talk to your readers. Readers are great: you’ll  always get feedback if you ask people. In general my feedback has been positive, but with a few suggestions for smaller changes. Even negative feedback still contains some gems! I know that for my next version of text, I’ll have to introduce two new sections to clarify a general idea (translation and rotation), as well as improve a weak section (introduction and origin of the 3D rotation matrix). Minor errors like broken links, spelling, and grammar are also getting caught – it’s amazing what a group of readers can find, even if I’ve re-read my material many many times. If I get enough sales, I’ll absolutely do what Dr. Knuth does with his $2.56 error-finding checks! (Which reminds me… I really need to buy his “Art of Computer Programming” series). Finally, this is a one-man operation: I want to make sure that if there are questions or comments, I actually talk directly to the readers. There are no PR agents or sales people between me and who buys the books – not only do I like to listen to what people say, but I’m sure it gives a positive affect on readers knowing the author explicitly pays attention to them. It’s a win-win as well: it continues the education-enforcement cycle, where if a reader has an issue or question, then clearly I haven’t done my job well enough, and I can in-turn improve my material and potentially learn something new myself. Open-sourcing the code on a platform that’s easily accessible and guaranteed to stay has also really been successful, with positive reader feedback: the 3D Tutorial source-code GitHub page isn’t on any weird or unique URL like many books unfortunately do. It’s easy to access, and no big zip-file download is required: code can be viewed and executed in the reader’s browser!

What’s next? I’m currently working on a presentation and hand out material for an iOS developer course I’m teaching through the ASUW Experimental College: the University of Washington’s “teach your own class” program. Though I could write a book on this subject, I’ve never felt happy with the general concept of books-on-ideas-and-not-one-idea. This is because not only does the content constantly change (iOS tools, submission process, etc. are evolving in big ways with every release) but because a pair of specialized books are still better introductory materials than a high-level book on everything. I’m a big fan of quality vs. quantity in terms of reading.

After teaching the ASUW course, I’ll be attempting to write a memory-management book, which is a subject I find very interesting! It’ll be much longer than the 3D-tutorial, and have much less maths, but will have more programming-language discussions and case-studies on real-world applications. This subject isn’t saturated with reading material, so there is absolutely a market need for it! Hopefully I can start getting physical copies to show up at universities – a programmer can certainly dream of it ;)

All in all, well worth it. Thank you very much readers, it has been a blast doing this little project!


This entry was posted in News & Updates. Bookmark the permalink.

Leave a Reply

Your email address will not be published.


Sites map