, , ,

Following my article on Software Engineering Daily, here are some practical things that will help you if you’re considering taking on a technical book project.

Identifying a Publisher

While it is easy to self-publish today. The recognition comes from having worked with a traditional publisher as they have processes that ensure a level of quality. Not all publishers are equal, and some publishers are attributed with more prestige than others. In addition to this, some publishers are willing to take a risk on a subject and/or author. Have a look at the titles already published, and whether there are any publishers you can connect to.

When comes to contacting the publishers, most of their websites will have a page for recruiting authors. Some are easier to find than others. Here are a couple:

If, or when you get to talk to a publisher it is worth ensuring you understand how their editorial process works and what is expected from you? Plus what happens if you find yourself in the position of not being able to work to the original schedule. Day-to-day work can get in the way which you hadn’t expected.

Planning content

It pays off to work out early on what your book will cover, in the form of chapters and major headings. If you haven’t already done this then any publisher you approach will be asking for it. If you have this worked out that will help show the publisher you’ve given the whole subject some serious thought.

If you’re working with other authors then working out the chapters and major headings will help split the work up and ensure the writing effort isn’t duplicated.


If you’re considering co-authoring, it is worth ensuring you both/all have similar views on the technology(ies) being covered in the book, as well as the approach to the book and style of writing, and visuals are reasonably well aligned. For example, my writing style tends towards writing in the way I hold a conversation, while others prefer the third person and expressing things in the fewest words possible. If there are discrepancies then you’re likely to experience some level of friction. What is more important is the reader doesn’t find the reading experience schizophrenic. While I haven’t experienced this problem, I have heard horror stories where authors end up no longer talking with each other.

Fixing language issues

Most developers are not linguistic gurus if we’re honest. But we can overcome that, so the core of our writing is not hidden by grammatical errors. While there are other tools available, I have found the full version of Grammarly to be hugely helpful. aside from picking up the missing comma etc, it can also suggest alternative ways to structure a sentence so the wording will parse better. This often forces me to back and reread what I’ve written rather than what I thought I’d written. Occasionally I find the suggested wording to flow better than my original sentence construction.

What does your reader know?

When writing it is worth keeping in mind what you expect your reader to understand. It is even worth setting out such expectations, both at the book level but also potentially chapter by chapter. Jumping into detail quickly without having warned the reader of your expectations is a good way to irritate a reader and solicit poor reviews. if you don’t want to get sidetracked by certain points then don’t be afraid to point the reader elsewhere for that material (just don’t point the reader to a book published by the competition).

Diagrams and using logos

Some publishers will expect or assume that you have got clearance for using copyrighted details such as logos. So when creating or using images you record where the logos or graphics come from it is worth recording where the resources are from. It will save a lot of time when it comes to confirming permissions when doing the final checks and due diligence.

When creating diagrams – remember most books are printed in black and white – so ensure your diagrams will still look fine in black and white. It is so easy to use color shades in a diagram that are difficult to differentiate when printed on a grey scale.

Early release programs

A lot of publishers will offer an early access program where your initial drafts of chapters may be made available online. This is a good way to help gather interest in the book title and start picking up sales. The publishers will also promote the books in early access programs.

The completed manuscript isn’t the end

Depending on the publisher they will provide some support in terms of marketing, and will also look to the authors to support any brand-wide promotions. But to keep a title selling you need to keep it in people’s awareness. There are a lot of ways this can be done. But personally, we’ve presented at conferences, and in the introduction, I include a slide with the details of books, etc. I blog on the subjects I’ve written about and take the approach with the relevant blogs to reference the book – at the same time careful not to produce content that would detract from potential sales.

Get your employer involved, you don’t need to be working for a company that is selling services or solutions directly linked to your product for them to see value in helping you. Aside from being generally supportive of an employee – which is always a good thing. An employer can gain value from such involvement because they can ride on your authoring credibility to entice potential employees to the company (with the “hey we’re great to work for, look at the talent already here”). They may find it useful to buy copies of your book to give away at conferences (same sort of ‘inherited’ credentialization).


I’d like to thank both Louis Weir and Andy Bell for their input to this and the related article. Not to mention other co-authors including Robert van Mölken.