Slashdot Mirror
Volunteer Programming For Dummies?
Tios writes "I've been studying programming languages (C++, Java, C, Visual Basic) on my own with the self-guided, basic textbooks and tutorials, and I'm starting to get tired of working with examples that are not put into real use. I'm motivated to utilize my programming potential, but I've not had any experience programming in a team environment with lead developers, mentors, or collaborators. If finding a programming job isn't an option, I wonder if I could volunteer for programming in an open-source community. If this is a good idea, how do I start? What resources are out there that could get me oriented in volunteering? What kind of basic projects are out there, with a supportive team/mentor for me to develop, practice, learn, and contribute?"
The best practice is just doing it. That's how me and probably many others have learned about programming. In 90's I did have some programming and game developing books, but I pretty much read about those out of curiousity and because they were interesting. Actual programming knowledge comes from making something you like and learning from it. Every time you will learn more and more and it just goes along the way. In my teenage years coding games made the most fun out of it and I always learned more. This was even before Internet started to be so widespread, and only help I had was Delphi's (great!) manual.
Seems you only have experience in programming by examples. There's lots of times you need to be able to solve a specific problem, and programming by examples doesn't teach that really well. You will also be relying on someone's elses views and "best coding practices" thinking, instead of actually developing your own and seeing much further. You need to be comfortable programming and solving problems by yourself if you look to join a team.
I suggest you take some topic that's interesting to you and develop program around it. If you later get a better idea, don't be afraid to move into it. That's what happens to lots of programmers, but when learning it also improves creatly how you look at the problems and you see what you could have done better in your previous projects.
Here are a few notes I wrote a while ago on the subject:
http://kegel.com/academy/opensource.html
http://kegel.com/wine/sweng/ might also be of some interest.
That was my first thought too - he's missing the *middle* step. In between examples and collaborating on a huge multi-programmer project he needs to make something for himself first.
Weaselmancer
rediculous.
I think you've identified that as being the key for you.
Do you live near a Junior/Community College? They are often great resources for things like this. The computer club or whatever they call it these days is a great way to meet people you could collaborate with, and most of the professors at most of these schools (in my experience) definitely enjoy being mentors. You'd probably need to enroll in a class to be able to participate, but classes are relatively cheap and they might benefit you anyway.
When I finished college and relocated for a job, but didn't have a family yet, I took classes at my local CC for fun and to meet people, and joined a couple of clubs. This was a great experience for me, and there were several non-traditional (read: older) students who also participated (you might fit into this group). The great thing about the computer club was that other groups would come to us for help... we wrote a lot of programs to help the other clubs (especially the engineering club, since there was so much crossover in membership).
I'd imagine that the computer clubs now participate in open-source projects a lot, but it's been a while since I was involved... but it probably wouldn't hurt for you to start there.
"Trolls they were, but filled with the evil will of their master: a fell race..." -- J.R.R. Tolkien on Olog-hai
I've had a lot of experience volunteering for non-profit organizations. Granted, it's not the same type of "volunteering" that you mention, but it is a very good path to gain not only coding experience, but leadership skills, business experience, and of course, contacts. On the resume, it is definitely a differentiator. In interviews, I am always asked about my volunteer work.
That being said, there are several pitfalls:
1) The vast majority of non-profits are inherently very conservative and risk adverse due to their unique cash flow situation. You cannot just go into a group and say, "I'll build you X,Y, and Z and it will be fabulous." You must spend time gaining their trust in a volunteer capacity they ask for. If they're advertising on a volunteer site for a programmer, great. You're in. If there is an organization you want to help, but they're not asking for IT help, you may have to spend a long time volunteering for them in whatever role they need, buddy up to the higher ups, then offer advice on how you can streamline things for them.
2) Be careful of the organizations you list on the resume. They might not always help. The homeless, animals, and children are all very good causes that won't offend anyone. Sadly, though, gay and lesbian causes may turn off a born-again HR screener. I'm not saying don't volunteer for controversial causes, but I am saying be careful of what you put on the resume.
3) Be sure you know what you're doing. Even though it is a learning experience for you, it isn't. You are not giving any long term help to a organization by selecting obscure tools and sloppy coding. You will not be there forever. This goes for paid work and non-profit work. You may be hit by a bus, you may have a falling out. However, the product you create will be used for a long, long time. Use best practices and common tools. Mod me down, RoRers, but I recently talked to a non-profit that couldn't find anyone with RoR experience willing to help modify an app that some fly-by-night volunteer developed. They spent months posting on Craigslist and the usual volunteer sites, and eventually had to agree on a complete rewrite in PHP from another volunteer.
Drop the Visual Basic. Do it now. And never, ever, mention it again.
Confucius say, "Find worm in apple - bad. Find half a worm - worse."
I've been pondering over the same questions for some time, and appart from starting your own project (a good way, but not everybody has the creativity to make a successful new application, many skilled persons are best performers when putting into code someone's else ideas), I would advise you to pick a middle sized project (2 or 3 regular devs), and begin with ancillary tasks.
Many small projects build badly for instance ; so why not clean things up there, providing a good configure script ? Submit this, do the package for your distro, and maintain it. That should give you some familiarity with the code.
Do the code documentation if lacking, or write the user doc. Most projects lack this too. Read each line of the code in the process. At this step, you will certainly become part of the team in some way, and you will have expertise over the code.
Clean bugs. Now, you begin to have a feeling where they might be lurking.
Get involved in the roadmap. Code the new features you feel like you can.
That would be my take on the process
some projects have so called "junior jobs" - bugs or improvements that are easy enough so that a new contributor can tackle them - for example, http://techbase.kde.org/Contribute/Junior_Jobs
Rich
Navigating Sourceforge is a voyage of the damned.
There are only two types of projects here. Those going nowhere, and those already solidly anchored.
If you live in a 1st world economy, I wouldn't bother w/ RAC. Most buyers will only pay 3rd world wages to RAC sellers. It's quite frustrating and will probably be a complete waste of your time. The only Americans who make money at the RAC site are the owners.