Catching Up: Writing Again!

So I just finished up this blog post, Just What the Heck is Amortized Constant Time Anyway?, over the last couple weeks. And I felt odd once I finally posted it, because of the total lack of personal context as to where this post is coming from. After all, it's been over a year since my previous post. So I wanted to write a quick "catching up" post, which is mostly about the fact the I am writing again!

Personal circumstances had made it difficult to write for about a period of a year. I wasn't able to produce much - prose or code - outside of the job. It was pretty frustrating for me, because I had to more or less abandon my blog, as well as set aside a writing project I had been working on last year. My circumstances have changed a bit, and I have freed up a good deal of time to be writing again.

This Amortized Constant Time post does seem a little out of the blue. About a year ago, I had been working on a book about the Scala collections library, and I felt that it was important to talk about amortized constant time and effective constant time, and the data structures that display these behaviors. But I didn't see it as material that directly belonged in the book. So I decided to make them appendices of sorts, and just put them out on the blog.

I've been thinking a lot about readability, and making my writing more accessible to a wider audience. Some of the blog posts I have written in the past have been pretty challenging, and I imagine that is a turn off for many potential readers. This struck home particularly strongly with my 2013 Scala Days talk, where the impression I got was that, while many people enjoyed it a lot, it was generally a flop. I presented way too much material, of way too technical a nature. The next time I give a talk like this, I'm going to put much more care into respecting my audience, and sharing material that is actually useful to them. I've specifically tried to address these kinds of concerns in the Amortized Constant Time post, which, while challenging, should be much more accessible to a wider audience. But I still have two problems with it. Most importantly, it is just too long. I've learned through Google Analytics that the average visit to my site is a bit over a minute. This is not nearly enough time to digest one of the blog posts that I typically write! I didn't really find any way to break this previous blog post into smaller chunks, but I will actively be looking at making shorter posts in the future.

The second major flaw with the Amortized Constant Time post, as I see it, is that it is not directly applicable to an engineer. I think that when engineers read blogs or other material, they most often are looking for recipes, or code snippets that they can copy and modify and use directly in what they are working on. Understanding performance characteristics of a collection implementation does not really fit into this model. But there are other things I want to write, or have already started writing, that could benefit from this perspective. I can focus on recipes and how-to guides, and leave some of the theory and edge case analysis to the side.

So what am I planning on writing on? The cake pattern, for one. A couple weeks back I went to a talk by Adam Warski on Scala dependency injection, and his constructor-injection based framework MacWire. It was a great talk, and really got me thinking. A few nights later, I was ruminating on the cake pattern, and I had an idea of a cake pattern variation that would make the pattern easier to understand and maintain. I plan on writing about this idea, as well as using it on a software project I started working on. I've also thought a good deal about the cake pattern posts I've written in the past. I think that while they are very thorough, and cover lots of bases, including what I believe are some novel applications, the material as presented is hard to digest. It's written up in a rather academic fashion, as well as being spread throughout a handful of blog posts. So I was thinking of writing a short "cake pattern handbook", which would read much more like a recipe guide, for practical application of the pattern in real projects. One bit of feedback that I've heard more than once is that my example code, (TService, TRepository, UService, URepository, etc.), is a too abstract to grasp, and that it would be helpful to use a more life-like example. So I plan to do that as well.

I've also started writing code again too! I started up a little pet project that is in very early stages at the moment. It's fun to be able to choose technologies! In my last job, I have doing Java/Spring/Hibernate, which is somewhat rewarding, simply because I have such a strong skill set in that area and can be very productive. But I've been really itching to move into a different technology stack. Mostly I want to get back to Scala, but I also want to try out NoSQL databases, and it looks like I will be using MongoDB on this next project. I imagine this new project will give me lots of stuff to write about, and I'm sure I will do that when the time comes.

Other things I'd like to write about? I have a couple ideas for posts on agile development that I'd like to get to. I'd like to pick up what I was writing a year ago on the Scala collections. And I also have a lot of ideas about domain driven design - particularly how it relates to technologies like Hibernate and relational databases - that I wanted to write up. I love to write, but I don't want to write just for myself. So please, give me your feedback, and let me know what you'd like to see the most!