I’ve been slowly building a new version of this website, to replace wordpress (and its attendant problems and constant updates) with something a little lighter that I control more tightly (I’m not just rolling my own blog engine, but a platform for several other things I have planned). As I’ve done so, I’ve been rethinking a lot of my approaches to software development for personal projects (corporate projects are a different matter and under different constraints). Given the ever-accelerating rate at which frameworks change, especially client-side javascript frameworks, I’ve had to more carefully assess the risk of major breaking changes and attempt to mitigate those as I switch things over. I’m currently building a fairly lightweight blog editor that allows me to create new blogposts using markdown and publish the rendered HTML in the actual blog itself. None of it is rocket science, but there are a lot of little things to think through. Perhaps one of the biggest things I’ve noticed is how different frameworks deal with extensibility versus ease of initial setup. I’m going to use javascript frameworks as an example of the sort of design decisions I’m dealing with, because it often seems to be the worst offender for me, although it’s likely that much of the difficulty I have on occasion will go away once I’m a little closer to a decade of solid javascript usage (I really only started using javascript heavily in the early days of jquery, although I used it under duress all the way back). While I was originally a fan of larger, more comprehensive systems, such as AngularJS because they handled much of the internals of the front end of the application, I’ve since started to move away from such systems precisely because they attempt to handle the internals of so much of the front end all in one place.

I’ve been on a bit of kick lately, rethinking how I build applications, particularly with the aim of reducing complexity. One thing that has been readily apparent (even in the bad old days when we called it service oriented architecture) is how breaking a system into small, discrete pieces that do a single thing well makes it much easier to maintain and reason about code. This approach works really well for scaling, deployment, and for quickly being able to build out a piece of functionality without entangling it with other systems. The model works really well for the way I typically think about code in general these days. Breaking the system into smaller pieces also allows me to optimize my technology choices for the problem I’m trying to solve at a much more granular level, which often makes things simpler (in practice, I still typically stick with just c# code, but the ability to throw node, ruby, or python into the mix can be handy at times).

We live in a pretty amazing world. Right now, I have on my desk several devices with which I can communicate with people nearly anywhere on the globe. I use one of those devices every day for several hours at a time, both for communication with others and to create things. The money I earn doing that is automatically put into my checking account, and I can spend it on groceries with a little plastic card that I carry in my wallet. I can even order food online and have it delivered directly to my house, for a very modest charge, that is nearly always a better choice (price-wise, not nutrition-wise) than driving down the street to get the food (at least for pizza, grocery delivery isn’t quite here yet, but will be). I could, right now (well, if I had renewed my passport) be in India, Iceland, or Argentina within a day. In short, we live in truly amazing times and are capable of things our ancestors would have never dreamed of.