I’ve long since held the belief that our reactions to critical judgement of our work hurts so much because it’s so personal.
This has never been more true than on the Internet. In the world of distributed and isolated development, we often end up writing in a sandbox. We sit down and tune out the world and write code. And then we just deploy it to the masses for real-world testing. Many people are unit testing, which helps a lot, but as we’re such a distributed development world now, we rarely get the sit-down feedback we might with a company.
With that in mind, perhaps the over-reaction of people to their bad reviews (codewise) is a function of this distributed environment.
You’ve seen it, I’m sure. You leave a low-star review on someone’s product, annoyed that it doesn’t do something you think it should, and you’re replied to with vitriol. You’re astounded! You know that a one-star review kinda sucks, but you didn’t expect name-calling or, worse, someone to find your personal contact information and tell you that you deserve to die and you’re an idiot for not understand what code is.
I didn’t make that up. That’s happened. And since it happens, the question is why does it happen?
It comes back to the way we both develop code and the way we share it. The easier we make it to share our code in things like Github or official, public, repositories like the WordPress.org plugin repository, the closer the connection we make between developer and user. If you consider how it ‘used to be,’ the person who wrote the code may never meet any of the people who use the code. I’ve used Safari for years, but I have no idea who wrote it. Conversely, I’ve actually communicated with many of the Chrome developers about issues I’ve see and unexpected results. And goodness knows we all just ‘cope’ with how terrible things can be in Microsoft Word.
We’ve made the world more accessible for people to communicate directly the issues they’re having with software. This is a good thing. It allows us to develop faster and iterate code faster. We make things better faster. At the same time, it opens us up to issues like handling negative reviews.
If you’ve seen the movie Office Space, there’s a character whose job it is to take information from the customers to the developers, because developers are bad with people. We all laughed at that because we all saw the grain of truth. That tiny nugget of truth was that people who can bury their heads in the sand for hours to invent things are kind of weird people, and they don’t always communicate the way the ‘rest of the world’ does. Of course, now it’s 2015 and we know that it’s just not so. We all communicate similarly. Some of us just have more patience than others because we’re used to working with people more often.
Sunday is the 17th anniversary of the term “Open Source” in how we use it today. There was a public call to use ‘open source’ instead of ‘free software’, and we heeded the call. But open source has changed a lot from that day. We’re not just talking about free software that anyone can take and develop but the open lines of communication that allow us to develop it by working with the users in a closer relationship.
While many of us develop in isolation, writing and testing code by ourselves, the moment we release it to the masses we’re terrified. What if it breaks? It will. What if it sucks? It does. What if people hate it? They will. But we do it anyway, and when we, the developers, get that one-star review, it hurts. It punches us in the gut and makes us want to walk away.
Except… it shouldn’t. Certainly some reviews are made by absolute prats who demand the unreasonable. We don’t reply to support tickets for our free software fast enough, or maybe we didn’t refund their money when our store clearly says ‘no refunds.’ Maybe they hated it because we declined to add a feature. Maybe they just wanted to rant at us for 500 to 1000 words.
Yes, those reviews that are clearly full of anger should be ignored. And yes, those will make you feel like total shit. But the other ones, the ones where someone says “I wanted to like this, but the developer pushes an update every week and it really isn’t adding anything useful. This plugin has become bloatware and I’m not using it anymore.” Well hey, that’s actually a very nice one-star review. It’s a sucky one to get, but it’s fair and just.
So why do people often demand we delete those one-star reviews, or reply back that the user has no vision and cannot see how the plugin develops, or that the code is the dev’s and you should thank your stars it’s free? It goes right back to how we develop. We’re not used to the feedback and constant communication with others about our code. We don’t present our code to the masses until it’s at a usable or workable stage. And there are practical reasons why, but it means we just don’t know what it will be like to work with others to develop until it happens, and it seems to always happens in bad way.
What should you do? Keep in mind that the people who hate your code may have a point. Try to be objective and see it fairly. But don’t be a pushover and don’t let the people who are legitimate mean people get you down. It’s not easy, though. It helps if you have other people to work with on your code projects. Trusted beta testers, or even developers who are willing to take a look. Get yourself out of your isolation and you’ll find it’s a whole lot easier to deal with the crazy, if only to have someone to laugh with.