Book Review: Life of a Song

I recently had the chance to read Life of a Song: The fascinating stories behind 50 of the worlds best-loved songs. It’s a concise collection of fifty Life of a Song articles from the Financial Times. As I rarely have a reason to visit the FT website, and I only occasionally catch the Life of a Song podcast, the book was a great opportunity to catch up on what I’d missed. Regular readers may find nothing new in the book, but for pop fans and die-hard listeners, the short collection is definitely worth a read.

Life of a Song: The fascinating stories behind 50 of the worlds best-loved songs

The book consists of fifty articles from the regular Life of a Song column collected into book form. Each article takes on a different, well-loved tune from twentieth century popular music. Songs covered include ‘My Way’, ‘Midnight Train to Georgia’, ‘1999’, ‘La Vie en Rose’, and ‘This Land is Your Land’. There are only a few songs in the list that I didn’t know off the top of my head, including ‘Song to the Siren’, and ‘Rocket 88’. The articles usually include some remarks about the songwriter, often quoting them about their creation. Then they cover the journey from composition to hit recording, and usually mention other interpretations that followed the hit.

Each article appears to be less than 1000 words. As you might expect, that’s a lot to cover in that much room. So each article is pretty topical, relating a single anecdote about it, and only touching on the rest. For instance, in the article about ‘Like a Rolling Stone’, the author relates the recording process that shaped the final sound.

On take four of the remake, serendipity strikes. Session guitarist Al Kooper, 21, a friend of the band, walks in holding his guitar, hoping to join in. He is deemed surplus to requirements, but Dylan decides he wants an organ in addition to piano, and Kooper volunteers to fill in. He improvises his part, as he would later recall, ‘like a little kid fumbling in the dark for a light switch’. And suddenly the song turns into the tumbling, cascading version that will become the finished article.

There’s two pieces of information that you need to know about this book in order to enjoy it.

  1. It is a collection of short articles by many contributors.
  2. Those writers are almost entirely arts journalists, rather than trained musicians.

This book was written by a lot of authors. I counted fourteen contributors, each of whom appears to be an English journalist. This can lead to the book feeling somewhat disjointed. Each author is comfortable talking about their own domain of the music industry. Some interpret the lyrics, others relate interviews with creators, others pick up on business maneuvers behind the scenes.

In the introduction, David Chael and Jan Dalley write that the book “is not about singers, or stars, or chart success – although of course they come into the story. It is about the music itself”. If you are a musician, this may leave you expecting musical analysis, lyrical breakdowns, or at least comparisons to similar songs. The book “is about music” in as much as it tells stories about musicians, but it is strictly an outsiders perspective. There’s no illusion that the writers were part of the culture of the song, or involved themselves with the people in the story. A reader shouldn’t expect that in a collection such as this.

My favorite article is the one about ‘Midnight Train to Georgia’. That song has so much soul, that it surprised me to learn that the original title, given to the tune by its white songwriter, was ‘Midnight Plane to Houston’.

The soul singer Cissy Houston… decided to record its first cover version… But the title irked. It wasn’t the collision of Houstons – singer and subject – that bothered her, but one of authenticity. If she was going to sing this song, she had to feel it. And, she later said, ‘My people are originally from Georgia and they didn’t take planes to Houston or anywhere else. They took trains.’

Ultimately, Life of a Song is a great book to read on the way to and from work, or to sit in your book bin next to your favorite chair. It’s a book that can be read in lots of small chunks, and each chunk reveals a little bit more about a song than the recording.

Now if you don’t mind, I need to catch a plane to Houston.

22. January 2018 by evan
Categories: Book Review, Criticism, Publications | Tags: , , , , , , | Leave a comment

Other Music of 2017

On I did my year-end roundup of the best EDM of 2017. Like any of these lists, it’s a very opinionated list. In this post I want to mention a few other albums I really liked that didn’t make the cut.

There are a few albums that I really enjoyed this year, but weren’t really striking in any way. They were enjoyable to listen to, but they didn’t stand out. Biggest amongst them is probably the new album from Odesza. It’s a fine album, but it nothing in it is unexpected. For me, one of the biggest surprises of the year was the amazing live show Odesza put on to support a relatively mediocre album. Another album that was good, but not great, was Float bySlow Magic. I really enjoyed listening to The Invincible EP by Big Wild, but in the end it just sounds kind of generic.

There are a few other albums that I discovered in 2017, and listened to a lot, but were actually released in previous years. I somehow missed Braincase by Electric Mantis when it was originally released. It’s a dope album of instrumental trap. Also great is the Kindred Spirits EP by Jai Wolf. I managed to see Jai Wolf twice in concert this year because he was coincidentally playing at events I wanted to see. His pure, old-fashioned turntable mastery absolutely dominated festivals crowded by much bigger names, and his EP is worth a few dozen listens.

Last up are the albums that BARELY missed the cut. There were hundreds of great albums released in 2017. Even focusing on EDM exclusively leaves more great albums than I could possibly list. I listened to Full Circle by Oliver probably twenty times. It’s great for getting psyched up for a hard job, or just for getting your hips moving. The new album from Giraffage is also great. It’s an album that really lives up to his previous releases. It feels mellow, sexy, and fun all at the same time. When I saw him live in San Jose, the show was filled with college kids, and that made me feel old. But I think it’s an album that has wide appeal to all listeners to EDM.

And that’s all the other albums from 2017 that I want to talk about.

Okay, obviously that’s not true. I loved so many more albums. LCD Soundsystem made a triumphant comeback. Bonobo released a very solid album earlier in the year. Bonnie and Clyde were the darlings of the internet for a week or two. I thought Sofi Tukker was over-hyped, but then they were terrific live. BVD Kult released a pretty paint-by-numbers pop/EDM track that I absolutely adored. Vitalic released a disappointing album. Jerry Folk released an album that I have very mixed feelings about. Some people from YouTube released some really good music. And someone named Andrew Applepie made a bunch of music that is actually really great in a quirky kind of way.

There was so much great music in 2017. Looking forward to 2018, there is a lot to be pessimistic about. Vladimir Putin seems intent on starting a war. Trump and the Republicans seem intent on destroying democracy in America. But still, it’s going to be a great year for music, and for human culture generally.

01. January 2018 by evan
Categories: Criticism, Music | Tags: , , , , , , , , | Leave a comment

DIY Music Branding

Branding, marketing, advertising … they’re necessary evils. Whenever I start a new project I take time to think out the image I want to project. I wish that music could just be music. I wish it could just be sound heard and not seen. But that’s naive. We live in a post-MTV world where music listeners connect their music with a lifestyle, an image, and a brand.

When I started a new beat-driven music project, I was thinking of making trancey electronica under the name of Fynix. So I created a sleek, futuristic logo based on similar designs on groups such as Odesza, and Armin van Buuren.

I’m pretty proud of it.

But after making more music, I have drifted away from trance into a more soul-influenced, keyboard-based style. So the old branding makes no sense.

So how can I connect my image with soul music and soul-inspired electronica? I started by looking at similar acts. I like this art from Faking It by Calvin Harris.

Faking It by Calvin Harris

I also like the branding for Charles Bradley. The image for Spotify Sessions is particularly nice.

Charles Bradley Spotify Sessions

I also want to connect with older soul artists like Sam Cooke and James Brown. Even though my music may not share many qualities with theirs, I want my imagery to put me in the same bucket.

Sam Cooke Wonderful World

After looking at a bunch of images of Sam Cooke, James Brown, Charles Bradley, and some electronica acts, I came up with a few guidelines.

  • Warm colors. James Brown and Sam Cooke use a lot of oranges, browns and reds on their album covers. Using the same color palette will help.
  • Cosmopolitan. Charles Bradley and other funk artists use a lot of images of the city. Maybe this is an artifact of the association with Detroit. Whatever the cause, I’d like to project a cosmopolitan image.
  • Natural Fabrics. Leather jackets are big in the Charles Bradley and James Brown branding. I don’t want a picture of myself in my branding, but if I could connect with something physical that would be good.
  • Sans Serif Fonts. Flat-colored text using basic fonts.

The funk and soul branding also prominently features portraits. Mostly artists looking at or near the camera, with strong lighting. Often the artist is wearing a suit, or a leather jacket. I might do something like this in the future, but I would need a photographer.

For now, I executed my branding guidelines pretty directly. I am from Pittsburgh, so I found a warm-colored picture of Pittsburgh on Wikimedia Commons. Then I wrote “FYNIX” in the middle using a Sans Serif font. Then I applied the newsprint effect to associate my brand with newspapers, which have a real-world physicality that unifies the ideas of the city and natural fabrics.

Here’s the result.

Fynix Branding

I like this because it is legible even when scaled very small, and it looks like the Calvin Harris branding, while subtly calling to mind soul acts of the past.

24. November 2017 by evan
Categories: Music | Tags: , , , , , , , , | Leave a comment

Sometimes It’s Okay to NOT Write Unit Tests

I recently lost about two-and-a-half days to unit/integration tests. At Mighty Networks, we are pretty proud of our test coverage, and we make writing tests part of the development process. Developers are required to write tests for every feature they implement, but in the past few days I’ve seen that this policy needs to be applied flexibly.

A few months ago we wrote a pretty expansive integration with the iTunes Store. Since we allow people to sell subscriptions through our app, we required a pretty complex integration. Apple’s developer APIs are notoriously crappy, so this required a full team effort. One developer wrote a series of tests for our Apple integration.

In theory, the tests are very thorough. But getting real data for testing is virtually impossible. So the developer faked up a json file, then wrote a preprocessor to generate fake data in a format that looked like Apple’s format. Then he wrote tests.

You may see where this is going already.

The tests he wrote essentially tested his preprocessor. Rather than testing the actual methods used in the integration with Apple, the tests looked at the values generated by the preprocessor. Essentially, by writing a clever object to fake Apple data, he removed the actual integration from the tests.

The tests looked correct. They seemed to show that our Apple code worked. But really they were mostly testing the test code itself.

So when I modified a related system, and added a few tests, I suddenly saw a massive cascade of failures all over the place. The failures were of different types too. Sometimes there was a null value, or an unexpected ID, or an error seemingly from Apple.

It took me a day to figure out that the Apple integration itself wasn’t failing, only the preprocessor wasn’t set up to actually work with the rest of the system. Then I took another day-and-a-half to pull out the worst part of the system and replace the non-tests.

I don’t blame the developer who wrote the tests. It’s a common mistake, and we all did it at least once.

In part I blame Rails, because it encourages black/white thinking about software development.

The developer followed the rule that he needs to write tests for every new feature. When he integrated with Apple, he diligently wrote his tests.

The problem arose when he realized that he couldn’t run production code to get real data. He didn’t know how to write a test for the algorithm, so he wrote code that generates Apple-like data, then tested that.

The developer failed to see that writing tests is a guideline, rather than a rule. In this case, it is very difficult to test every part of the integration. It’s acceptable to write tests of the core process, without testing specific return values and specific pieces of data. The tests gave the impression of working code, and full test coverage. But they hid a few problems with the integration by testing for specific values, rather than algorithmic correctness.

So what can we do?

Senior developers need to encourage junior developers to talk about problems that arise when following “the rules.” Senior developers need to encourage an environment where it’s okay to admit that portion of the code just can’t be tested. Or at least to see that a portion of the code can’t be tested in the same way as most of the code. Senior developers need to encourage critical thinking and analysis in situations where the strict interpretation of the rules may not lead to the best results for the development process.

24. November 2017 by evan
Categories: Software | Tags: , , , | Leave a comment

In which I complain about the lcd soundsystem show…

This feels like a blog post from 2004. I want to complain about some super popular thing as if anyone cares about my opinion. Whatever. I’m going to write it anyway.

I went to see LCD Soundsystem at The Bill Graham last night. The auditorium was packed with a concert audience that actually made me feel young for once. The show was generally excellent, at least in the music sense. It was a great performance. Maybe you could complain that some of the performances were virtually identical to London Sessions. Or maybe you could complain that they only played five tracks off the new album. But that’s picking nits. They ended with All My Friends, so I really can’t complain too much about the music.

LCD Soundsystem at The Bill Graham

And here’s the part where I get up on my soapbox about some nonsense.


Point the fucking lights at the band. No. NO!. Stop your shit. Nobody cares about your art, we just want to see the fucking band. Seriously.

The band was back-lit for 2/3rds of the show. Bright spots were pouring over James Murphy’s shoulders into the audience’s eyes. He looked fabulous in silhouette. At least I think he looked fabulous. It was tough to see him at all. Since the lights were pointed at the fucking audience.


I can’t believe I bought this shirt.

Terrible LCD Soundsystem Shirt

All you had to do was show the picture of James Murphy, and underneath it, write “LCD Soundsystem”. Instead you gave us this monstrosity.

“So Evan, why didn’t you buy the other shirt?”

I did buy it, and it’s a fucking tie-dye.

Terrible Tie Dye LCD Soundsystem T-Shirt

Seriously? SERIOUSLY?!?!? Has anyone who cares about clothing ever actually worn a tie-dyed t-shirt?

Anyway, I know those are pretty minor points. But I was really excited to finally see one of my favorite bands, and these two little things really grated on me.

PS. Yes, there were even more tragic shirt options. In plain white.

16. November 2017 by evan
Categories: Concert | Tags: , , , , | Leave a comment

Learning to Talk About Inaccuracy for a New Data Engineer

About a month ago, the engineering team at Mighty Networks was impacted by China’s now-defunct one child policy. A parent of our data engineer was having health problems. Because there were no other children to help out, he was forced to relocate his family back to China.

It took us around six months to hire him. With a bunch of data projects now in the pipeline, we couldnt’t go through the hiring process again. Fortunately, I was excited to step into the breach. I’ve never formally trained as a data engineer, but I built a data warehouse from scratch for another startup, and I’ve always had a passion for numbers.

Still, I’ve definitely struggled a little bit in the new role. One of the things I’ve struggled with most is how to communicate numbers to the business team. It’s fine to make pretty visualizations, but how do I communicate the subtlety in the data? How do I communicate the fact that the numbers are as accurate as we can get, but there are still some sources of error ever-present in the system?

I came up with the following guidelines to help me talk to the business team, and I thought they might be useful to other programmers who are in a similar position.

Sources of Error

There are two categorical sources of error in any data analysis system.

  1. Data warehouse replication problems
  2. Bugs and algorithmic errors

Data Replication Issues

Inaccuracy of the first type is unavoidable, and is a universal problem with data warehouses. Data warehouses are typically pulling in huge amounts of data from many sources, then transforming it and analyzing it. In our case, we have jobs that should pull data hourly, but these jobs can fail due to infrastructural errors, such as an inability to requisition server resources from Amazon. So we have jobs that run daily as a fallback mechanism, and we have jobs to pull all the data for each table that can be run manually.

Typically, the data should be no more than an hour off of real time.

When ingestion jobs fail, the data can be recovered by future jobs. Typically, data replication errors do not result in any long-term data loss.

Bugs and Algorithmic Errors

It’s important to remember that the data analysis system is ultimately just software. As with any software project, bugs are inevitable. Bugs can arise in several ways and in several different places.

  1. Instrumentation. The instrumentation can be wrong in many ways. New features may not have been instrumented at all. Instrumentation may be out of date with the assumptions in the latest release. Instrumentation could be conditionally incorrect, leading to omitted data or semi-correct data.
  2. Ingestion. The ingestion occurs in multiple steps. The data has to be correctly propagated from the database, to the replicated database, to the data pipeline, to the data warehouse. Errors in ingestion often occur when only part of this process has been updated. In our case, fields must be added to RedShift, to Kinesis Firehose (for events), to Data Pipeline (for db records), then they must be exposed in Looker.
  3. Transformation and Analysis. The presentation of advanced statistics rests on several layers of analysis and aggregation. A small typo, or mistake in one place can lead to a cascade of errors when that mistake effects a huge amount of data.

How to Talk About Inaccuracy

The best way to talk about inaccuracy is to talk about what steps you have taken to validate the data.

  • What did you do to validate the instrumentation? How did you communicate the requirements and purpose of the new events to the developers? Did you review their pull requests and ensure that the events were actually instrumented?
  • What did you do to validate the ingestion? Did you see events coming in on a staging environment? Did you participate in testing the new feature then verify that your tests percolated through to staging analytics? Did you read the monitoring logs?
  • What did you do to validate the analysis? Did you compare the resulting data to the data in another system? Did you talk through the results with a colleague? Did you double-check the calculations that underlie your charts? Even when they were created by other/former developers? Did you create an intermediate chart and verify the correctness at that level of analysis? When you look at the data from another angle/table, do the results make sense with your new results?

Don’t dwell on the sources of error. Talk about what you have done to minimize the sources of error. In the end, this is software. Software evolves. The first release is always buggy, and we are always working to refine, fix bugs, and improve.

Make a plan to validate each data release like the rest of the team validates the consumer-facing product. Use unit tests, regression tests, and spot=checks with production to validate your process.

Top Line Numbers vs. Other Numbers

In general, you can never be sure that a number is absolutely 100% correct due to the assumptions in the process, and the fact that you must rely on the work of many other developers. Most charts should be used in aggregate to paint a picture of what is happening. No single number should be thought of as absolute. If possible, you should try to present confidence intervals in charts or use other tools that represent the idea of fuzziness.

But as in everything, there are exceptions.

With particularly important numbers, if the amount of data that goes into them is relatively small, then we can manually validate the process by comparing the results with the actual production database. The point is that for the most important, top-line calculations, you should be extremely confident in your process. You should have reviewed each step along the way and ensured to the best of your ability that the number is as close as possible to the real number.


When you’re trying to communicate the accuracy of your data to the business team…

  • Focus on what you have done to validate the numbers.
  • Keep in mind that the data analysis process is software that evolves toward correctness as all software does.
  • Validate data analysis like you validate any other software.
  • Where it’s possible and important, do manual validation against production so you can have high confidence in your top line numbers.

12. November 2017 by evan
Categories: Software | Tags: , , , , , , , , , , , , | Leave a comment

I paid my dues to see David Gray live

One of the reasons I am fascinated with both computer science and music is that each is a bit like magic. Each has invisible power to make change.

Yesterday, my daughter woke up with the flu. Actually, we found out today that she has croup, which is apparently going around her school. So Erin stayed home with her, while I went to work. But we also had to cancel our plans for the evening. Instead of going to the David Gray concert together, I would go alone.

At work, I was stuck in a meeting that seemed like it would never end. During this meeting, I got a headache that kept getting worse and worse. When I rubbed my head, I could feel my temperature rising. I could tell that I was getting sick too. The meeting dragged on for four hours, but I pushed through it.

By the end of the day, I was exhausted and feverish. I had driven to work, because I was still going to make it to the concert, even if I was going alone. But in Palo Alto, you have to do a dance with the parking authority if you want to park for free. You have to move your car every two hours, from one colored zone to another. I left work a little early because I knew there would be traffic on the drive, but when I found my car, there was a bright orange envelope on the windshield. I owe Palo Alto $53.

At that point I had paid $70 for the tickets, plus $53 for the parking ticket, so I had invested $123 to see David Gray. The parking ticket only steeled my resolve. I was going to see him come hell or high water.

And this is all sort of silly, because I don’t even like David Gray that much. Mostly, I have a deep sense of nostalgia for his one hit album that came out right before I went to college. I listened to it a lot in college. At the time, he was the only person I knew of who was doing singer-songwriter-plus-drum-machine really well. When I found out that Erin couldn’t come to the concert, I tried to explain this to my younger coworkers who I invited to the concert. They were nonplussed to say the least. A singer-songwriter with a drum machine really doesn’t sound very compelling today. It sounds practically commonplace. But nobody had quite figured out the formula back in 1998. So David Gray felt really fresh to me at the time.

My point is, I’m not a David Gray fanboy. I just respect the amount of time I spent listening to him when I was younger. Unfortunately, this is not enough to convince others to drive all the way up to Oakland for a concert.

The drive was hellish. If you have ever commuted from San Jose to/from Oakland during rush hour, then you know how this goes. The Greek Theater is only 40 miles from my workplace. The best route that Google could calculate took two and a half hours. I was in traffic for every minute of that drive, with a rising fever. It was extremely painful, and even though I left work fifteeen minutes early, I still arrived 10 minutes late.

But when I pulled up to the parking garage, things seemed to turn around. By this point I had a very high fever, the sun had gone down, and it was raining. So I couldn’t see the “Full” sign on the parking garage until I had already pulled in using the wrong lane. Everyone was continuing on to the next lot. At first I tried to back out of the garage, but then I realized that it wasn’t really full. So I pulled into a spot. I’d take my chances.

Then I stepped out into the rain, and started running to the theater. I could hear the music pouring over the hills. I saw a man standing in the rain, asking for extra tickets. I knew he was just going to scalp them, so I almost walked by, but fuck it, who cares. I gave him my extra ticket.

Then I ran up the steps, and breezed through security. I climbed to the top of the hill, and the music hit me.

That’s the moment when you feel the true power of music. I was all alone and feverish, in the rain after a long day of work and an awful drive to the theater, yet the music seemed to heal me. I could feel myself recovering as the sound washed over me.

I didn’t really talk to anyone. I listened to the music, and watched from the top of the grass. David Gray has a good band, and he has a good audience rapport. Even though his music isn’t as fresh today as it was in 1998, it still changed me last night.

I bought a shirt, and felt a lot better on the drive home.

David Gray at the Greek Theater in Berkeley

David Gray North American Tour 2017 Shirt

20. October 2017 by evan
Categories: Music | Tags: , , , , , , , , | Leave a comment

When Code Duplication is not Code Duplication

Duplicating code is a bad thing. Any engineer worth his salt knows that the more you repeat yourself, the more difficult it will be to maintain your code. We’ve enshrined this in a well-known principle called the DRY principle, where DRY is an acronym standing for Don’t Repeat Yourself. So code duplication should be avoided at all costs. Right?

At work I recently came across an interesting case of code duplication that merits more thought, and shows how there is some subtlety needed in application of every coding guideline, even the bedrock ones.

Consider the following CSS, which is a simplified version of a common scenario.

.title {
  color: #111111;
.text-color-gray-1 {
  color: #111111;

This looks like code duplication, right? If both classes are applying the same color, then they do the same thing. If the do the same thing, then they should BE the same thing, right?

But CSS and markup in general presents an interesting case. Are these rules really doing the same thing? Are they both responsible for making the text gray? No.

The function of these two rules is different, even though the effect is the same. The first rule styles titles on the website, while the second rule styles any arbitrary div. The first rule is a generalized style, while the second rule is a special case override. The two rules do fundamentally different things.

Imagine a case where we optimized those two classes by removing the title class and just using the latter class. Then the designer changes the title color to dark blue. To change the title color, the developer now has to replace each occurrence of .text-color-gray-1 where it styles a title. So, by optimizing two things with different purposes, the developer has actually made more work.

It’s important to recognize in this case that code duplication is not always code duplication. Just because these two CSS classes are applying the same color doesn’t mean that they are doing the same thing. In this case, the CSS classes are more like variables than methods. They hold the same value, but that is just a coincidence.

What looks like code duplication is not actually code duplication.

But… what is the correct thing?

There is no right answer here. It’s a complex problem. You could solve it in lots of different ways, and there are probably three or four different approaches that are equally valid, in the sense that they result in the same amount of maintenance.

The important thing is not to insist that there is one right way to solve this problem, but to recognize that blithely applying the DRY principle here may not be the path to less maintenance.

15. March 2017 by evan
Categories: Software Design | Tags: , , , , , , , | Leave a comment

Remaking Cool Music, Rebooting a Blog

I spent the weekend remaking the theme from the Netflix show The White Rabbit Project. It’s a pretty rocking little theme. I really admire any composer who can write a good piece of music that lasts only thirty seconds, and the composer of the original theme certainly succeeded in that respect.

In that blog post, I included the drum presets, synth presets, and audio files used in the remake.

So why didn’t I post that here? In short, I am trying to revive my defunct blog. I was pretty hardcore about blogging for about six years, from around 2007 to 2013, but since then I have let it slip. Social media seemed to take over and make blogs irrelevant.

Or at least it felt like my efforts were wasted three years ago.

Now I feel like I have more to say about computer music, and I feel like mass social media, where everyone is lumped together into one big mass, aka Twitter and Facebook, is dying. I feel like the flaws in it are apparent.

So maybe blogs are both the past and the future? Or maybe the future is something we can’t see yet? Either way, I am rebooting

18. December 2016 by evan
Categories: Uncategorized | Tags: , , , | Leave a comment

I love Pandora, but where is the discovery?

I have been a loyal Pandora subscriber since the month they started offering subscriptions. I love the service. I will continue subscribing forever, even if it’s only to keep my perfectly tuned Christmas music station.

But Pandora is not serving its audience very well, and that annoys me.

I probably listen to Pandora over five hours a day on each work day, and probably an hour or two on days off. When I tell someone I use Pandora, they inevitably ask me, “why don’t you just use Spotify?” More and more, I feel like they have a point.

In the past, I have preferred Pandora because it enabled discovery. It allowed me to create stations that would play music that I liked, but I had never heard. As a person who has spent decades of his life listening to and studying music, one of the main things I like about a piece of music is that I’ve never heard it before. In the past two years or so, I feel like this aspect of Pandora has dwindled or disappeared.

More and more, I feel like my Pandora stations primarily play the tracks that I have already voted for. Admittedly, some of my stations have been around for over a decade, so I have voted for a lot of tracks. When I vote for a track, however, it isn’t an indication that I want to hear that track every time I turn on that station. A vote is an indication that I want to hear tracks that are similar to that track.

But this is just too rare lately on Pandora. I hear the same Ellie Goulding tracks that I voted for last year. I hear the same Glitch Mob tracks that I’ve heard for the past six years. I still like that music, but I would prefer to hear something else. Why not play another track off the album that I voted for? Why play the same single track over and over?

“But why not click the ‘Add Variety’ button?” The ‘Add Variety’ button adds a new seed to that station. I don’t want to change the type of music played by the station, I simply want it to play OTHER music that falls within my already-indicated preferences.

What really irritates me, is that this doesn’t seem like a hard feature to implement. Why can’t a user tune the amount of new music they hear? Why can’t we have a slider that we can control with our mood? If the slider is set to 1.0, then we are in full discovery mode. Every track played will be one that we haven’t voted on. If the slider is set to 0.0, then every track played will be one that we HAVE voted on. In this way, Pandora could act like Spotify for users who like Spotify, and for people like me, it can act as the best shuffle on the planet.

As a programmer who has worked with large datasets, search tools like ElasticSearch, and written lots of web applications, I know that this isn’t a difficult change. It might require one schema change, and less than ten lines of new code. But it should be implementable and testable in under a week. Design might take longer, but here, I will design it for you.

pandora discovery slider

pandora discovery slider

And seriously, Pandora, I will implement this for you if you are that desperate. My current employer will loan me out, and even without knowing your code base, I could get this done in a month.

So come on, Pandora. Serve your audience. Stop making me explain why I prefer Pandora over Spotify. Add a discovery slider. Today.

11. December 2016 by evan
Categories: Criticism | Tags: , , , , | Leave a comment

← Older posts