It seems to be relatively common in the online developer community to easily dismiss others’ work when it doesn’t align with whatever we consider to be the best way to go about doing something.

I think it’s fair to say that this is something that we’ve all seen, too: Think about one of your favorite libraries, frameworks, applications, dependencies, or whatever, and then think about how critical and dismissive other people – or even ourselves – can be of the work.

Honestly, there’s nothing wrong with being critical – I think it’s helpful because it forces us to justify the decisions that we’ve made, defend our rationale, or even rethink our approach.

But when it comes to dismissing something solely because you dislike how it’s done represents a ill-formed perspective on the work that someone has done and a lack of understanding as to why things are the way they are.

Throw The Baby Out With The Bath Water

Again, I think critique is good. Having others explain why those chose one decision or implementation over another results in good conversation (and possibly education) for those involved.

But far too often – and such is the nature with open source – people are very quick to say that something sucks, that something needs to re-evaluate its terminology, or re-consider why it’s branded and/or described a certain way without considering the full picture.

This seems to be the case with any project that even gains a little bit of traction. I’ve seen it happen with small projects with peers, and we’ve all seen it happen with large projects like Bootstrap: Someone dislikes the way that, say, the CSS grid is organized or how they use (or don’t use) semantic class names and then they dismiss the entire project.

No one throws the baby out with the bath water.

No one throws baby out with the bath water.

I’m not saying that picking a problem with a project is a bad thing. As I’ve already stated, it’s helpful when done so constructively, but just dismissing something solely because you disagree with how the developers opted to implement a feature, or saying that the way a project is described without fully understanding the context of said project is weak.

Honestly, though. Come on.

If anything, at least ask why something is the way that it is and try to understand as much about the environment in which the project exists rather than just approaching it in a way like “if I was doing this, then I would’ve done it this way. They didn’t do it this way so it sucks.”

By the very nature of what we do, programmers deal with ordered steps and logic all the time. This doesn’t mean that we always make wise decisions, but it does mean that we [hopefully] know how to think in a rationale way.

To that end, there is likely a reason that a project is the way that it is, and if you don’t understand why, grant the benefit of the doubt that maybe some decisions were made given some information that you may not have – yet.