Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
×
Programming IT Technology

Volunteer Programming For Dummies? 195

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?"
This discussion has been archived. No new comments can be posted.

Volunteer Programming For Dummies?

Comments Filter:
  • Thank you! (Score:2, Interesting)

    by Anonymous Coward on Tuesday July 07, 2009 @11:52AM (#28609169)

    I feel like I'm in the same boat as you. I like to read programming books and I feel that I'm pretty good at many of the higher-level languages; however, I'm not sure how to take that knowledge and apply it to an open-source community. I started by looking at Google Code and Sourceforge and the source code they provide for many programs. I feel like I'm capable of working on some of these projects, but it's intimidating when the program is stable and you don't know what to contribute. There are bug reports I can look at, but they are generally over my head.

  • Non-Profits (Score:5, Interesting)

    by Snap E Tom ( 128447 ) on Tuesday July 07, 2009 @12:06PM (#28609403)

    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.

  • Re:Thank you! (Score:3, Interesting)

    by Deltaspectre ( 796409 ) on Tuesday July 07, 2009 @12:08PM (#28609435)

    A good place to start is the IRC channel for a project. Especially during the summer, since the organizations in Summer of Code will have idea lists up with many many unclaimed ideas. The org I'm working for this summer is Thousand Parsec ( http://www.thousandparsec.net/wiki/Ideas_for_Programmers [thousandparsec.net] ), but you can find other idea pages here: http://socghop.appspot.com/program/accepted_orgs/google/gsoc2009 [appspot.com]

  • GiveCamp.org (Score:3, Interesting)

    by SirLurksAlot ( 1169039 ) on Tuesday July 07, 2009 @12:22PM (#28609647)

    It isn't open source but it is volunteering for non-profits. I'm actually volunteering as a developer next weekend. Student volunteers are accepted and they are partnered up with more experienced developers. The projects are scoped to be completed in a three day time frame, and it is a great opportunity to meet people in your field, not to mention being able to contribute to a worthy cause.

  • by DriedClexler ( 814907 ) on Tuesday July 07, 2009 @12:27PM (#28609711)

    I'm in largely the same position as the submitter, and I think the problem is that jumping into existing programs like you suggest is not the simple step you make it out to be. Stuff that may same "duh!" to you, may not be obvious to others. Stupid as it sounds, what I really need is some step-by-step instruction set like:

    "If you want to contribute to [OSS project or class of OSS projects], download the source files [here], and compile them using [program], which you can download [here], by [following this compiling procedure] with [these settings]. If you're a beginner, check out the part of the code that [does simple task x] which is in [file], and see how it interacts with the rest of the program. This program depends on [other files], which you can get [here]. [Here] is an example of where it uses them."

    But I have yet to find some tutorial like this anywhere.

    Gee, it's almost like they don't want people to learn to how to contribute.

  • by WarlockD ( 623872 ) on Tuesday July 07, 2009 @12:42PM (#28609921)
    I complete agree. The best way to learn is to find a good problem you enjoy and solve it.

    I have been trying to learn practical Java even though I have a good C background. I found out the source code for The Ur-Quan Masters [sourceforge.net] was released for GPL and I thought, "Hey! I love that game, it has a special place in my heart. I also know it backward and forward, lets try to convert this C application to Java!"

    Trust me, its a miserable experience though. The code is organized haphazardly, even after its been ported to the PC. I never dealt with SDL so I have to go back on a lot of API's to figure out how they are doing the graphics. Heck, all I got now is just a handful of objects that just handle some simple database operations. Did I mention I am also "learning" Java? I barely know how JFrame works let alone the Graphics object. (Or Graphics2D)

    However, but struggling with this I am learning, by leaps and bonds, more about Java than I would of ever done in a book. I have to make practical decisions on the conversion that may effect the rest of my coding (ie, should I keep the original uqm file and resource file, or construct one easier for Java to manipulate)

    If I was you, I would search the net for a project I was interested in, see if there is free code available, then attempt to finish it. At the very least your learning some basic programing skills. If you finish, you would also contribute to the coding community :)

    PS - Also, it teaches you to document your code. I can't wine about the quality of the C comments in this thing because I don't comment very well myself:P
  • by fishbowl ( 7759 ) on Tuesday July 07, 2009 @12:52PM (#28610075)

    I wish more projects were as well-organized as KDE.

    http://techbase.kde.org/Projects/PIM/KMail_Junior_Jobs#KMail_Junior_Jobs [kde.org]

  • by Monkeedude1212 ( 1560403 ) on Tuesday July 07, 2009 @01:04PM (#28610247) Journal

    I have never found a more truthful, accurate, and informative response on Slashdot. Parent post

    The trick is simple, understand how programs "work" - once you've got the logic down its just a matter of putting that logic to a problem, then putting that solution into code. Examples only show you putting the solution into code, and don't tackle the bigger problem of really teaching you the logic.

    The biggest problem REALLY is finding the problem. Alot of people turn away when they think "Why would I take half an hour to program a step that takes me 30 seconds to do?" In fact thats what I did. Which I now see as erroneous, because any step that will be done more then 100 times that can be coded in a short time is always worth it.

    To be honest, I found the way I started was trying to design a way to kill time in class. I had taken a VB module in Comp Tech, which was very "By example" and unapplicable. But anyways, so I popped up my TI-83 Calculator and decided to program a simple game: High or low. 5 Guesses to get the # between 1 and 100, and the Calculator would only tell me if I were too high or too low.
    After mastering that (and programming it on all of my friends Calculators, because none of us had those nifty link cables) - It wasn't long before I took up another project.

    By the end of that year, I had a small scale, rip off of space invaders, about 6 enemies approaching you on screen, and you at the bottom moving back and forth to try and hit them.

    By Finals, I had programmed dynamic solutions to series of equations (solving algebra), also an easy to read and use UI for calculating all the elements of a circle (radius, Diameter, circumference, even Arcs and stuff!). Also a program that did derivatives in calculus. Because of me, my school forced everyone to clear their calculators memory of programs before writing diplomas.

  • by bmajik ( 96670 ) <matt@mattevans.org> on Tuesday July 07, 2009 @02:00PM (#28611115) Homepage Journal

    Step 1: find a peice of F/OSS software that you are interested in, use, or would like to use
    Step 2: use it to do real work
    Step 3: notice something in the product that appears to be a bug or a limitation related to your real-world use or desired real-world use
    Step 4: grab the code and start looking through it. Determine where in the code the problem seems to exist. If this is a segfault or something, fire up GDB, get a stack trace, grab the correct variable state to show the data conditions leading to the problem
    Step 5: construct a repro case for the bug that shows it is a problem with the code and makes the problem portable out of your environment into the maintainers environment

    At this point, you can contact the maintainers of the project if you want to. They'll appreciate the detailed research you've done and usually it won't take them long to come up with a good fix.

    Or, you could keep going

    Step 6: construct a hypothesis about what the problem is. If you have a repro-scenario and know where in the code the problem is surfacing, work backwards to understand the data and instruction flow that gets you from reading the repro state to the code blowing up. Based on your understanding, form a hypothesis as to what the specific defect is.

    Step 7: begin working on a local fix (i.e. don't do a world-visible checkout to a version control repository) to the problem. Continue iterating on your fix until the repro-case you identified earlier appears to have been repaired. Now test the program on cases that used to work prior to your fix to do some sanity checking that you've not introduced regressions.

    Step 8: once you have a fix that appears to work, check your fix against any coding styles or other conventions that appear to be in use in the project. You may want to look at past respository commits and comments in the file(s) you've worked into infer as much as possible about this.

    Step 9: wrap it all up. Compose an email describing the problem, the repro case, your understanding of the the solution, your patch, and the tests you did on the patch. Email the maintainers of the project and ask them if your problem and solution make sense.

    Step 10: based on what the maintainers say, your work may be done or you may need to iterate on your patch to improve its quality or conformance to the projects expectations. Your goal is to get a developer to accept any part of your work -- ideally, they'd commit your patch as-is, but if nothing else, the investigation you've done thus far will be helpful to them if they want to do a "better" fix in the future. And the tests/repros you've documented will be helpful for you (and them) to try when evaluating future fixes.

    This is the easiest way to get your feet wet in _any_ F/OSS project. I've contributed small fixes to a few different projects, and all of them were because I was trying to do something with the software that didn't work for me and my scenarios, and I investigated the problem to resolution and then submitted my findings to the real maintainers. In no case have I asked to become "part of the project" or any other such thing. If you find yourself drawn to a particular project on a regular basis, doing what I've described on a frequent basis will show the existing maintainers that you are serious, you are committed, and that you do good quality work. They'll ask YOU to start looking at stuff above and beyond what you've already done, and the involvement and sense of inclusiveness will happen naturally.

    Most people love to get free work done on their projects. Most have open repositories, email lists, and IRC channels. Just get to work :)

  • by raw-sewage ( 679226 ) on Tuesday July 07, 2009 @02:26PM (#28611555)

    A lot of comments here are of the "scratch your own itch" or "just find a project and dive in" variety. I think those are great ideas.

    But what about finding a mentor or coach? I've been a professional developer for about eight years now, spanning two jobs. In my first job, I had a mentor. Not so much for coding, but just someone to show me the ropes around the company, explain why things are the way they are, etc. I learned a ton from him; maybe stuff I could have learned on my own (or at least via asking lots of different people questions), eventually, but the frustration level would have been significantly higher. My mentor ultimately moved on, but by then I had gained experience and responsibility in that group. I knew what I was doing.

    Another, experienced developer came into the group. I wouldn't call him so much a mentor, but a peer who was great just to bounce ideas off of. We could have easily worked in "silos", with a minimum of communication, and probably been reasonably successful. But, again, just having a willing cohort made things go a lot more smoothly.

    All the above regarding my previous job has been underscored by my second and current job: no mentoring, total "trial by fire". Yeah, I know what I'm doing now, and can get by well enough. But I was miserable for a long time, given that there were simple things that someone could have helped me with and saved me a lot of time and frustration. And the "team" I'm on consists of me and one other guy. The other guy could have been a mentor, as he has several more years of experience in this field than me. But his communication skills are awful. And even though his code works, everybody who has ever looked at it cringes in disgust. So, if anything, he's an anti-mentor.

    The point in all this: in coding, or even work in general, it's nice to have a mentor, or at least a teammate with whom you can have an intelligent conversation. I personally find myself learning more, at a faster pace, and less frustrated when working with someone who's at least in the same ballpark as me mentally. Especially with coding: I greatly lament my current lack of teammates with whom I can do "cardboard programming"---just talking through my work out-loud, or bouncing ideas off someone often results in better code or design, or in the worst case, a better understanding of the issue(s) at hand.

  • by ari_j ( 90255 ) on Tuesday July 07, 2009 @02:29PM (#28611611)
    Incidentally, I initially got started programming by hacking an existing Lunar Lander clone written in GW-BASIC and provided with the family computer. An EE uncle encouraged me to learn how to make it display more data on screen to aid in perfect landings. Hacking on existing code is a great place to start, because the total investment between sitting down and having code that does something is much lower than if you start a new program from scratch.

    Eventually I got a book on C++ and a copy of Turbo C++ and learned the language. Around that time I discovered Minix and did a ton of programming on a 286 laptop running it, all in C. The big accomplishment was probably a set of several Tic Tac Toe playing programs with different AI strategies. Then I bought a used Sun workstation and learned more languages, probably Perl but it's hard to say anymore.

    But where I got the single largest segment of experience programming was hacking at PennMUSH, the online text-based role-playing game server software. It's good for this purpose because it is (even more so now than it was a decade ago) reasonably well-designed and well-documented, and because it is roughly the maximum size and complexity for single-programmer comprehension without investing years in the learning curve.

    Really what you need to do is find something that you want to do. Don't just try to join a project to learn - you and they will both end up frustrated. Add a feature to a program you use regularly (an IM program, for instance), write a program that would make your life easier, or fix a random bug from some project's bug tracker. If you get really desperate, watch the changelog for a program you use and try to implement equivalent changes without reading the code that was committed in the project's main repository first.
  • by bootup ( 1220024 ) on Tuesday July 07, 2009 @06:16PM (#28615017)
    I've got a small project that will benefit allot of people moving to GNU/Linux. I could use some help on enhancing it if you are interested. It is a firefox plug-in that is finished to the degree it is ready for distribution. It lacks allot of desirable features you could work on. Nothing too complicated either. Send an email to jade -@- kglug do.t org.

An Ada exception is when a routine gets in trouble and says 'Beam me up, Scotty'.

Working...