Will Crichton

Providing programming language platforms to a large org & lots of users forced me to change how I think about and discuss PLs. Programmers will say "X is hard", "I don't like Y", "A is good", or "I love it when B" about a PL. * They cannot be wrong. * You cannot argue. 1/

These are your users and your customers. And they are telling you how *they* view their experience with the language. They can't be wrong. It's literally their perspective they are reporting. Finally, "the customer is never wrong" makes sense to me. You *have* to listen. 2/

And you can't just argue with them! Maybe you have a *brilliant*, wizard-level explanation. Suddenly, everything makes sense to them. Sounds great, doesn't matter. If users have to receive your brilliance before understanding a PL, you have failed. 3/

You have to understand what led to users having this view about their experience. Maybe the experience was different, but their *perception* and *memory* skewed things. Why? Maybe they experience the PL in a surprising way. What way? Why? 4/

And you have to change *the language* or *the way they learn or experience* the language to address it. It has to be systematic. You need everyone going forward to automatically benefit from the improvement, or it didn't really help. This requires that deep understanding! 5/

This means *your* experience or view on the PL is COMPLETELY IRRELEVANT! I know, it hurts, but it just doesn't matter. About all you can use it for is to help you understand *their* experience. Critically ask yourself before bringing up your personal experience: who cares? 6/

If you point out feedback is wrong, you won't learn how to improve. If you argue, you won't learn why (and your users will run away). If you don't fix the root cause, the fix won't scale. If you focus only on your own experiences, you will build a PL only you want to use. 7/