A few weeks ago, I shared a post in which I walked readers through how to achieve something within the context of WordPress. It essence, it was programming advice.

Programming Advice

The post was received okay, though it wasn’t without its [valid] set of criticism (which I’ll address later). Luckily, most of the people who responded did so via comments and emails explaining why they took issue with part of the code, and how they would go about addressing it were they having to solve a similar problem.

Not everyone was like that (and they never are). Instead, if you share any code of any type in any fashion with anyone you’re likely to get some type of response reading something like

It’s okay, but it’s not how I would do it.

The problem with statements like this – especially for those who want to get better at what they’re doing – is it implies there’s a better way, but the way isn’t offered up as a solution.


Programming Advice

I’m convinced, for programmers, would one of the best things we have at our disposal for becoming better at what we do is the Internet, as a whole.

But that’s really too broad. I dig the fact we have things like:

  • GitHub
  • Twitter
  • Slack or IRC
  • Email
  • CodePen
  • Blogs
  • …and so

I’ve met incredibly smart people who are willing to volunteer their time to provide insights and expertise on how to write better code simply to help others get better at what they do. It’s pretty good, isn’t it?

But it’s not without its challenges.

As with any group of people, there are those types who are likely to lord their knowledge over us as if they’ve received access to information few are able to achieve, and they use this perspective to detract from their peers.

As far as I’m concerned, that mentality and behavior has no place in the career and community of professional programmers.

Giving Advice

If you’re someone who spots problems with code someone has shared:

  1. Contact the person in whatever way seems best (Twitter, email, a blog comment, etc.)
  2. Let them know you see errors in their code
  3. Offer a solution or notes on what you would change and why you would change it

Remember the person to whom you’re speaking may have good reasons for the they’ve shared and written and it may not necessarily how they’d write production-level code.

Regardless, approach it from a helpful perspective rather than one of arrogance. Of course, if you’re still reading this, you’re not likely one who has to deal much with arrogance.

Receiving Advice

And if you happen to be on the receiving end up of this type of advice or critique:

  1. Hear what the other person has to say.
  2. Examine their code against your code. You may agree, you may not.
  3. Take their solution seriously and see if there’s something you haven’t thought of doing.

Sometimes, you have the ability to respond and justify your stance and ask further questions, sometimes not. And that’s okay. We’re not out to constantly defend the things we’ve done – sometimes, others will be right; sometimes we’ll be right.

Above All Else

The most important thing is we listen to whatever advice other people offer and determine if it achieves what we’re trying to accomplish in a more robust way.

If it does, why not learn from it, incorporate it, and share it for others to read?