Written by 20:30 EST, 28 February 2021
The date above is when I completed the first, full draft of my book, Programming the Internet of Things. That was less than a day ago, as of this post’s timestamp.
This project has been – so far – the most challenging undertaking of my technical career. There were times I wanted to throw in the towel and others where I planned for detailed follow-up volumes, articles, blog posts, etc.
Frankly, I’m glad to be done – at least with the initial pre-final draft.
Some Background
Programming the Internet of Things is largely based on the programming exercises I developed for my Northeastern University College of Engineering graduate course, Connected Devices. It’s a lab-focused class with some lecture content, and a ton of programming exercises designed to help students understand the complexities of integrating custom IoT environments, from device communications to cloud integration.
Creating course content for such a class (and from scratch) involves a significant amount of annual (if not semester) updates due to changes in library versions, hardware improvements, cloud service offerings, etc. So, I touch on a number of things to help introduce the concepts and some key principles, but focus mostly on edge tier integration (that is, how different types of devices can talk and pass messages using protocols such as MQTT and CoAP).
If you’re reading the book, you’ll find I spend a lot of time on these concepts. In my professional work as a consultant and educational work as an Adjunct Professor, edge tier integration is the area where I’m most often asked to assist. Questions like, “What kind of device (or devices) do we need?”, “How are they going to communicate (and what protocol(s) are best)?”, and “What data do we need to collect and how (and where – and when) should we act?” are common, so I attempted to address these throughout.
You may have thought of other questions as well, such as “Which cloud service provider should I use?”, “Which analytics engine is best suited for problem x?”, and “How will I provision all of my devices?” Each of these are important focal areas for an IoT ecosystem, and volumes can (and sometimes have) been written on each. While I address cloud connectivity and provide some sample use cases in Part IV, I’ve left these and other cloud-related questions to be answered by the plethora of existing resources. I hope you don’t mind.
Why I Wrote the Book
In short, I mostly wrote this book for my students and as a teaching resource I can use in class. But, why (and perhaps, how)?
There are many interesting and difficult challenges associated with building an IoT ecosystem, and my book doesn’t address them all. I primarily focused on that first set of questions. They are, I believe, most helpful when seeking to understand how the technical underpinnings of an IoT ecosystem functions, and yet I found it difficult to find a singular resource that pulls them all together for programmers.
So, I created my own content, which – while continuously updated – is the foundation for my course, Connected Devices, and has provided much of the substance behind Programming the Internet of Things.
What I Learned
I generally like to write, so writing itself is usually fun and easy. But, ‘like to write’ is a loaded phrase, and ‘fun and easy’ isn’t exactly apt for this project (well, it was fun, but certainly not easy). Here are some nascent self-reflections from the process:
Stick to the Plan – But Don’t Fear Re-Scoping
Most (perhaps all?) technical books start out with a roadmap – an outline representing the ordering of content, and what will be contained within each section. I thought I had a well-crafted and detailed plan starting out. And I did, except the original plan would’ve resulted in an 800-page tome. Yikes. Might as well go live in a cave and just write for a year.
Clearly, this wasn’t tractable. So, we re-scoped – just a bit – by focusing on the key problem areas I felt would be most helpful, and to which I was best able to contribute. I removed a planned section on a third protocol, and whittled down the cloud integration section, which not only allowed me to stick with the schedule, but helped me keep my eye on the prize (more on this later).
Even with this (slight) re-mapping, re-routes, alternative paths, and second-guessing still came into play. I had to constantly remind myself to ‘stick to the plan’, and revert back to my original (and reviewed / approved) roadmap to stay the course.
One way I tackled the sheer quantity of material: I decided to write some sections out of order – starting with the content I felt was most ready to convert into written form. With the roadmap in place, it was relatively easy to insert these out-of-sequence sections into the appropriate place.
Iteration is Good – Until it’s Not
I knew I would to have to battle my ‘perfectionist’ tendencies in general, but didn’t realize how much of a liability (and a benefit) it could be. They say ‘don’t edit as you go’ to new authors. Of course I ignored this advice, at least initially. This caused me to get stuck at times, unable to move forward because some of the content wasn’t good enough, or detailed enough, or … (fill in the blank).
So, what was the upside? It helped me to be (I hope) a bit more thoughtful about what detail might be useful for a new learner vs that which would be too banal for someone more experienced in the subject. Hopefully, I found the right balance in the end.
One trick I picked up along the way (thanks to my wife and son): Write everything out in outline form – numbered sequences, bullets, etc. – and re-purpose as more readable prose in subsequent edits. This allowed me to maintain the mapping of content to the plan without going (too far) off the rails.
Feed the Reward System – But Don’t Get Complacent
Writing this book was absolutely exhausting. When I finished one part – even if it was a lengthy chapter – I began to fret about how much more remained. This led to even more exhaustion and even some concern over sustaining the schedule agreed upon with my publisher (O’Reilly Media – they’ve been absolutely great to work with, btw).
So, I began to celebrate quick wins and successes, which was re-energizing, but also served to incur some level of complacency: “Oh, I’ve got this. I’ll get it done – look at all these wins!” Eventually, I found a balance, and that’s what enabled me to push through to finish the initial complete draft.
The obvious lesson here: Don’t lose sight of the prize through complacency, but keep pressing onward even after a quick win. Just because you can see the light at the end of the tunnel doesn’t mean you can stop.
Parting Thoughts
As an author, I hope you’ll read Programming the Internet of Things, even if you’re not planning on implementing any of the exercises. As a contributor to society, I hope it will be valuable and serve as a useful tool for you and your colleagues.
Thanks for reading. Cheers all –
Lab Bench Studios 