There are many pitfalls when learning how to program. The biggest one, probably, is not asking for help.
There are many times that are issues are really quite minor, but without a second set of eyes to point that out for us, we get obsessive, and think that we’re a million miles from understanding. That’s not true, but without someone to make that 5 minute, conceptually easy correction, we can spin our wheels in the mud for hours, if not days. It’s not just profoundly discouraging, it’s also unnecessary.
Getting rid of that friction, then, that blockage that stops us from asking and then receiving the easy solution to our problems, is extremely important. We often need a ‘hook’ in the beginning, some kind of social engagement that can provide the emotional support of knowing that, with some effort, solutions are within our reach.
It’s not enough for an answer to objectively exist (of course it does); there also needs to be a personal element of positive reinforcement. Without that, great ideas and projects will languish in the darkness. Having good documentation is extremely important, and can make the difference, in many cases, between quitting and continuing.
That’s why I’d like to put together a Github open source project guide.
A while back, I emailed a person I know who had volunteered himself as a Rails mentor, asking for a good open source project to join. He sent me a very thoughtful reply, that encouraged me to document the ones I used that were light on documentation (plenty of opportunity there). It wasn’t until I saw a personal appeal on a mailing list, though, that I got attached to one.
The reframing of the project – from an impersonal , objectively useful slice of machinery, to an interface to a person and a project that I could help, as a person – made all the difference for me. I know I’m not the only one, either, as I frequently here beginners at meetups say they’d like to get involved, yet get no closer, meeting after meeting, to becoming meaningfully involved with contributions.
I’d like to replicate that dynamic on a website that people could use to browse through and identify good projects. As much as possible, that friction would be removed.
I would go through, examine the projects, and then create write-ups for each of them, and provide a top-level view for hundreds of such projects.
There would be a scale grading the difficulty level of contributing, for instance, and detailed how-to explaining how exactly to get involved at each level, with every step explained.
There would also be small testimonials from the project creators, and a sense that you, personally, would be helping them.
There would be some curating here, so that great projects wouldn’t be side by side with haphazard weekend ones with no way to distinguish between them.
Finally, I would also spread the word about the project and do what I could to promote it, to form a community around it to make it truly useful.
Because, at the moment, when I search for projects to join, the top Google results should me an undifferentiated mass of all-purpose projects, spanning every language, need, level of complexity, etc. There’s a preponderance of ‘junk projects’ clogging the pipes, projects that have their use and place but simply crowd out the really good projects that should be receiving prioritized attention.
A github open source project guide that addressed these issues and put forth an alternative way, then, would be extremely useful.