Drive-by criticism must die

Sunday, January 27th, 2013 at 3:10 pm

By request: if you want to comment on this, here is the Google+ post and the one onFacebook.

Criticism is a good thing. I am a fan of sensible disagreement and people challenging each other to think different about their work and change their attitudes after seeing a different point of view. Margaret Heffernan’s Dare to disagree TED talk is a great resource to watch if you wonder how that can work. This is what editing is about. A good editor can make a book or a movie much more than it is by challenging the author or maker to go further and think bigger.

Badly executed criticism however can scare, stifle and make people feel like a failure although all they might have done is a small mistake that can be easily rectified.

/disapprove

Good criticism takes time and effort. A good critic doesn’t only point out that something is flawed, instead it is important to explain what the flaws are, what their impact on the overall quality is and what could be done to improve. A bad critic flat out tells what should be done, believing in a subjective truth or way of working formed by the critic’s own environmental influences. That way the critic might be as far off the mark as the person criticized.

I just spent a few days at hack events helping people port their existing or build completely new apps. It was very insightful seeing a massive range of developers in different stages. I was most confused to see people who have very good ideas getting stuck at technical problems and when I showed some ideas and solutions being met with overwhelming thankfulness. When I asked these developers about their experiences in asking people I heard a lot of “Well, I am scared to ask as I don’t want to sound stupid online and people are quick to discard what you do as terrible”.

This saddens me. I, like most web developers I know, learned by looking at other people’s stuff and poking and changing it until it did what I wanted. Then I looked into why it works and spend months of my life on mailing lists and forums asking for and giving ideas and advice. Of course we all said terrible things in heated discussions and prematurely dismissed things, but in the end there was agreement – there was a feeling of having to communicate to become known and get to know people closer that you can learn from.

Enter social media and a 140 character throw-away, realtime web feed fast world of who says the most outrageous thing and “is awesome”. The pace of social media and its fragmentation (do you post on Twitter, Facebook, Google+, GitHub, your blog, JSFiddle, JSBin or where?) is a breakneck environment and it leads to people acting – possibly unconsciously – like complete sociopaths.

Case in point. Over on her blog, my colleague Heather Arthur describes how a piece of software she wrote was mercilessly shot down on Twitter by people other people look up to. Heather felt awful because of that – not only because she was criticised, but mainly because there was no explanation why her code was deemed bad.

This unknown element can make it very easy for anyone to find the flaw in themselves:

At this point, all I know is that by creating this project I’ve done something very wrong. It seemed liked I’d done something fundamentally wrong, so stupid that it flabbergasts someone. So wrong that it doesn’t even need to be explained. And my code is so bad it makes people’s eyes bleed. So of course I start sobbing.

Some of the people who shot down her code in far too short messages lacking any context and information now apologised and there were some good quotes in there:

I am sorry. I feel terrible that I made someone else feel terrible. I feel even worse because I didn’t mean to say that they were terrible, but accidentally did.
It is easy to forget that people write code. But it is important that we don’t forget that. Writing code is easy, putting it out in front of the world isn’t.

Heather ends with a very good point:

I evangelize open source whenever I meet new coders or go to meetups. I tell them to make something that they would find useful and put it out there. Can you imagine if one of these new open sourcerers took my advice and got this response, without the support I had. Can you imagine?

By being too fast and not detailed enough in our criticism we might actually right now discourage a lot of new people who could create amazing things in the nearer future. This is sad.

I am lucky that I have followers on Twitter (amongst the trolls) who are not afraid to point out to me when I am overly harsh or glib about something. I try to make amends when that happens and find that I learn more and more every time I do and it taught me quite a few things.

Let’s see a great example of how things could be done. Jan Hančič posted the other day Load scripts and styles with one request and I read the post and went a bit “uhhh, I am not sure” about it. Then I found a comment that perfectly covered what I wanted to say and didn’t hurt Jan at all:
——
Hey Jan,
Glad to see people hacking around; coming up with new ideas is always a good thing, no matter how realistic they are (the important here is to stretch our imagination).
Btw, the approach you describe has not been done by anyone else in the past, and I believe it’s for a good reason: it doesn’t help… Mixing CSS and JS is a bad idea IMHO, for many reasons:

CSS Is loaded in parallel by the browser, while JS is not;

CSS is loaded in the head (before the DOM is rendered), while JS is generally loaded generally in the body for performance reasons;

Minification of CSS and JS works differently, so including one into another is looking for troubles;

In a decent sized application, with a moderately big codebase, putting everything into 1 single file could end up with an unmanageable big file;

loading it in 1 single chunk would prove unpractical; either you end up with FOUC or you get a white page until the file complete loading by your browser; Moreover, loading 1 single minified CSS file and 1 single minified JS file is generally more than enough in terms of optimisation.

I’m not even considering that recent talks/rumors at Google seem to indicate that modern browsers are nowadays extremely optimised and performant also when downloading multiple resources (it was an Angular guy that glanced over this concept in a recent screencast..) Btw, don’t give up trying; Crazy Ideas can sometimes lead to great discoveries ;)

Cheers,
Davide
——
See what happened here? Instead of throwing out a quick “this is stupid” remark Davide Alberto Molin criticised in a picture perfect way: he started encouragingly, pointed out that this indeed is a new idea, listed the technical details that makes this idea flawed citing examples and ends with thanking Jan for throwing the idea out there and encourages him to go on doing that.

This takes time, this takes effort, but it has overall positive results. Jan was happy to get the comment and learn from it, I got a massive respect for Davide (someone I never heard of before) and Jan can update his post or follow up with one that takes the technical issues into consideration.

Long story short. If we want to encourage people to go out and show the world what they did (and we all learn from that) we need to stop dropping dismissive short sentence criticism and instead spend more time to explain, verify and validate our criticism. That way we can still prevent bad code from being used, but we don’t come across as a terrible person at the same time.

As Steve Klabnik puts it succinctly:

Twitter makes it so hard not to accidentally be an asshole.

Let’s use channels that allow us to give context and explain the why of our criticism instead – if it is code on GitHub, the issue tracker is a great place. We can still send a Tweet out pointing to our criticism there – thus showing that we are out to care and improve and not to harm and win the internets.

photo by Hobvias Sudoneighm

Share on Twitter