If there’s one thing I like writing about more than anything else, it’s compassion, empathy, and intuition. It’s a super squishy topic which means it’s vulnerable, emotional, empowering, and ultimately human. I wish I could talk about it more than I do but sometimes I think the depth of it can be a bit intimidating because it can encourage a way of thinking that might feel uncomfortable. Might show you something you weren’t previously aware of.

As they’re wont to do, a certain tweet was floating around the interwebs for a while the other week. Recruiters be like: We’re looking for someone who can connect to the database using CSS. It’s been a hell of a long time since I last embarked on a quality shitpost project1, in fact it’s been so long that back then I probably didn’t even have the word shitpost in my vocabulary.

I’ve been working fully remotely for almost 18 months now. It’s not a temporary measure, brought on by the Covid-19 pandemic, it’s because the place I work is fully remote. No offices anywhere (just like Elastic and Gitlab, last time I checked). It’s not my first rodeo either, thanks to previously enjoying a year of living and working by the Baltic coast in Jūrmala, Latvia. Even having worked remotely before, however, that experience in 2017 and my current experience from 2020 onwards could hardly be further apart.

I recently read a post called /No code reviews by default/, by a startup called Raycast1. In summary, code reviews are optional and the team deploys nightly internal releases so that the changes introduced can be tested (or used) by the team themselves, because they all run this nightly build locally. They’re eating their own dogfood. This works well in small, agile teams. It reminds me somewhat of Extreme Programming (XP)2 and also of the common practice of bypassing code review by pairing on a feature with a team mate.

There was one time where I thought that being a software developer meant that I just had to get good at writing code, because to my mind the main thing I was producing in my time at work was, well, code. This was back at an agency called New Bamboo, and it was my first job both in London, and as a programmer doing Ruby. I only had one year of professional experience writing PHP code–everything else was self-learning and freelancing as a favour–so this is going back to the dawn of my career.

About six months ago I wrote a post about rewriting the tech that publishes this blog.[^1] It seemed like a good idea at the time to try and build something out in Racket and Pollen, and it was a learning experience. In doing this, I inadvertently painted myself into a corner. While I could fairly easily hack away at the code while I was building the initial release, I essentially had to re-learn most of it when returning to it several months later.

I recently realised that despite many new additions to the Ruby language and ecosystem, I’ve never really had an opportunity to take advantage of many of them. Of course, some new language features are more useful than others, particularly when it comes to maintaining code as a team, but what is also interesting is that they also support less conventional, or immediately-apparent, use-cases. The first part of this series of posts is all about /Pattern Matching/.

I was browsing HN over my coffee this morning and came across an interesting thread[^1] linking to a post titled /When Buddhism Goes Bad}[^2]. That wasn’t actually the title I read, as on HN the more neutral subtitle – ◊em{How My Mindfulness Practice Led Me To Meltdown/ – was chosen instead. This is one of those posts I can relate to, at least in part, because of the experiences I’ve had myself.

I finally got around to paying some money for /Beautiful Racket/1, a fantastic online-only book that introduces you to Racket by guiding you through building a few language implementations. In that sense it’s not unlike /Write Yourself a Scheme in 48 Hours/2, except that book focusses on Haskell and (through no fault of its own) lacks the wonderful presentation of Beautiful Racket. Developing a soft spot for a lisp feels like a rite of passage for a typical programmer, alongside owning a copy of SICP and using emacs as your main editor.

Way back in 2002, or perhaps 2003, I’d acquired a copy of Macromedia Dreamweaver and started playing about with HTML. The timeline is a bit blurry, considering that it’s almost twenty years ago. CSS wasn’t really a thing yet, though, and IE6 was still the main browser of choice. Eventually CSS became a thing and one of my first real ‘projects’ was to create a user style that hid all the ads on the Gamesradar forum I used to spend time on.