Software Engineer MixRadio
MixRadio was a music streaming service that I joined shortly after its sale by Microsoft. This was a business with a short cash runway and a long to-do list, so my focus in this role was on speed & execution.
Automated Acceptance Tests
The standard process for any new feature in the MixRadio web team including adding automated acceptance tests. This was an expensive commitment in terms of engineering time. In particular, we were plagued by so-called "flaky" tests, where outcomes varied from one execution to the next. The level of buy-in for this methodology within the team was very high, so a compromise was needed to avoid losing too much time to this problem.
Extreme schedule pressure meant there wasn't time to stop and fix the underling race conditions making our tests flaky, so I created a nightly "flaky build" within which to quarantine the most troublesome tests. This allowed us to satisfy the team's desire for very high test coverage without sacrificing our everyday momentum to the reliability issues that came with having so many of these tests.
Deployment Automation & Chat Ops
The production deployment process at MixRadio had been automated into two Jenkins jobs: one to produce a build of the app, and another to deploy that build to production. So although the engineering cost of the automation had been paid in full, the everyday efficiency benefits had not yet been harvested, because engineers still had to wait for the first job to complete and then manually copypaste an ID over to invoke the second job. Having engineers sitting and waiting to manually complete the deployment process like this was not ideal given the schedule pressure of the cash runway.
Noticing how much time we wasted on this boring non-work, I created a Slack bot called "Leeroy Jenkins" whose purpose was to abstract away this process behind a Slack command. This enabled engineers to trigger production deploys in a single step. Moving the deploy process from Jenkins to Slack also had the unexpected benefit of improving transparency around deploys: it meant that every deploy was also a deploy announcement, thus avoiding issues such as accidental simultaneous deploys.
Playlists
Implementing the front end for playlist functionality is more complex than for albums. Users can create playlists with duplicate tracks, for example, and you need a data model precise enough to know which one to label as "Now Playing" in the track list. Users can drag the currently playing track to a new position in the playlist, and you need to meet their expectations about how this will affect playback.
These were the types of problems I was working on on the day of the insolvency announcement.
Digital Rights Management
Record labels don't let you run a music streaming service if you expose their catalogue to unauthorised copying by commonplace stream capture browser extensions. As part of our efforts to meet this business-critical compliance requirement, I audited the code for some of these tools.
In some cases this code had been deliberately obfuscated as a defense mechanism against people like me performing that kind of audit. Deciphering this code was a difficult process. I printed a lot of it out and went over it repeatedly with a red pen to trace the relationships between its parts.
