Change or Die.

A tad dramatic, perhaps. However, I feel this anecdote is important to hold onto throughout all stages of your career, especially in the tech industry.

Embracing change and accepting that you are playing an endless game of “catch up” is one of the hardest things for humans to do, yet one of the most important for developing oneself professionally and staying competitive.

A few months ago, I parted ways with a company I loved due to irreconcilable cultural differences. This left me questioning my career path, wondering “what do I want to do?” and “what am I actually good at anyway?”.

Career paths are hard.

It’s been a bit of a journey since then, but I think I’ve actually learned and grown more professionally in the last few months than I had in a couple of years.

You see, my career path hasn’t exactly been “textbook”, for any of the typical roles in tech. I started out as an internet-connected child who had learned the basics of HTML, accidentally became a freelance PHP developer, then spent the next 5 of my teen years contributing to the abyss of terrible procedural PHP 4 code on the internet instead of going to school. – where I spent much of my teen years.

Before I was even aware of the existence of programming best practices, I had accumulated years of experience of writing “functional” code (literally, not in the Haskell sense – real functional programming still terrifies me). Don’t get me wrong, at the time I was proud of my code, and put effort into solving things in elegant ways to satisfy customer requirements.

I’d just never been exposed to OOP, version control, or testing.

Fast forward a few years and I’d attended university, achieved a Master’s degree to be proud of, and worked at a small SaaS company for a few years. Yet, while I’d certainly learned and embraced OOP and version control, and had written tens of thousands of lines of code, adding significant value to the company – I’d still managed to completely avoid learning to write tests.

In my defence, the whole company didn’t do unit testing!

I’m a fairly ambitious person, and by this point, my career had ended up moving from “individual contributor” into the “management” track. As such, while I was still very much involved in technical decisions, I spent most of my time in meetings or dealing with customers, staff and organisational issues, so wasn’t actually writing much code myself any more. In fact, in order to be effective at my role, I actually had to reinforce mental processes to restrain myself from getting too involved in coding.

To be honest, even if I had been still writing code regularly, I’d have found it very hard to develop myself. The codebase at the company I was working for was a large, legacy PHP monolith with hundreds of thousands of lines of code and 0 tests, and unfortunately, that had become my comfort zone!

Towards the end of my tenure with the SaaS company, we matured as a tech team, built a CI pipeline and started introducing unit testing to the team as part of a push to improve quality, driven partly by myself. Yet, while I had strong opinions about the automated testing pyramid and was vigorously preaching the right way to do things, I was secretly very much aware of my own inexperience of the basic building block – unit testing.

The “right way” to do automated testing

Skipping over a year of senior leadership roles, for the last couple of months I’ve found myself writing code again – and not a line of PHP! I know I’m way behind the curve here, but I’ve finally learned how to write decent Python, including publishing my first library on PyPI, complete with tests, documentation and CI/CD handled by Travis, following best practices for open source projects in the Python ecosystem.

Even better, today I’ve finally started to understand how to think the right way for TDD. Massive thanks to @martabeveridge here, for 20 minutes of TDD pillow talk last night which helped a few key concepts slot into place. I’ve now written followed the test-code-refactor cycle many times for my most recent project, and it’s starting to not only feel natural but actually motivate me to do the same for all future projects.

The TDD cycle – natural for some, hard to adjust to for others

At this point, I think my days of writing untestable spaghetti PHP code are over. I’m finally embracing TDD (albeit 10 years late), I’m excited about programming again, and I’m finally regaining the ability to be proud of the code I write.

I’ve still got a lot to learn (and always will), but I feel like I’m on the right track again.

Big thanks to:

  • Mar, for inspiring me to be better by going from Law graduate to highly competent software developer in less than a year.
  • TravelNest, for giving Mar a supportive environment to thrive in and great engineers to learn from!
  • CodeClan, for teaching Mar best practices right from the start. While coding bootcamp graduates aren’t always very well prepared for the many legacy codebases of the real world, when they end up somewhere without a legacy codebase and with other excellent engineers, the habits and expectations they form right from the start are wonderful. Thanks to CodeClan, Mar has entered the industry without forming any bad habits, and I’m genuinely jealous!
  • Steve, for being the first software engineer I looked up to, for getting me excited about unit tests and mocking even years before I had a clue, and for retaining his passion for writing great software despite organisational distractions.
  • Tamás, for being a pleasure to work with and resetting the unhealthy stereotype I had that developers with a history of legacy PHP were doomed to that fate forever! I aspire to be as technically competent as him one day.
  • Leif, for answering my really silly questions and helping me get my head around some basic concepts.
  • The open source community around Home Assistant, for holding a high bar for code quality, providing thorough code reviews on pull requests, and for getting me interested enough to learn a whole new language and ecosystem!


Vim block-visual mode

Vim 2.0 was released in 1993, barely a year after I was born.

The fact that it’s taken me that long to discover block-visual mode pains me greatly.

I spent years telling myself I’d learn to use Vim properly one day, occasionally starting to read a relevant book but getting bored a few pages in.
The thing which finally kick-started my progress was these keycap stickers:

I found them on eBay a few months ago and I’m so glad I did.
They remind me of what I need to know when I come to need it, and broke the barrier of feeling overwhelmed whenever I attempted to learn in a more structured way.

Anyway, today I started using block-visual mode in earnest and it made me very happy.
Out of the box it’s not quite as flexible as PHPStorm’s multiple carets, but it’s still saving me lots of time.

If you use Vim regularly but you’re wondering what I’m on about, you’re missing out:


jQuery UI overflowing droppables

If you’re working on a site using jQuery UI, the Draggable, Droppable, and Sortable built in functionality can save a lot of time making a web application interface dynamic. As such they’ve become a mainstay for millions of websites.
However I recently came across a frustrating issue with the scope of droppable drop targets which caused (in my opinion) unexpected behaviour. In short, droppable elements which were hidden by a parent container boundaries with overflow: auto or overflow: hidden were still triggering the droppable functionality regardless of whether the drop target was visible or not. Not only does this cause unexpected behaviour when dealing with a fairly basic list of droppables, it causes even more confusion if you place multiple lists of droppables together as the drop event will then be fired on multiple elements (after bug fix #6009, anyway).

Here is a simple demonstration of the problem – try moving the draggable element around the list of droppables and see the problem.

After lots of searching and trial and error, I came up with the solution of checking whether the mouse event was within the boundary of the parent element on every drag start, end or drop event. This does mean handling the hover classes yourself, but that gives you more granular control anyway!

Feel free to use this code, or comment with a better technique!


Collaborative Music Tastes

For the past year, most of my working life has been spent listening to music using a service – now discontinued – called Soundrop.


Soundrop was an app in the Spotify app ecosystem which offered music genre-based listening rooms with group chat and democratic track queueing; whichever track in the playlist had the most votes got moved to the top of the queue to play next.

This method of listening to music is by far my favourite, as it has brought me to new music of all sorts of genres which I wouldn’t have listened to without a recommendation from someone else passionate about music. Just the simple fact that every track played has been added and voted for by at least one person means that every track I listen to has a vote of confidence from someone who shares my music taste enough to be in the same room as me. If you’ve never tried social music listening like this, I thoroughly recommend it.

However, at the start of 2015 Spotify sadly moved away from their embedded app ecosystem, which disappointed many users of a variety of apps and caused most of the communities built in Soundrop to disintegrate. Some of the more tight-knit groups of listeners decided they didn’t want to lose the service they had loved and community they had built up over several years, so a couple of community projects were launched to form a replacement service.


The most serious Soundrop replacement, and the one which I have contributed a little bit of effort towards and hope to contribute more towards in the future, is called Soundbounce, and you can download it for Windows and Mac OS X today at

All the code is hosted on the lead contributor Paul’s GitHub:

If you like the idea and want to contribute, please feel free to check out the issue list and send a pull request!


Musical Statistics

I knew there was a reason I loved This is it: statistics drawn from years worth of data, rendered as beautiful, easy to interpret, crisp vector graphics. (click to enlarge)

listening-trends tube-tags gender-plot


Career Puzzles

I recently attended a careers fair at Heriot-Watt university, and was pleased to find that amongst all the usual junk produced en masse and handed out to students who don’t really care in the hope of grabbing their attention (pens, keyrings, bottle openers, leaflets, free sweets, money…), I found something which actually caught my interest – a simple wooden puzzle, where you have to assemble 7 tetris-like blocks to make a small cube.

The company handing these little branded puzzles out was Skyscanner, a rapidly expanding, now multinational tech company based in Edinburgh.

Little details like this are the kind of thing which make me want to apply to one company over another for a job; if there are innovative minds in there coming up with things like this and being allowed to run with them, chances are the company ethos is going to be open-minded enough to fit in with my way of working.

Anyway, I had the urge to take the puzzle a step further, and asked the woman running the booth if I could have 27 of these freebies to make a larger cube, and make a stop-motion video of the creation process. This was my entertainment for the whole afternoon!



New Site, New Services

I’m writing this at 5am, having had a bout of inspiration and redeveloped this website, having put it on the backburner for a year… or two.

While it may not look like much, behind the simple website I have refreshed the core of how I market myself and my services; I am now aiming to develop a brand which represents me as a web project manager, development consultant and freelance wordpress developer, rather than just another php coder.

Over the coming days I’m also going to launch my hosting platform properly and publicly – previously my hosting services had only been open to web development clients, but I now have a proper management and payment processing system in place so I can start taking on normal hosting customers too.

Anyway, since this blog has just begun and is looking a little bare, let’s start it off with a completely unrelated photo, a deceiving panorama from atop the Arc de Triomphe in Paris, taken by myself last month while travelling.

I think I might make a habit of this; technical posts with uninteresting text but a bright and colourful (unrelated) photograph!


Panorama taken from atop the Arc de Triomphe, Paris

Panorama taken from atop the Arc de Triomphe, Paris