Critics and the Internet

Update 2016-06-23

I sometimes go through my old blog posts to re-digest what I’ve written and to see whether my opinions have changed. In this case, they have. At this time in 2013, I don’t think I was as acutely aware of the gender gap in CS. Or perhaps I was, but I most certainly was not aware of any of the cultural or psychological reasons behind it. And I was not aware of the way that affects us as individuals and in the industry.

I still feel that the situation could have been handled better on all sides, and I still feel that replace was a pretty silly utility to try to market as a useful piece of open source software. But reason must prevail in discussions of utility. And this whole situation, in retrospect, is maddeningly ridiculous.

Yesterday saw a minor uproar on Twitter between some relatively popular members of the open source community. I think the entire thing has been blown out of proportion, and I wanted to get some thoughts down on it.

The Incident

This untitled blog post complains about tweets from three specific individuals regarding a piece of open source software that she wrote. I find the reaction of (almost) all involved to be blown horrendously out of proportion. Indeed, the same individual posted a relevant point on how to deal with the same sort of non-constructive criticism she was faced with nearly two years ago. In my opinion, if she had taken her own advice, the situation would not have become so heated.

The Problem with Replace

I share a similar sentiment to Heather’s project, replace. I think it is largely useless as history has seen a number of command-line find / replace utilities. Modern versions of sed do in-place substitutions, but I will stipulate that it is not always the easiest utility to use for this task. Perl works. Someone even wrote a utility called Sarep (in Perl, no less). I see two problems with replace:

1. Confusion
2. Impetus

Confusion

In general, I think that more solutions to a problem are better. There are limits to this view. I see no need for redundant software. Given the existence (and ubiquity!) of other utilities that perform the same task(s) as replace, I think that replace crowds and ultimately confuses the solution set of a solved problem.

This is not unique to the replace project nor is it unique to Heather. I’ve written a grotesque number of HTTP servers in various languages over the years. Why? I either wanted to learn more about HTTP or more about the language (or both). Writing code is a fantastic way to learn new things.

Releasing that code to a wider audience can be a blessing and a curse. These days, you don’t even have to advertise your software for people to find it. They will find it. And some of these people will have constructive feedback for you. They will identify bugs. They will fix bugs. They’ll provide comments on the quality (or lack thereof) of your code. Some will suggest more idiomatic approaches to solving the problem. There will also exist the inevitable few who deride your project.

Replace feels redundant to me. The only benefit of its development is that it can list the changes it made to a particular file. I don’t see that as a huge benefit, and therefore I feel that replace ultimately serves to confuse people from tools that already exist in their environment. Tools that have existed for decades.

Impetus

Unfortunately, the reason this project exists isn’t because it was intended as a learning experience (or at least that reason is not cited).

In another post, Heather explains that she created replace because she is “always wanting to replace strings spread throughout my code, and never found an easy way to do it.” She admits that “find + sed can do it, but the syntax is hard to remember.” Fair enough.

What about Perl, though?

perl -pi -e 's/foo/bar/' file list

To apply this recursively to directories, you somtimes have to use find and xargs – but more often than not, you can use globbing. It’s also rather simple to do this sort of thing in a shell script:

#!/bin/sh

for i in `find $1 -type f`; do
    perl -pi -e "$2" $i
done

Ok. So this still doesn’t print out the context that changed.

#!/bin/sh

argstr="$2; print STDOUT \$ARGV . ':' . \$_"
for i in `find $1 -type f`; do
    perl -pi -e "$argstr" $i;
done

No line numbers? No problem.

#!/bin/sh

argstr="\$i++; $2; print STDOUT \$ARGV . ':' . \$i . ':' . \$_"
for i in `find $1 -type f`; do
    perl -pi -e "$argstr" $i;
done

Did I know how to do this beforehand? Sure. And it’s admittedly not the easiest problem to solve without experience. Would replace exist if she had asked peers what they use? Maybe, maybe not. But it’s pretty clear we can replicate most of its actually unique behavior in less than 5 lines of code.

The Problem with the Response

Do the above points justify a comment like “Ever wanted to make sed or grep worse?” Maybe not. They certainly warrant a comment. The code is readable and functional, so the comment, “… eyes bleeding!” seems like hyperbole.

Let’s think about that a bit. It is hyperbole. A hyperbole is explicitly not intended for literal interpretation. Literal interpretation is exactly what happened. Coupled with the post on how to avoid dealing with “assholes” in the open source community, I really don’t understand why this was taken to heart so much.

The Response Back

The critics have been labeled mysogynistic (not by Heather, but by people “sticking up” for her). I think this illustrates that there’s plenty wrong with the side of the “victims” as well. Even if we assume the claims that Heather’s personal livelihood would be negatively impacted because 3 people posted critical comments of less than 140 characters referring to a single open source contribution, we can’t infer that attacks to the other side are warranted.

If you genuinely hold the opinion that these people posed a threat to her livelihood, you are simply out of touch with reality. If I had a position that required her skillset, I’d probably hire her for it.

As part of the response to Heather’s detractors, I have seen the words “mysogynist,” “asshole,” and “douche” thrown around like candy. I’ve also seen (not the same) people say, “It’s never OK to be an asshole.” I should think that I don’t need to illustrate the hypocrisy here further!

On the point of it never being OK to be an asshole, I disagree. Criticism, even unfounded, personal claims, have a place in society and in personal function. In some cases it can be used effectively as a defense mechanism. In others, it is legitimately the only way to get a point across to a person. If you don’t know what I mean, hang out for a while in an IRC help channel. Negative, baseless, personal accusations and criticisms (when expressed as opinion) are also vital to protecting speech freedom. I’d be surprised if at least some of these people don’t derive enjoyment from the likes of South Park, Family Guy, or risqué stand-up comics – all of which provoke enjoyment by being overly critical.

Personal Experience

I’ve faced the derisions myself. When we are in new environments (whether that means learning a new language, new tools, or otherwise) we ask questions. That’s expected. It’s natural. We need to learn to grow.

Sometimes we ask dumb questions and we don’t do our homework. Worse yet is when we offer advice to people based on incomplete understanding (or complete misunderstanding) of a topic. These are destructive situations. We may not know any better because of our relative newness to the subject. Our inherent ignorance, however, absolutely does not give us the right to educate on the topic.

Releasing open source software is a form of education. It is fair to assume that someone with even less experience will find your software and learn from it. When your software offers a solution to a problem alread solved by standard utilities, you are robbing people newer than you of their learning experience. This can make people angry, and when people get angry, they get critical. You will be criticized for this. It is a valid criticism.

I have been criticized for that.

It is a hard criticism to hear.

Ultimately, you need to learn from the experience. You will be the better for it.

I realize I’m speaking in the accusatory here. This is not directed towards Heather, or any individual in particular. It’s just good advice.

On Twitter

Twitter is not a tool for having in-depth discussions or writing about deep topics. If someone is critical towards you on Twitter, don’t attempt to resolve it on Twitter.

This is just common sense.

Conclusion

In software, and in life, you need a thick skin. Some people are jerks. Some people are critical and there is no context as to the foundation of their criticisms. In either case, learn what you can and move on.

Fundamentally (and as is often the case in life) nobody is absolutely correct in this scenario. (That probably includes me, as well.) There are myriad great arguments to be made in support of either side.

From this situation, I would take away the following:

• replace is redundant and may cause confusion to and / or inhibit the education of people with less experience than me.
• I should continue to develop replace so that it solves other related and more difficult problems.

I would encourage Heather to continue her work in open source and take her own advice for handling criticism in the community. I’m sure she has many great contributions to come, and it’s certainly possible that replace can be one of them.