While on sabbatical I started getting serious about writing a book. In spite of having wanted to write a book for years, writing one while on sabbatical wasn't my primary goal. But as visa issues in France became more difficult and made more traditional research work harder the book writing became a bigger focus for me.
Contrary to difficulties I've had getting journal articles published, getting this book published has been really straight-forward. By the end of the sabbatical I had a publisher lined up with a nearly-done book deal. This post is about how I made that happen.
Just to be clear, getting my written work published isn't easy or normal for me. Failed attempts is the norm. It took me six years to get one of my journal articles published. The editor for another journal nearly gave up on my paper because 20 reviewers refused to review it.
This book is different.
The planning began before I started my sabbatical. I realized that I needed a fresh take on an old topic in engineering and computer science: C programming. The go-to book on C, 1989's "The C Programming Language" (a.k.a. "K&R"), is often used in today's computer science and engineering classes, but it shouldn't be, for the following reasons:
- The book was written for technical people and not as a pedagogical tool. The style is wrong. Flowcharts? Diagrams? Spiralling or scaffolding? Nada.
- C is not an introductory language. In 1989 it was a good choice for an introductory general purpose language, because the options were limited. In 2019, there are much better introductory alternatives, from Javascript to Python to Matlab.
- C is niche. There are only two major groups left that should use it: operating system people (like K&R) and embedded systems engineers (my students). K&R wrote for the former. I'm writing for the latter.
Before embarking on this I realized that I needed to make the book distinct from K&R but also from the multitude of books on C programming that have appeared since. So, early on I nailed down the major concept: introduce C in its embedded systems niche, on four distinct embedded platforms (PIC, ATMEGA, and two versions of ARM). Secondly, I followed Fred Cady's example and structured the book so that instructors who adopted it would be able to use it in a way that helped them with their program accreditation (ABET, CEAB, CSAC/CIPS, etc.) needs. Finally, I realized that the book needed to onboard readers better: I would assume that they had background in Python and Arduino and would provide examples of those with each new C programming concept.
So I started writing. I rewrote the introductory part too many times, spent too much time trying to figure out which microcontroller boards to use (a bad habit with engineers). I finally settled. I chose the PIC16 board because of the class I was teaching at the INSA engineering school in Strasbourg, France at the time. The NXP802 was chosen because it was the simplest ARM chip I could find and the one I used at the Hochschule engineering school in Karlsruhe, Germany. The ATMEGA328P and SAMD21J18 were chosen because they are so popular due to the Arduino and Maker communities, both inside and outside academia.
With that, I began writing Chapter 1. By the time it was nearly done I received an email from University of Toronto Press. They were looking for possible textbooks to adopt for a new venture into the science and technical worlds. I pitched the concept, gave them a cleaned up version of Chapter 1 and a chapter-by-chapter structure for the book and waited for reviews to come back. I fully expected a rejection but was pleasantly surprised when all of the reviewers quickly came back with almost universally glowing reviews. I'd never seen anything like it in my publishing life.
While I was waiting for the reviews to come back I approached a friend of mine, Loren Wyard-Scott, about co-authoring the rest of the book with me. We had worked on previous pedagogical projects together and both of us teach similar capstone and embedded systems courses at the University of Alberta and York University. Coincidentally, my sabbatical year was 2018-19 and his is 2019-20, meaning that both of us could make the book writing sabbatical goals. He agreed, came on board and by mid-2019 we have a well-tested twice weekly meeting online or on the phone to work on and discuss the book. Each of us is working of separate chapters for the time being, although we think that that will change as we get to the end point.
As Loren and I established our work routine, adapting our current material and developing new material into individual book chapters, work progressed with the publisher. By the time I got back to Toronto in the Summer of 2019 we had a draft of the publishing agreement. We both got excellent feedback and suggestions from the librarians at York and U of A. That feedback made it clear that we needed to finalize the agreement using an IP lawyer familiar with the academic publishing world. We want to ensure that we are in good positions to use our material in our own classrooms, that our colleagues at York and U of A will also be able to use it, that we'll be able to make useful updates to book and use the core of the book for variations on other programming languages or hardware platforms.
As of October 2019, we're now awaiting the legal feedback so that we can finalize the publishing agreement. While my productivity has slowed down a bit since getting back into the non-sabbatical admin-and-teaching routine, we're on track to finish the book by October 2020, roughly coinciding with the end of Loren's sabbatical.
James Andrew Smith is an associate professor in Electrical Engineering and Computer Science Department in York University's Lassonde School. He lived in Strasbourg, France and taught at the INSA Strasbourg and Hochschule Karlsruhe while on sabbatical in 2018-19 with his wife and kids. This blog post is part of a series discussing the family's sabbatical year, from both personal and professional perspectives. You can view my Twitter postings from about Strasbourg (INSA) and HsKa (Karlsruhe).