How the Heck Did Spotify Convert Me to a Premium Account?!

I’ve used a number of services (both legitimate and illegitimate) over the years to listen to music. Just recently I was an avid user of Grooveshark, whose legitimacy is in question. On September 30th, Spotify became available in Canada. It has approximately 40 million customers, and around 10 million of them are paying Premium customers. I’m now one of them, but I certainly never intended to be.

Spotify Logo

Around the time Spotify was preparing to launch, some of my coworkers were trying to convince me to sign up. I had a lot of music set up on Grooveshark. The service was free, and I really didn’t want to set up all of my music on yet another service. Regardless, out of curiosity — hey, it’s free after all — I signed up and give it a try.

Honestly, I really didn’t want to like it, yet the interface on both Windows and iPad was excellent. It responded in just about every way that I wanted.

Compared to Grooveshark it was night and day. On Grooveshark I noticed that the interface was clunky and it was painful to organize my music. Sometimes music just simply wouldn’t load. My music would occasionally disappear — I assume this happened in response to takedown requests. Music was of varying quality, which makes sense since the source of music is the hard drives of other users.

On Spotify, generating playlists was easy, and my music was automatically organized by song, album, and artist — in fact the only thing not there is genre and I’ve had to create playlists for that specifically. They also have playlists available daily in a number of styles that allow me to discover music I wouldn’t normally play. Best of all, the music I find is high quality and always plays.

It wasn’t long before I stopped using Grooveshark entirely.

But Spotify gives its users all of this for free.

What are the differences between free and premium? Premium gives the user access to an extreme quality setting. On my Android phone premium allows me to pick the song I want to listen to instead of a shuffle play. Free has ads every 15 minutes or so. Premium allows me to download songs for offline play.

Premium is $10 / month. I’m confident that over time purchasing my music on a store like iTunes would actuallly by cheaper than sustained payment to Spotify.

One of the things that pushes me to Spotify over iTunes is that Spotify is platform agnostic. Regardless of whether I’m using iOS, Android, or Windows I still have access to all of my music. My music also exists in the cloud. While there is an option for an offline sync, it’s not required. If I get a new device, all of my music is immediately accessible, unlike with thousands of music files stored on my media server at home.

Again though, all of that is free.

How did Spotify convert me to a premium account?

The experience is simply worth the money.

It might all be free, but I am willing to pay for quality and I’m willing to use my wallet to show what I like. I have changed my settings to increase the music quality, and the lack of ads is nice. I still don’t make use of offline play, but I don’t need the feature in order for them to get my support.

If you are making a service, make sure the quality is there. If I like the service and the quality is not lacking, I’ll open my wallet for your service as well.

On Hiring and Trivia Questions

I’ve talked about FizzBuzz. I’ve talked about years of experience. But there’s another topic to cover which hits almost every developer interviewing for a position: trivia questions.

Everyone's favourite game of pointless knowledge.

I need to define what I mean by trivia question. A trivia question is a question that has a definitive answer that can easily be searched on Google. These include things like, “What is a singleton?” And, “What’s the difference between a thread and a process?”

Don’t get me wrong, these are questions where experienced developers should know the answer. But, anyone can learn and memorize the answers to these questions. More than that, if someone has the capacity for learning — as all developers should — then these are things people should be able to learn and grasp in a day.

I went to an interview ten years ago for a junior developer position. I thought the interview went pretty well. The interviewers were impressed with my experience from some projects I’d been involved in, but then they asked me to list off design patterns. I thought it was an odd question — I’d never heard of design patterns. Surely, they continued, I must have at least heard of a singleton. Nope.

The thing is, I was using various design patterns. I just didn’t know the terminology. A coworker of mine today told me a very similar story. He had brought in examples of code he’d written, but he didn’t know what a singleton was, so they weren’t interested. He told me that his code actually contained a singleton, but they wouldn’t give it the time of day.

Another coworker told me that during an interview he was asked to give examples of .NET interfaces. I can’t imagine many people who work in .NET would have trouble with this question, but I also can’t see any value in it. It is so easy to learn the names of interfaces that it surely doesn’t tell you whether a candidate can actually write any code.

What’s the number one goal of an interview when you want to hire a developer? Figuring out if the candidate can actually write code that you want to maintain. If the candidate can’t write any code then there’s no point in even going further. Trivia questions do not tell you that a candidate can code, they don’t really tell you anything at all. They do give candidates good stories to tell in the future that might discourage others from applying for positions in your company.

Here’s what I would suggest: when there’s an area you really want the candidate to know about, like design patterns or interfaces, ask the question. If the candidate tells you that they don’t know but they can learn, great! Ask them to prove it by taking a week to code a small demo application that shows off the point in question. Then have another interviewer where they can teach you about the topic.

This shows that the candidate has passion, initiative, and the drive and capacity to learn new things. It will also show you that the developer can code — or show you that they can’t. The reason you ask them to teach you about the topic is so that you know they didn’t just farm out the work or copy it from Stack Overflow without actually learning.

When I’m being interviewed, this is a key tool now. If I don’t understand something or feel I got something incorrect after the interview is done, I will correct myself and write some code to demonstrate. Then I email it to the interviewer. It can only help.

(And for those who are curious, I have learned about design patterns since that interview.)

Using exceptions to break command query separation

I had a conversation with my eight year old daughter this morning about using exceptions as messaging passing.

Me: I hate it when people use exceptions as message passing.
Her: What does that mean?
Me: When you ask someone if something is ok, there are exactly two answers. What are they?
Her: Yes, and no?
Me: That’s right. Using exceptions as message passing would be when instead you either answer nothing, or scream your head off that something has gone terribly wrong.
Her: That’s dumb.

She gets it. My eight year old was able to determine that a yes or no question is not exceptional if the answer is yes or no. Why are there professional developers out there who aren’t able to determine this?

I am tired of looking at code written by professional developers that looks like this:

public void AuthenticateUser(string username, string password)
{
    string actualPassword = Passwords.ContainsKey(username) ? Passwords[username] : null;

    if (password == null || actualPassword != password)
    {
        throw new ArgumentException("Password doesn't match!");
    }
}

What is this? When you are asking if a password is valid, or if anything is valid, there are exactly two answers that are expected: yes and no.

Expected answers are not exceptional.

This method should have read like this:

public bool IsUserAuthentic(string username, string password)
{
    string actualPassword = Passwords.ContainsKey(username) ? Passwords[username] : null;
    return password != null && password == actualPassword;
}

Now it returns either a yes or a no. The user is either authentic or they aren’t.

Exceptions are great, but they should be saved for situations that you really didn’t see coming or aren’t a valid answer to the question being asked. You want a value from the database, but the database is offline? That could be an exception. You want to access a file on a disk, but file access is locked? That’s an exception. You are dividing by zero? That could be an exception.

Here’s another example:

public void ValidateDateTime(object value)
{
    DateTime parsedValue = value as DateTime;
    
    if (parsedValue == null)
    {
        throw new ArgumentException("value wasn't a DateTime!");
    }
}

This method checks to see if a value is a DateTime. If it is, nothing happens, if it isn’t an exception is thrown.

Here’s the corrected version:

public bool IsValidDateTime(object value)
{
    return value is DateTime;
}

The corrected version is even smaller than the version that throws an exception! It should be easier to write.

Part of the problem here is that, this breaks Command Query Separation (CQS). If a method has a void return, then it should be a command. It should have a side effect. These methods do not. They are queries, they just want to know if a user is authentic, or if a value is a valid type. Since they are queries they should have return types, which is why the corrected versions return boolean values.

The other issue with using exceptions in this way is that you are going to litter your code with unnecessary try-catch blocks that could potentially catch actual valid exceptions that you would want to know about. Returning a boolean does not prevent the calling code from throwing an exception if that is, in fact, the correct way to handle it. But throwing an exception means that any code that wants to reuse the logic here will need to wrap this in a try-catch block in order to interact with the result.

You should be writing your code for maximum reuse in order to get as much value from it as you can. In order to do this, CQS and saving exceptions for cases which are actually exceptional will do wonders in the long run.

The JavaScript Guard and Default Operators

There are two operators used in conditionals that most developers are very familiar with. Those are logical AND (&&) and logical OR (||).

These are short circuit operators, which means that they will not execute the second condition if it is not required.

if (isCondition1 && isCondition2)

If isCondition1 is false, there is no need to compute or check the value of isCondition2.

if (isCondition1 || isCondition2)

If isCondition1 is true, there is no need to compute or check the value of isCondition2.

In C#, each side of the operator is computed as a boolean value. But, in JavaScript, that is not the case. In JavaScript the type is coerced to a bool but not actually returned as a bool, which works as expected in conditionals because you’re not actually returning a value, just checking the boolean coercion..

if (objectA)

is valid in JavaScript, because if the object is not null or undefined, it will evaluate to true, but if the object is null or undefined it will be evaluated as false.

This means that you can perform evaluations such as:

if (objectA && objectA.isCondition1)

The operator short circuits if objectA is null or undefined, so the second condition is never even checked, preventing a null reference exception when checking isCondition1. Just in case you were wondering, this is a great habit to have. In C#, instead of just listing the object as the first check you would specifically have a null check.

You don’t have to save these operators for conditionals though. In C# you can use these operators outside of conditionals in order to assign a bool value to a variable. In JavaScript outside of a conditional, the type coercion is performed to see how to handle the result, but the value returned is not necessarily a boolean value. This means that these operators work differently than you might expect.

var someObject = objectA || {};

What does that statement do? It is the default operator. It means that if objectA would be coerced into false then the right side of the operator will act as a default value, in this case someObject will be an empty object. If objectA is defined, then someObject will be a reference to objectA.

var someObject = objectA && objectB;

This is the guard operator. If objectA would be coerced into false, then someObject will be equal to objectA, otherwise it will be equal to objectB. Outside of conditionals and avoiding null reference checks I get a lot less use out of this one.

The Hidden Pitfall of Being Awesome

What happens when you’re awesome at what you do? Even more than that, what happens when you’re consistently awesome? You get a reputation for being awesome. People start to say great things about you and might even start to believe that you can handle anything that comes your way. Maybe you even can. But there’s a hidden danger here. If you start to buy into the things that other people are saying, you are apt to stop trying.

Sam Flamont related this issue to little league baseball, but the points are every bit as relevant to software development.

I asked how many times have you seen the best player become average and the average player become the best? It happens all the time and it happens because the kid who is the best begins to believe his own hype, where the kid is average keeps hearing his parents say, “Get ’em next time.” Well the average kid is sick of waiting until next time, he wants next time to be now, so he works and works as hard and as often as he can, while Kid Greatness is relaxing by a pool or playing video games.

I can almost guarantee that if you are consistently awesome it’s because you work hard. You have the killer combo of passion and drive that people want, but if you start to believe what people are saying then you grow complacent. You no longer believe that you need to work hard to maintain your status, so eventually you just stop working hard.

Once you stop asking questions, and quit pushing yourself you are going to lose the edge that got you that killer status.

Jeff Schmitt created a list of 12 behaviors that are likely to happen once you start believing your own hype. These behaviors can lead to your downfall.

In the past, you challenged conventional thinking. Now you’re the one who quashes your peers’ ideas. Your colleagues whisper that the golden boy who could do no wrong is slipping. A few even claim you hog the spotlight. You’d like to dismiss it all as a bad streak or jealousy. More likely, they sense that you’re losing those qualities—curiosity, openness, humility—that made you so formidable.

1. Dismiss questions.
2. Feel there’s no need for change.
3. Quit asking questions.
4. Don’t reach out.
5. Fall into a routine.
6. Look down on peers.
7. Lack self-awareness.
8. quit pushing yourself.
9. Grow sloppy.
10. Focus on producing hype.
11. Fixate on status.
12. Become dismayed when something’s amiss.

If you can’t believe your own hype, what can you do? Stay humble! If you stay humble you will keep asking questions and keep your drive and your passion. Thank people for the compliments that they give you, and then forget about them. Developers often suffer from imposter syndrome. This can be seen as a negative since you don’t feel competent and you don’t feel like you deserve your success, but when it comes to staying humble imposter syndrome can actually work in your favor.

Jeff Atwood has stated that in order to succeed you need to believe your hype.

However, if you have daily internal struggles with self doubt and indecision, you are almost certainly not going to achieve your mission, whatever it may be. I have found that, to a disturbing degree in this world, you have to believe your own hype to succeed.

He does go on to say that the opinions of others are traps, but says that we need to ignore them to get past our self doubt. I think that if you are lacking in self doubt then you need to ignore those opinions to get a little bit of that self doubt back because it will keep you hungry and strong. His final piece of advice is good: “concentrate on the daily routine of doing what you enjoy, what you believe in, what you find intrinsically satisfying.”

There’s a joke about believing your own hype that is attributed to Warren Buffet:

A very successful oilman dies. He faces Saint Peter, who says, “You’ve been a good man and normally I’d send you to heaven, but heaven is full. We only have a place in hell.” The oilman says, “Any chance I could talk to other oilmen who are in heaven? Maybe I can convince someone to switch places with me?” Saint Peter says, “It’s never happened before, but sure, I don’t see any harm in it.” The oilman goes to heaven, finds an oilmen convention and yells, “They found a huge oil discovery in hell!” Oilmen are stampeding out of heaven to hell, and our oilman is running with them. Saint Peter asks him “Why are you going to hell with them? I have a spot in heaven, you can stay.” The oilman answers – “Are you kidding, what if it’s true?”

Get out there, be awesome, be consistently awesome, but stay humble and stay passionate.

On Hiring and Years of Experience

Over a year ago now, I had an interview for a software development position. The interview went pretty well and I was expecting to hear positive news. Instead I got what I thought was the strangest phone call. I was told, “You’ve got great knowledge of the language, and your skills would be a huge asset to the team, but you just don’t have enough years of experience.”

The funny thing was, I didn’t feel let down at all. Instead I felt like the company had done me a huge favour — they saved me from taking a job working for a company with views diametrically opposed to my own. It’s a company that I can’t ever see myself thinking I might work for in the future.

Jeff Atwood wrote the following:

It’s been shown time and time again that there is no correlation between years of experience and skill in programming. After about six to twelve months working in any particular technology stack, you either get it or you don’t. No matter how many years of “experience” another programmer has under their belt, there’s about even odds that they have no idea what they’re doing.

With that in mind, do you really want to work for a company that still doggedly pursues the years of experience myth in their hiring practices? Unlikely.

That resonated strongly with me, because he hits the exact thought I had — that I would not really want to work for this company.

DHH also wrote about this in a post titled “Years of Irrelevance“:

As long as applicants have 6 months to a year of experience, consider it a moot point for comparison.

This is pretty much the same point made in the book Peopleware. Tom DeMarco and Tomothy Lister state that their research showed years of experience as a productivity non-factor. Only people with less than 6 months with the language did not do as well as the rest.

It’s my thought that ability, passion, and capacity for learning far outweigh other qualifications. If someone is driven to learn, able to learn, and has only one year of experience then there will be a higher likelihood that they will succeed because they will learn constantly and always be improving. On the other hand, if someone has 10 years of experience, but those years are all the same year, then that person will be less likely to succeed, and more likely to stagnate.

At the same time, I don’t want to entirely denigrate years of experience. If someone has 10 or 20 years of experience that build on each other, and still has a drive to learn and improve, I don’t think you’re likely to find someone better to have on your team.

When do decide that a candidate is not right for your team, don’t tell them that the reason is they have fewer required years of experience than you were looking for, worst case scenario is that they turn into someone you want and would never consider you again.

On Hiring and FizzBuzz

Now hiring

I read an excellent article today called, “This is why you don’t hire good developers” written by Laurie Voss, CTO of npm.

In the article, Laurie has a lot of great advice for conducting technical interviews for developers as well as some things that you shouldn’t do.

As I said, it’s an excellent read and I agree with almost every point in it, but I did take issue with one point.

People ask questions in interviews about obscure syntactical features of programming languages, or details of popular APIs. The famous fizzbuzz test simply asks “are you aware of the modulo operator?” If the answer is “no” then they are probably a pretty weak candidate, but it provides exactly 1 bit of data. Yet people will spend twenty minutes on it in an interview, a huge waste of limited time.

I happen to like the fizzbuzz test. Jeff Atwood of Coding Horror fame said the following regarding it:

I am disturbed and appalled that any so-called programmer would apply for a job without being able to write the simplest of programs. That’s a slap in the face to anyone who writes software for a living. -Jeff Atwood, Why Can’t Programmers.. Program?

See, it seems like saying fizzbuzz is a test of whether or not someone understands modulo is way off. Let’s take a look at what basic fizzbuzz is:

Write a program that prints the numbers from 1 to 100. But for multiples of three print “Fizz” instead of the number and for the multiples of five print “Buzz”. For numbers which are multiples of both three and five print “FizzBuzz”. -Imran Ghory, Using FizzBuzz to Find Developers Who Grok Coding

Does that sound like something that just tests knowledge of modulo? It is also testing knowledge of looping, conditionals, and most importantly basic problem solving.

Take a look at Trello’s fizzbuzz problem that they list on their developer careers page, it asks the applicant to take a look at a hashing algorithm and find the original string from an output hash. It is considerably more of a test of basic problem solving than it is a test of modulo.

I know that if I am looking for a developer that I want to work with, I want to make sure that she has an excellent knowledge of requirements and understands and can explain her problem solving process.