Getting over commitment issues

Since I left Uni back in the summer I've been promising that I was going to start releasing the code I was working on. By committing it to GitHub I could start sharing with others and learning from them. Well, I have a confession to make ... I have commitment issues. I've been worrying so much about making a good impression with my first commits that I've not made them yet.

I'm an idiot. No code that I release right now is going to set the world on fire (even if I polish it for the next six months). The whole point of releasing my code into the wild is that others can take a look at it and make comments, improve it and show me the stuff that they are working on. Only then will I start learning properly.

In fact, I was recently speaking to a coder (whose coding skills I greatly respect) about a previous project that he had created, and one which is pretty much the community norm in its field now. One of the first things he said when I mentioned I was going through the rdocs for the project was, "Don't look at the code!" Even he was worried about code that he'd written a couple of years ago. The way I see it now though, is that you will almost always look at code that you wrote 6 months, a year or even longer ago and find things to improve. If you don't, then you're not learning and you're not improving.

Then, this morning I read this blog post by John Nunemaker and I recognised the situation I was in. So, I'm going to do the same with my GitHub account as I have with my blog. I'm going to start anew. I have a project that I've started working on as a follow up to the first section of The RSpec Book. It's nothing impressive and it definitely won't be a trending topic on Twitter anytime soon, but it's a start. Tonight I will commit it to GitHub. It will be the baseline that I will measure all future coding endeavors against. Yes, it sucks and yes, I could do better ... and I will.

But not before taking that first step of actually committing it.