It's also possible that I'm just used to producing more dry material. Seeing as you're interested in talking about interesting problems that you have encountere

It's also possible that I'm just used to producing more dry material. Seeing as you're interested in talking about interesting problems that you have encountered, do you think that 1 post per week is going to be too much? It seems to me that you'd have a bunch of material to start with, but it would be quickly exhausted. Looking at my own site I typically end up with about 2 posts a year, though if it was a higher priority I could see it being something like 6 posts/year (but certainly not 52). As per the concern about broader interest, you can either widen the technical discussion somewhat (the approach I chose) or stick with trying to lighten up the discussion and focusing on providing more context for readers. It seems like your chosen approach fits your goals quite well. Some of the other comments on this post seem to talk about optimizing the reach of your post, though IMO I think it's better to ask "How is someone going to find X and if they find X what do I want to convey to them". Knowing the goal of a particular piece helps frame it and it helps contextualize/flow ideas if you end up doing a series of posts on a single topic (which may very well happen if you're focusing on challenges in personal projects). For a point of comparison here's two of my posts on technical pet projects: http://log.fundamental-code.com/2017/02/14/profiling-mruby.html http://log.fundamental-code.com/2017/02/14/profiling-mruby.h... and http://log.fundamental-code.com/2017/09/02/total-variation-denoising.html http://log.fundamental-code.com/2017/09/02/total-variation-d...