Writing a book: how to work on many projects
After quite a bit of pondering, writing and editing, I shipped the Learning as a Software Developer book last week. The whole process took about 6 months to complete, so I had time to experiment with a few ways to work. During that time, it was important for me to keep the blog going and still have time for technical learning and my various homestead-y hobbies. So, in that case, I was in for a marathon, not a sprint.
Spoiler: making a commitment to write regularly was the best way to make progress.
I’ve also tried a batching approach to the problem. The idea was to write a few blog posts in advance the first week, then spend the next week working on the book, and finally do a bit of technical learning. It was working decently at first and I WAS able to batch a few posts in advance, but then life happened and I was only able to write a little bit for the book before having to go back to blog posts. Fail!
Making sure I’d work a bit on everything each week was the best way to make sure I’d keep moving forward. It kept everything fresh in my mind, so I had less catching up to do to go back into the flow and start writing. To limit context switches, I’d pick ONE thing to work on every night instead of jumping from task to task.
I’m aware this makes me less effective than batching, and that it takes more time to complete some projects, but this way I don’t lose steam and burn out. Right now, I’m living in manager space and not in maker space: I don’t have time to focus intensely on a project for hours every day, so I have to sprinkle important projects here and there to make sure they get done. If I space out working on each project too much, I’ll wake up 6 months later without having published a new blog post or written a newsletter.
Relating to this, I also had to hone my ability to get to work immediately (or at least faster) since I’m working during the gaps in my day. I only have a block of a few uninterrupted hours in the weekend if I’m lucky, so I can’t lose 2 hours getting started every time.
The key here is to have a task primed and ready to go, or at least a well-defined process. For example, to write a blog post, I generally write a draft in one go, and then edit the next time, so I’m either starting a new blog post or completing one.
Finally, what helped me is that all those tasks are similar enough to fall into the same habit. I changed my blogging habit to a habit of writing and coding using the same cues and rewards, so I’ve not lost a habit that took some work to build. It took quite a while to ship everything this way, but in the end it was worthwhile and allowed me to ship the first version of the book to you.
Originally published on my blog at http://blog.cindypotvin.com/writing-a-book/
