It Seems Like I’ve Been Here Before …

People seem fairly impressed when I mention that I’ve written a couple of books on databases and software. I try not to make a big deal of it, just mentioning it in passing as appropriate, because I actually don’t consider it to be a big deal. I’m one of those people who likes to share knowledge, likes to write and has accumulated a decent amount of knowledge on a few things. Occasionally, that knowledge demands to be organized and backed up in article or book form. There’s also been the hope that others will find it useful in their own lives and might actually pay for it.

Previous Projects

I’ve actually written three books and they all have their own stories. I titled the first one Microsoft Access for Beginners and it grew from a few pages I wrote for a friend who wanted to know more about Access, although certainly not as much as I bombarded her with in those pages. It then became a series of articles on my site. After being laid off from a job one day, I immediately headed to the local Starbucks and started fleshing out the book for publication. Mostly, I wanted to take the project to its natural conclusion and move on to other things. I self-published it rather than try to get any publisher to take it seriously. It sold a few copies and has since wandered off into some obscure corner of Google’s search results.

The second book was Your First Guide to Database Design. It was more of a more general look at database design than the last one since I’d moved beyond Microsoft Access. I also saw a need for a practical guide to normalization and other database principles and thought I could fill it with a book. I promoted it a little bit more than the first one, it sold a few more copies but didn’t make any best seller lists.

It did lead to the third book, however, when I had a chance meeting with the owner of a publishing company and he later checked it out. This resulted in a contract for MySQL Explained, a rewrite of the last book specifically for MySQL. This time, I had a publisher who knew and cared more about promotion than I did and the book easily sold many more copies than the first two put together. It was actually Amazon’s #1 book on MySQL for a time.

Why Write a Book?

As I said, I don’t consider the act of having written a book to be worthy of bragging rights, even if it’s been picked up by a publisher. Certainly congratulations are in order if your book sells really well or becomes influential in any way but then both those things could be said of books like “Fifty Shades of Grey”.

For me, as someone who writes technical non-fiction, writing is about creating a great resource that someone can learn from. The reward comes from hearing how someone has been helped by it and being able to go back to it months or years later and still see it as something great. That’s the drawback, too, since we are our own worst critics. I go back to my previous books and cringe really hard at things I could and probably should have done better. I’m continuing to gain experience both in the material and its presentation and I see ways that I know I could improve on my old work.

That’s what brings me to my next book, tentatively titled Understanding MySQL and MariaDB, which will be a follow-up to MySQL Explained. This time, I will be including MariaDB, the offshoot of MySQL and using more of a textbook approach to provide a completely updated look at database design with both MariaDB and MySQL.

Eating that Elephant

Over the years, I’ve also been fortunate to have learned an appreciation for language and attention to detail which are both essential for a writer. The attention to detail is especially important for a one-man book project like this one. The amount of detail to consider on this book is actually intimidating and has led to me procrastinating on it for awhile. I knew over a year ago that MySQL Explained was in dire need of an update. I was a little embarrassed to leave it the way it was on Amazon but there were other projects demanding my time and only so many hours a day I could glue myself to the computer so it had to wait.

The details will vary based on the project and the writer. I’m detailing this here just to give you some idea of the detail that’s necessary to create a quality result that readers will be glad to have paid for. For me, the process on this book breaks down something like this.

Build the outline

The book does have to be about something and have some kind of structure, after all, even if it’s just so you can have a nice-looking Table of Contents. With this project, it means:

• Reading through the previous book and noting all the improvements needed
• Reading other references I could find on MySQL and MariaDB and noting any features or subjects I hadn’t thought of
• Assembling the subjects in some kind of coherent order that will probably change as I actually write the material

In addition to this, the new book will be much more lesson-oriented than the last. That meant the outline items needed to be broken down into specific ideas that can be tackled in a single lesson.

Outline the individual chapters

Since the book is going to be presented as a series of lessons, the individual lessons need some kind of structure, preferably a consistent one. Since my last book, I spent a couple of years teaching computer programming. During that time, I learned through both training and hard experience that teaching a subject is about a lot more than just writing paragraphs of theory and instructions and expecting students to read for understanding. It’s about presenting the material in a way that the student can actually understand, often in multiple ways for different students.

Of course, this is still a book designed to be read but there are still things that can be done within that format to make the information more accessible. I came up with a chapter outline where the subject and learning objectives for each lesson are clearly stated in each chapter. The summary at the end of the lesson also focuses on what the student has gained during that lesson and how it will benefit them later. I will also include chapter questions and answers in this version so the readers can review the important points. Another section of each chapter suggests additional practice and exploration that will help the reader expand on what they’ve learned there.

Dust off the writing tools

I really like the ePub editor Sigil. It’s easy to use with a user-friendly interface. The version I’m using does tend to replace paragraphs with DIVs which is an annoyance but overall, it’s a great program. During the last project, I was able to use Amazon’s software to convert the ePub files into MOBIs that I could upload to Amazon for publishing. The only drawback was having to maintain a separate manuscript for the electronic and print editions. If you’re wondering whether a print edition is still necessary in 2020, you should know that my print edition of MySQL Explained often outsold the Kindle edition 2 to 1.

When I started getting bogged down on one of the chapters, I switched tasks and updated myself on Amazon’s Kindle tools. Kindle Create is now available and is a nice improvement over the tools I remember. The program makes it easy to create Kindle projects based on Microsoft Word files for novels, essays and other reflowable material or PDF files for fully-formatted books like textbooks and cookbooks. It also helps maintain links and insert multimedia in the electronic version and then outputs KPF files for uploading. This means I can actually create one manuscript in Word, apply all the formatting I want to and use it for both editions of the book.

Kindle Previewer 3 is another nice tool that lets you see what your finished product will look like on different devices with different settings.

Define the styles

If you’ve read any computer books over the years, you might have noticed they often have a section in the Introduction where they explain the icons and style conventions used for things such as warnings and links to additional resources. For this book there’s also the question of how to represent things such as menu options, command buttons and SQL code both as blocks and inline within paragraphs.

All those styles have to be defined somewhere so I can consistently apply them throughout the book. Consistent styles provide a more professional look and make things easier for the reader. I started using Sigil before I discovered Amazon’s new tools and had a pretty good CSS file built up. Then, when I realized I’d be using Word, I spent time time getting familiar with Word’s style settings and moved the styles there. I’m sure they’ll continue to evolve somewhat.

Define the standards for graphics

Technical books are often heavy on graphics, including screenshots. Windows generally captures screenshots at 96 dpi which is low resolution for printed material. Windows fonts and graphics might be two light or low-contrast for the printed page and the detail you need might be too small when the image is shrunk down from your monitor onto the document page. If you don’t want your images to look blurry, muddy or otherwise useless, you have to pay attention to how each one looks in the document. Also, it’s good to have consistent sizes for images within your pages. A good image editing program like Paint.Net is essential.

Finally, for the printed edition, there’s the issue of how your images will affect the flow of the text and the page breaks. Large amounts of blank space because of an image that’s forced onto the next page don’t look great in a book. This means juggling some paragraphs around and making sure any references to images clearly identify the right one. Sometimes, this means numbering the images (Figure 1, Figure 2, etc..) and that has to be tracked, too.

Then there’s the task of putting together some decent cover art. I’m really glad I found Canva.com.

Do some actual writing at some point

The relationship between the actual writing and all the other activities I’ve mentioned here is similar to the one between coding and all the other parts of software development. It’s tempting to just jump in and start churning out lines and paragraphs but all the other activities are what really make the product worth anything.

Still, you do have to generate a decent word count on a regular basis if you actually want to produce a book. That means staying off Facebook and away from Netflix and actually sticking to a work schedule if possible.

Then, the best argument for brevity is that every word you write has to be checked, re-checked and checked again, especially if you’re checking your own work. It’s amazing howe how spelling and grammatical errors just appear out of nowwhere nowhere when the words seemed so perfect as they where were being typed. Bad grammar, spelling and punctuation is the most common problem in writing and will ruin your credibility faster than anything else.

For technical works, fact checking is also a major activity. My proofing checklist for the lessons on this book looks something like this:

• Proofread for grammar and spelling.
• Fact check review 
• Review for passive voice and overly complex phrasing. 
• Review for glossary terms.
• Review for clarity.
• Review to ensure main points are emphasized.
• Scan for cross-lesson references.
• Set next review date. 

Each one of those reviews needs to be done separately to avoid missing problems by looking for too many things at once. For all those steps, it’s actually a shorter list than what I do for major blog posts like this one where I also scan for opportunities to insert outbound links and ensure that the article is Google-friendly.

Of course, if you can get other people to do some reviewing, that’s great. Unless you’re willing to spend some serious cash out of your anticipated profits, however, you’ll probably just want to schedule some time between each read-through so you can approach the material fresh.

Find a home for supplemental files

If you’re including extra materials with the book like code, sample files or online videos, the easiest way to do it is now through a website – either your own or a third-party site. Whatever site you use, it has to be clearly mentioned in the book and maintained at least for a few years after the book’s release unless you want your readers to encounter a bunch of broken links.

Another issue is the length of the URLs for the links. Electronic book formats are great for enabling your users to quickly access online content but your printed edition is a different story. Your readers aren’t going to want to type in long, confusing URLs in order to get to those supplemental files.

Any corrections or updates you want your users to see after you publish, also called the errata, should also be easily available.

No matter what other sites you use such as YouTube or GitHub, an official page on your own website is probably the best strategy as a central hub for all the links your readers will need. Your book can then point them to that one page and reference specific items on it as needed. If done well, it’s also a great promotional tool. It’s also another item that needs regular updates and proof-reading.

Final Proof

No matter how much proof-reading and checking you’ve done, there’s that one final read-over for each edition just before it’s published. By this time, you’re sick of your own writing and tired of the subject itself but you do it anyway because the last thing you want is to see Amazon comments about the typos and formatting issues you missed. The nature of electronic publishing and print-on-demand books makes it easier to fix errors after the initial publish but it’s still something to avoid.

Publishing and Profits

The actual publishing and royalties process is a story in itself and I’ll leave that for another post. The process doesn’t end when you click the Submit button and the experience of maintaining that book has it own set of thrills and challenges.

It’s a huge amount of work to properly produce a book. In the end it’s worth it for those moments when you see that you’ve actually created something good whether it’s when the manuscript finally starts looking like a book in progress or when readers contact you or leave 5-star Amazon reviews. As with any type of work, if it’s something you enjoy, it won’t be long before you’re thinking of the next project to take on.

---

Nexus: A Brief History of Information Networks from the Stone Age to AI

• #1 New York Times Bestseller from the author of Sapiens: A Brief History of Humankind
• Published September 2024
• 528 pages

Check Price

ComeauSoftware.com uses affiliate links through which we earn commissions for sales.

---