So this blog is coming up on four years - in that time it’s moved from a Wordpress install hosted on Laughing Squid to a static Jekyll site hosted on a Rackspace Cloud Server to a Docker container that’s now living on Digital Ocean. A lot has changed from my introductory writings about functional programming and investigations into Clojure, OCaml, and Haskell - I’ve moved from being an academic with a lot of experience with Java the language to a polyglot industry professional with a good understanding of the various moving parts involved in a basic web deployment. I’ve gone from thinking deeply about the languages that I use (I need static typing! everyone needs static typing! let’s build better static types!) to focusing more on the customer experience, and understanding how important a language’s ecosystem is to really get your job done. In the process JavaScript became my core language (out of necessity) and I’ve bounced up and down the stack. I’ve learned how to build frontend widgets with rich behaviors, dig deeply to improve error rates/page loads, and lead teams.

Throughout this I’ve managed to keep a pretty steady cadence of writing and publishing something new nearly every month (minus some dead time in 2012 when I was swamped by stress both at work and on a side project). I’m not sure exactly what my real plans were when starting the blog - I think it was mostly a branding thing. In retrospect I realize that I started this blog just as the multi-year haze of graduate school depression was clearing - weird as it seems, part of me missed writing.

I try to aim towards aspirational pieces - these are the people and professionals and teams that we should aim to be, and these are the behaviors that will get us here - with a smattering of deeper investigations of technical issues that I’ve found interesting. However, the content is primarily for myself - writing something lets me work through a number of issues and end up in a place where I can explain it to someone else. My time in academics internalized all the millions of criticisms that can be brought to bear against every sentence and phrase and by the time I’ve published something I feel like it’s a pretty good and cogent argument, if not remarkably clear or profoud - expository writing is really hard and I feel like I’d have to spend about three times the time I already spend doing it “right”.

Often in the process of writing I’ve changed my mind about the topic I’m writing on - my extremely long post on why REST was important for infrastructure APIs started as post about how it was silly for infastructure APIs to use REST. I later learned that to read any sense of cohesive design into OpenStack Nova’s “REST” implementation was a mistake.

I disagree with some of my past posts - or at least, have a “yes, but” attitude now. My post about the agile value of Courage is definitely something that I think is still true, but it’s a lot easier to be courageous when you’ve built an application on top of a low amount of legacy code and on top of the great safety net of comprehensive unit and functional tests. (We used to have legacy code but burned it to the ground in the process of launching the product.) The new job has a bit more legacy code and yes, I think I’m still pretty courageous (some would say ‘brazen’), but my pitch would be slightly different with a few more projects under my belt.

I wrote my post on deontology applied to software development after having this horrible realization that phrases out of the agile software development playbook such as “I prefer this code to that code because it has better object factoring” (or some other equivalent jargon - there’s a lot of it, and I’ve been guilty of it myself in the past) were meaningless - so what does ‘software goodness’ even mean? Writing along those similar lines today, I might try to reach even further - just as object factoring was a useless argument, maybe almost every argument that’s had over code is just as trivial. Engineering is a process, and the code just has to work … fighting over the internals of the machine may be just be sound and fury talking through vapid topics around a useless criteria but the conflict (and the process that mediates it) over code quality is ultimately what fuels the team more than any objective metric.

Writing as a Process

Over time I’ve gone from thinking about the blog as a thing associated with my name and more a process that I subject myself to - what’s important is producing some kind of content, “completing” it for some value of that, and then publishing it into the world and starting the next one. We all keep processes around in our life - I run at least 3 days a week - and ideally those processes are a positive influence on us. Writing has been a positive process in my life, despite the many hours it takes to produce what ends up here for admittedly low readership.

Like many computer science nerds, there’s a part of me that finds empathy really hard - if there’s a bad outcome, you did it wrong - you should have done it my way - what were you even thinking? (I referred to this on Twitter as computer science’s “awful id”.) These thinking patterns were reinforced through years of school and an academic training, where I got to indulge in the parts of my brain that preferred machines to people. They are always following me around and working their way through my thinking; a demon sitting on my shoulder. By forcing me into long-form thought and away from knee-jerk judgement, writing banishes the demon - at least for a little while.