Trust, and choosing your bottlenecks

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.

Getting to know your customers

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.

Rewrite it in lisp again

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.

Pattern Matching in Ruby

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/.

The goose is out

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.

Rewrite it in Lisp?

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.

Growing up

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.

Past mistakes

I think everyone needs at least one blog post under their belt that describes mistakes they’ve previously made in their careers. Now is the time for me. Liberal application of the word ‘just’ “Why don’t you /just/ do this other thing instead?” Uuughhh…this word, which serves as punctuation as much as the word ‘fuck’ does in Glasgow, is bound to rile anyone up after the umpteenth attempt at trivialising the problem they have.

Agile lipstick 💄

Over the past decade of my wondrous career I’ve rather haphazardly stumbled in and out of the realm of agile leadership. I’ve been a scrum master and an agile coach, even got the PSM1 certification which is nice but not really worth the PDF it’s written on these days. My best investment was in a coaching course1 where I learned experientially all of the things I didn’t learn as part of my job: active listening, rapport, acknowledgment and recognition, transactional anaylisis, I’m Ok/You’re Ok, etc.


I’m driven by ambition, as are many of us. I don’t think that you need to be ambitious to be successful, though, unless you reframe your perception of it. You can be enough; no more, no less. My ambition is fuelled by wanting to do more or wanting to do better, but on the flip-side it feels more like over-compensation. One particular habit I have, for example, is to work late on an off-day to try and feel like I’ve pulled my weight.