Interlude and Schedule-change

So, most of the reason I started this blog was because I wanted to start writing about writing code again. As motivations go, I think that's pretty straightforward. Within a few days of my starting the current efforts, though, I was notified that my position was going to be closed at the end of Q1, 2017. The resulting job-hunt processes took up a fair chunk of my time, but after the first few weeks, it became a pretty standard routine — something I could complete the daily task-set on, most days, before I even left for work.

I also picked up a freelance project with a friend and former co-worker, with an eye towards getting some income-buffer started if my job ended before I found a new one. As might be expected, that also ate into my available writing-time, though not very much or for very long.

While I had five years worth of development efforts to hand off to others before I left, the rigorous application of some of the practices I've written about here so far made most of those quick and relatively painless:

• I'd built an earlier version of the documentation decorators, so most of the codebase had pretty thorough and very consistent documentation. Honestly, there's more stuff that I'd built out there than I've had the need or time to build equivalents for here (so far), but those will percolate up here too, eventually.
• Everything I'd written that was actually in use anywhere also had a fully-developed build-process in place, so as changes are made, there's a simple, consistent way to build and deploy them.
• That build-process also leveraged a unit-testing structure that, while probably not as thorough as the one I've created here, was still very thorough, and was attached to the live build-processes so that a build targeted for a production deployment couldn't be completed without all tests passing.
• All of my efforts there either started with a uniform project-structure or, in the couple of cases where I hadn't thought through that structure until after the project was underway, or even deployed, had been re-organized into one.

With all of these in play, the hand-offs for all my work there actually became amazingly simple, from my perspective, at least. Spending some time walking through those common structures first allowed me to point the recipients at the documentation, the project-structure, etc., etc., for all of the simple questions. That kept a lot of my time free.

Enough so that I was able to write almost every post that's shown up here so far before the beginning of March, 2017.

I managed, in fact, to write and schedule publication of every post here through the one before last before I found and started another job.

Now, however, I'm actually at that new job, and have been for a couple of months. Between that and the occasional vagaries of the side-project noted, my writing-time has been pretty scarce, and very scattered. It took the better part of ten weeks for me to complete the previous post — mostly because I'd set it aside to work on something else, pick it up with an idea for a new and better approach to some task or challenge within it, then do the same thing over and over again.

This isn't the first time I've been in this sort of situation. Unlike the last time, though, I'm pretty darn certain that I won't have to worry about writing code for this blog that has conflicts of interest with what I'm doing at work. On the other hand, the new job is very different from the previous one, and makes more (and unpredictable) demands on my time that have interfered with my writing-efforts in the last couple of months. The side-project is also gaining traction again, after a month or more of near-total inactivity.

Putting all of these together, I'm not completely sure what that means for my writing- and publication-schedule here yet, at least on a long-term basis, but I am planning continue my efforts here, as much as I can manage — I've still got a fair chunk of stuff thought out that I can write about, it's just a matter of finding the time to do so.