Yesterday, I received an email from someone who was kind enough to contact me about a security vulnerability that existed in one of my plugins (past tense because it’s been fixed :). This wasn’t so much an issue of code quality but potential security problem that could’ve been exploited by taking advantage of how PHP handles file uploads.

Generally speaking, this is one of the luxuries of open source – you’ve got other people who can spot vulnerabilities in your code and who can give you a heads up as to how to fix it. Of course, the flip side of this isn’t so nice – someone discovers a vulnerability, exploits it, and then you’re left dealing with whatever the fall out may come from that.


Watch out for this guy. He's after your code.

Watch out for this guy. He’s after your code.

Anyway, the understood protocol with security vulnerabilities usually works like this:

  1. The person who discovers the vulnerability contacts the developer(s) of the software to notify them of what they’ve found.
  2. The author of the software has a chance to respond and/or patch the software.
  3. Before the person who discovers the vulnerability opts to publicly share the story, the developers have 24-hours to provide a fix (or, at the very least, a statement about the problem).

This may play out in slightly different ways, but you get the idea. Naturally, you’ve got those who don’t follow this protocol at all, but that’s not really the focus of this particular post. Haters are going to hate and all that jazz.

Instead, one of the things that seems be happening more and more frequently is people calling other people out about the quality of their code via Twitter.

Should these situations be treated that much differently?

The Spectrum of Code Quality

To be clear, I don’t equate someone’s poor code (and we’ve all written – and are probably writing – poor code) with a security vulnerability or nine. Clearly, one has far less drastic effects than the other (though one may lead to the other).

Poor code can range anywhere from something being difficult to read to being something that results in a security vulnerability. It exists on a spectrum that may range from writing poor code from inexperience or writing poor code out of laziness all the way to writing poor code that can result in serious, negative ramifications for users.

As stated above, we have a bit of a social standard as it relates to the extreme cases, but in anything that’s less than that, we seem not to care and will publicly call out someone for the lack of quality of their code.

Sometimes we’re direct, sometimes we’re not. In whatever the case, an actual person has the potential to be the collateral damage.

The reason I think this is a problem is two fold:

  1. It’s one person pointing out another person’s problem to make one party feel more superior at the expense of someone else.
  2. There are far better ways to contact someone about their code and its quality (or lack thereof) than via Twitter.

On top of that, it seems that many of those who are quick to call others’ code into question under the guise of being helpful are the very same people who often have little to offer in the way of productive conversation or contribution.

That is, they may make some sort of joke or “#LOL” about someone’s code, but they don’t actually offer any guidance whatsoever on why it’s wrong, how to fix it, and why the proposed solution is better.

It contributes nothing but noise.

To make sure that I’m making myself absolutely clear: This is not about any one person (that is, this isn’t subtext – or a subblog or subpost or whatever sub you want :).

It's not a sub sandwich, either.

It’s not a sub sandwich, either.

Nor am I saying that this is how things areSome people do this, some don’t.

The challenge in talking about anything like this is that it leaves the author wondering if what’s being shared will just fall on deaf ears. That is, will the people who are the ones who publicly call others out about their code be the ones who take anything away from this (let alone read this)?

My pessimism says no, but we’ve seen communities changes over smaller things, haven’t we?

What Does This Look Like?

For anyone who has seen this happen on a service like Twitter, you know how it goes:

Someone grabs a piece of ugly code, takes it out of context, and chastises the code in some way. It may be very direct, it may be in subtext (or #subtweet), or it may be passive aggressive.

Whatever the case, when you’re working in a community with one another, it’s reasonable to assume that the person being called into question has a high likelihood of seeing their code on display for critique (I know, I know, “but it’s open source!” I’ll get to that in a minute) and ridicule, at least in this case.

Real classy, right?

This is but one example, and I’m not fabricating it. I mean, if I were to show something like this publicly, wouldn’t it undermine the entire point of this post?

Do Not Be Hasty

And whenever someone writes about this kind of stuff, inevitably someone is going to say that they’re writing about themselves in order to passive aggressively comment on those who have called them out in some way.

Don't Be Hasty

Don’t Be Hasty – this seemed a bit obligatory.

That’s clearly not the case, right? I showed that someone has contacted me directly at the very beginning of this post. On top of that, I’ve got plenty of blog posts and gists in which you can go back and read and see other people’s comments about code I’ve shared – some of it’s nice, some of it’s constructive, some of it’s destructive, and there are a few profanity-laden rants in the comments.

The thing is, this isn’t about me, as a developer. This is about seeing people in a development community be respectful to one another.

1. Understand the Context

If you’re going to be someone who is going to call out someone else’s code publicly, at least understand and/or even provide the context of the code.

It’s easy to take something out of context and bend it to whatever purpose you want. We see sensationalist news outlets do it all of the time. If you’re going to go after something someone wrote, go after the whole thing – not one ugly part of it.

2. “It Is Open Source!” Is Not an Excuse

Open source code is free and is licensed as such; however, it’s not some type of implicit license to mistreat other people. Often times, when code is being mocked, you’re mocking the person who wrote it – you’re saying something about their abilities or their quality as a programmer.

How lame.

Rather than do that, why not actually use the tools that we have in place – like inline comments in GitHub – and just provide criticism there.

What do you honestly have to gain by sharing someone else’s work in a public forum? It’s clearly not meant to be constructive because, if it was, then it would be handled in a forum where people can actually do something about it.

Social media isn’t that place.

3. What Goes Around May Not

So here’s the catch: People will often say something like “well, whatever, what goes around comes around,” but the problem with that, in this case, is that it’s just going to continue to perpetuate the problem, right?

That is, how would someone calling the initial offender out do any sort of justice? All it does is equalize the situation and perpetuate the problem.

I feel like a parent with what I’m about to say, but not responding to code criticism anywhere except GitHub, email, and similar places is probably the best policy. I’m not saying this won’t stop people from running their mouth about whatever it is that you’ve shared, but once something like that is out in the open, there’s very little that can be done productively via conversation.

Just quietly update the code and go on with whatever you’re working on. When anyone tries to look up what’s being called into question, it will no longer exist.

This Is the Nature of Our Field

Unfortunately, this is a negative aspect of our industry. There’s a lot to be gained via open source and a lot to learn from studying others’ code.

There’s very little to gain from chastising other people publicly, and there’s very little to learn from making fun of someone else’s experience. If nothing else, I’d figure that this would be a turn off to anyone who’s standing on the periphery of the community and trying to decide if they want to get involved or not.

Frankly, there have been times where I’ve said “if I knew now, what I knew then, I wonder if I would’ve gotten involved,” but even that is a bit misguided because it isn’t relegated to a single development community.

Reading Reddit or any of the comments on Hacker News will prove that.

Ultimately, all I’m saying is that we could stand to stop making fun of one another’s code. Be productive about it – give something back that’s actually constructive. Anything else is just noise: It detracts us from moving forward, it intimidates those who are younger and/or are less experience, it negatively impacts others, and it implies that you’ve never made any type of mistake or error in your development experience.

And we all know that’s not the case.


Join the conversation! 5 Comments

  1. Tom, would you be humble enough to share the file upload exploit? I have a PHP WordPress class utility to creates admin options for plugins and themes. One of the items is a file upload tool… and now I’m worried about it!

  2. I enjoyed this article Tom. Maybe if people viewed their tweets and posts as open source commits, they would make sure that they were all clean and productive.

    • Thanks Zack – and dude. I love this:

      Maybe if people viewed their tweets and posts as open source commits, they would make sure that they were all clean and productive.


Leave a Reply