The act of showing poor source code either via our blogs or our open repositories can be a scary thing. I mean, we’re putting out for others to read and critique that we’ve worked hard to complete.

Sometimes we do it thinking that we’re on the right track; sometimes we do it when we’re asking for it.

Writing

In the latter case, I’d say that it’s not so scary – we’re asking for critique. In the former, isn’t it a bit more challenging when we get that criticism?

That is, isn’t it harder to deal with the criticism that comes on to something we thought we were doing right?

Of course. Does that mean we should stop sharing our code? No way.

Poor Source Code, Good Source Code

One of the things I’ve learned over the years of blogging and sharing code is that it’s okay. As authors of said blog posts, we should do our part in explaining:

  • What the code is doing
  • What we were thinking when laying out the code
  • Why we made the decisions that we did
  • And remain open to criticism

That last point is key, though. For example, I wrote a post a few weeks ago that generated a string of emails for how the code could improve.

I’ll talk more about this in an upcoming series of posts, but I updated the code and the post and all’s well.

  • I learned from what I had done wrong
  • I learned how to improve it
  • I updated the post so others can learn from that

And that’s what can come from sharing weak source code.

It’s Not Always So Easy

If I was to end the post here, then I’d be misleading you. It’s not always that easy because people aren’t always that helpful.

It’s easy to write about cases that have gone well in the past, but what about those that haven’t? On one hand, people don’t want to read about the negativity that comes with sharing their work. Then again, some people thrive on this kind of drama.

There’s middle ground on this, though.

Negative Feedback and Insults

If you share source code that can stand for improvement, prepare for negativity. That is, prepare to have others critique you without providing any clear solution.

Ignore that feedback. Flag those comments, delete those emails, and so on. No one benefits from them. If the feedback doesn’t provide some type of resolution, it’s not feedback. It’s an insult.

Don’t Stop What You’re Doing

It’s true: Just like when we were kids, some people are just mean. Their goal, their point is to convey how bad your code is and nothing more.

Ignore that and move on and continue what you’re doing.

I say this because I’ve seen peers question their career when a negative comment ruins their day. If the comment offers some type of improvement, then take it.

In fact, email the person and ask if they can discuss it more with you. I’ve done this and I still do.

Sometimes, it works out for the better; other times, the person doesn’t respond. Worst case scenario: You don’t get a response or they tell you to stop contacting them.

No big deal. But a single comment is not a show stopper and it doesn’t negate your work.

Look at how many people critique the major players in our industry for things they do. And look and how these major players continue to play ball.

That’s how you handle people when they don’t provide constructive feedback.

Keep On Keepin’ On

The whole point for writing this post is two-fold:

  1. Don’t be afraid of putting yourself or your code out there for others to read
  2. Don’t stop what you’re doing because of an occasional negative comment

If those who I admire, respect, and have learned from stopped, I’d have far fewer people to follow. If I did this, then I’d have stopped blogging years ago.

Yes, negativity hurts. I’m not down playing that. But take it in context as best you can.

Continue sharing your code. Continue garnering feedback. Continue discussing it with others. Continue working to get better at what you do.