Developers can be very quick to judge another developer’s work – be it code, a blog post, or even a tweet – as to why they would opt to share one method of solving a problem rather than another.

And that’s a bit of paradox, isn’t it?

I mean, developers know that for any given problem, there are likely multiple solutions, yet they often challenge why one solution was chosen – or at least shared – over another situation.

And it’s not enough to actually challenge it, but it’s gotta be done with condescension or passive aggressiveness; otherwise, it’s just not enough, is it?

See The Hyperbole?

Furthermore, I think that developers can be some of the most critical people of their peers than many other industries (and that sucks, doesn’t it?).

My code is not perfect?

“My code is not perfect?”

Don’t believe me?

Just read any comments on any programming threads, programming blogs, Twitter threads, or anything where any programmer can share an opinion or method for solving a problem and watch the comment thread devolve into a conversation about who’s solution is more right and why the original author was stupid.

Okay, that’s hyperbole.

At least to a degree.

But the point remains: for many programming problems, there are multiple solutions some of which, yes, are more optimal than others, but many of which are no more right (or wrong, I guess, depending on how you see it) than their alternatives.

Understand Their Situation

To that end, if you’re a developer, and you’re challenging a peer’s approach to solving a problem, first try to understand the context in which they are sharing their code.

Perhaps it’s not so much that they are less capable, or a lesser programmer than you, but that you’re simply unaware of the problem domain and whatever solution you think should’ve been mentioned, covered, offered, or implemented wouldn’t fit given the requirements.

After all, we’re all well aware of project requirements, schedules, management, and how easy it is for things to end up getting off track early into a project, right?

And sure, at this point, it’s easy to  shift the burden back on the author and say that they should’ve done a better job of explaining the context of their problem, but how many people really want to trudge through a requirements document, email chain, or a history of Basecamp threads in a blog post as to why something needs to be handled a certain why because some third-party component doesn’t play as nicely with one solution over another?

Exactly.

Shouldn’t this be assumed, at least at some level? Don’t we owe one another that benefit?

Believe The Best (Don’t Assume The Worst)

So as a programmer, I urge my peers not to read programming articles looking for ways to tear down the solutions offered up by a peer.

Don't Be That Guy or Gal

Don’t Be That Guy or Gal

Don’t aim to challenge the author’s ability, integrity, or intelligence. Instead, try a more empathetic approach: They’re likely solving a problem in the way that they’ve shared not because they’re completely ignorant of alternative solutions that are available, but because of some sort of constraint that is limiting them for whatever solution you’d provide given their situation.

You’re not in their situation.

You are, however, in a place in which you could ask what prompted them to share the method that they’ve provided versus other options, or even open a conversation that could perhaps better your abilities.

After all, when you’re up against a challenging problem with a massive set of constraints, it doesn’t help when others come around to “tsk tsk” your work, does it?

So why do it to other people?