Music Monday: The Tibbs – Takin’ Over

A lot of my recent favourite tracks come from Spotify’s “Discover Weekly” playlist, or one of a few other Spotify playlists that I keep an eye on and plough through whenever I’m in the mood for something new. This is how I discovered The Tibbs; the entry point being the track “Lies”, which I’d strongly recommend checking out.

Such is the nature of Spotify, I added the track to one of my own playlists, listening to it whenever it came up. With hundreds of tracks across a handful of lists, I don’t always check out an artist’s other tracks. However, on this occasion, I found myself listening to “Lies” so many times, I felt I had to venture further into the Spotify rabbit hole. I soon came across the album “Takin’ Over”.

It’s fresh, with mostly upbeat, funky tracks that are a joy to listen to. Current favourites include “Dog Days”, “96 Tears”, “Washed My Hands”, and “Cussin’, Cryin’ & Carryin’ On”, to name a few.

The whole album is sublime, and well worth listening through in its entirety (all 39 minutes of it).

As it turns out, I’m an idiot, because I could’ve discovered some of the band’s catalogue a couple of years sooner. I previously bought “Footprints in the Sand” following a recommendation from Juno Download – probably the “Recommends” section of the Funk genre. That’s worth a listen too, so I’ll leave you with that track too.


Use Makefiles to quickly run common commands

A tip I picked up from work is the use of a Makefile to set up short aliases for commands you run often, but that are a pain to type, or you can’t remember. I find this particularly useful as I code fairly intermittently these days, so it’s easy to forget the exact syntax of certain commands.

A good example is how to run unit tests. This varies from project to project, but is something you’ll probably want to do fairly often.

To start, create a blank file called “Makefile” and put it at the root of your project. Then insert the following code:



Change /bin/bash to the location of Bash, and modify the ./vendor/bin/phpunit line to do whatever you’d normally type in to run your unit tests.

You’ll need to replace [TAB] with a Tab character. Spaces won’t work. Make is strict in this regard.

Save and exit the file. Now open a Terminal, go to the root of your project, and type:

$ make unit-test

All being well, this will run your unit tests.

In the Makefile, “unit-test:” indicates the label you’ll need to run after “make” to run the command. You can add multiple lines and multiple labels – for instance:

[TAB]echo 'A'
[TAB]echo 'B'

[TAB]echo 'C'
[TAB]echo 'D'

If you have lots of commands, this method can get a bit messy. It’s handy for small projects where you only have a few things to include but can’t always remember them.

FAWM 2018: a good excuse to write new music

Last year, I wrote 16 tracks as part of FAWM, an annual songwriting challenge where the goal is to write 14 tracks in 28 days.

This year, I’m a couple of days late posting my first tracks (compared to last year, anyway), but I’ve made a start. Here’s my FAWM profile with links to the new tracks.

I was really pleased with the tracks I wrote last year, which I used for a new album – “Ten“. That album is exactly as it was once FAWM 2017 ended. I didn’t add or remove any tracks, reorder the sequence, or edit any of the music.

When I got started this year, I was a bit rusty. It took a few tries to come up with the first track (Synthrock), which I wasn’t completely happy with – but with a time-based challenge, there isn’t a lot of time to procrastinate. So I thought it best to finish the first track, and get on with the show. I’m happier with the second track (Psionetrics) and this should help keep my motivation up.

I find that FAWM is a great way to write new music – I only wish I hadn’t had ten years away (between 2007-2017).

On becoming a Scrum Master

I got my first job in tech back in December 1998. In my career so far, I’ve worked in pure coding roles, I’ve worked as a tester, and I’ve had a couple of more varied roles.

A few years back, I was working long hours for an extended period of time, and I completely burned out. While I continued coding so as not to lose the skill, it quickly became something I no longer enjoyed doing.

This year, I came to realise that my coding days are coming to an end. I’ve fought it for some time, but I’ve recently come to accept it. I’ve also had the opportunity to move into a Scrum Master role at my current workplace, which has helped a lot.

My new role has made me realise that while I may have enjoyed coding in the past, the thing I enjoy most – and that I’m good at – is delivery, aka getting shit done.

Being a Scrum Master, a Delivery Manager, an Agile PM or whatever I might call myself today or in the future, isn’t my only skill – but it is what I’m particularly good at.

I don’t know if I’ll be blogging about delivery a lot, a little, or at all. I don’t blog particularly often these days. But that’s mostly due to a lack of focus on my part. I like to do a lot of different things. As a result, I can’t focus on being the best at anything.

I’m far from the best coder. But I was always good at getting shit done. When I look at my past jobs, I don’t want to shout about what tech I used, how I solved complex problems, or how I designed my solutions. I’m far more interested in what I delivered – and the fact I got the job done – than how I did it.

I’ve worked with some amazing developers in my career. Many of those developers are great at getting things done. Some consider technology options at length, and maybe are hesitant to make a decision in case it’s the wrong one. Some may obsess over doing things perfectly. There’s definitely a place for planning rather than jumping straight in and making a mess of things. However, it can be taken too far.

Anyway, delivery is what I do. It’s what makes me tick. It’s the area I can help with the most.

And I’m glad to have finally figured this out. It only took me 19 years.

Music updates, 24th Sept 2017: New playlist, All tracks page

I’ve been tidying up my personal site, updating the layout to work better on mobile devices, and adding a bit of new content.

Earlier in the year, I did a big update to the site to move away from static pages and put some of the content into a MySQL database. I didn’t blog about it at the time, as the visible changes to my site were virtually non-existent. However, those changes made it easier to work on the updates I’ve been working on today.

New playlist – Best of Symmetry

In March 2016, I released a pair of albums – Symmetry 1 and Symmetry 2. Although I was happy with how these turned out, there are quite a few tracks I skip when listening to the albums now.

To solve this, I’ve selected 10 of my favourite tracks from the 22 on these albums, and created a new playlist: Best of Symmetry.

All tracks page

If you’ve ever wanted to see a complete list of all my tracks, well, look no further! I’ve added a new All tracks page that lists my tracks in alphabetical order.

I may improve this further by listing the album that each track appears on. For now it just shows the year of release. There’s quite a difference between the tracks I released from 2005-2009 and the tracks from 2016 onwards, so it might be a bit jarring to listen to the tracks in the order shown.

There are 172 tracks listed – I hadn’t realised there were so many. The list does include remixes, which will increase the overall total. I may do more in the future to highlight remixes or list them separately.

Future change: New tracks?

One other thing I’d like to is include new tracks that do not yet have an album.

In the past I’ve always followed the process of releasing tracks on albums, mainly because I don’t have a logical place to list the tracks that aren’t on an album. But that could be easily addressed with either a “New tracks” page or a “Non-album tracks” page.

There aren’t a lot of these tracks right now, other than “Top Brass“, which is on my Soundcloud page. I do have a few tracks in progress, and would prefer to share them as I complete them, instead of holding them back for an album.

For now, I need to get some of my current “in progress” tracks finished so I can share them. In the meantime, I might add one or two more playlists.

Always be shipping

Building software is fun.

It’s great to develop something from nothing, or extend something to do more than it did before.

I think coders want to build things the best way they can. But in practice, that doesn’t always happen. Shortcuts can be taken, perhaps due to time pressures, or major requirements popping up late into a piece of work. Sometimes, you need to make changes to software that are quite different to what it was built for to begin with.

But software changes, and we can’t always anticipate how it’s going to change. In fact, we probably shouldn’t worry too much about how it might change in ways we simply don’t know about yet. (It’s a bit different if it’s your product, such as a hobby project, and you know some of what you’ll be adding later – and can build for those things accordingly.)

Perfect code

We shouldn’t be aiming for perfect code. Equally, we shouldn’t be happy with crappy code, but that’s not the point here.

Delivery – shipping a product or feature – is vital. It doesn’t matter how beautiful your code is if you never ship.

It definitely matters if you build a mess of a system that will be painful to work with in the future. But we shouldn’t be agonising over making everything perfect before anything is shipped.

I know there are developers who will find some of my code from years ago and say “what was he thinking?!” And to be honest, if I read it today I’d probably think something similar. I’m sure I could think of ways to improve the code I worked on back then that I didn’t think of at the time.

But the important thing is that the code shipped, we could monitor how things went in production, and we could get stuck into other projects.

Continuous improvement

Continuous improvement is a wonderful thing. Some of my favourite projects have been framework migrations. I’ve migrated from a proprietary framework to Zend v1; I’ve migrated from a basic home-grown set of PHP classes to an MVC framework; I’ve managed a migration from Drupal to Laravel. More recently, I’ve worked with a team who have been migrating from a FuelPHP monolith to a service-oriented architecture.

With large-scale migrations or any major refactoring, breaking off components of the application and migrating them piece by piece is an excellent way to minimise risk, keep momentum going, and avoid a seemingly infinite end date. The concept of “dropping” a massive new upgrade on a given date for an entire customer base is extremely risky, and runs the risk of being rolled back if it all goes pear-shaped.


There’s a phrase I have in my head at all times as a reminder of why “big bang” launches are so dangerous:

It is difficult to know when testing is complete.

Testing is not something you start and finish. Testing is an ongoing process, a discipline, that can incorporate a selection of the following at various times:

  • Automated unit tests
  • Automated integration tests
  • Manual exploratory tests
  • Manual functional tests
  • Manual or automated regression tests
  • Manual UI tests
  • Non-functional tests (a large category)

Testing helps to highlight everything from catastrophic failures to tiny UX quirks. But having tests doesn’t mean your big bang implementation will be fine – especially in a big, complex system.


In Scrum, the output of a sprint is a potentially shippable product increment. Whether you ship or not is up to you. But the point is that you can ship if you want to. This capability should be available to the Product Owner.

When a development team thinks they have 6-12 months, or years, to deliver a project (or maybe there’s no end date at all), it’s can be very tricky to keep the team focused. Agile accepts that requirements change frequently. This in itself is not an instant issue. However, when you have a long-running project that isn’t shipping anything, and constantly changing requirements, especially when development is already in progress – that’s a recipe for disaster.

Always be shipping

There’s a lot of different things I’ve discussed in this post, but it boils down to one simple thing. Always be shipping.

Stop adding a day here and there to perfect something that already works fine (and has unit tests that pass).

Start getting stuff out the door.