I read a great article the other day from Andy Lester. In it, he talked about different ways to contribute to open source projects, without the need to be a programming genius. I thought it was a great article, and agree with all his points. The one part that stuck with me, however, was this:

Diagnose a bug

It's a valid point. Diagnosing bugs is a bit part of software development, no questions there. But what if you don't know what's a bug and what's your own inexperience?

I remember when I started out, I often encountered issues when writing code. Thing's wouldn't run as they should. Or rather, they didn't run as I expected them to. Does this make it a bug in library x? Not necessarily, though it could be. How can you know? When you are new to software development, it's easy to misuse a library, get unexpected results and not know what the root is.

I spent countless hours trying to figure out why a certain piece of code wasn't working as expected. Sometimes I would find something silly in my code, and other times I wouldn't find anything. Was that a bug in library x? Again, it's hard to know. I remember thinking at the time that I must be doing something wrong, it didn't enter my mind that the actually problem may actually be coming from the open source library/framework/whatever I was using at the time.

So I think there is a point in one's career, where you are indeed, not good enough for open source. Where a distinct lack of experience directly affects your ability to distinguish between your own mistakes, and those of others.

How to get past it? Write more code, read blogs, get yourself as much exposure to software as you possibly can. In time, you will learn to see past what you have written, and use your understanding of the software you are using to effectively diagnose bugs.