This summer I was lucky enough to finally get into the Google Summer of Code program. Just as one would expect, the whole experience was great! ;-) Anyway, I thought I’d share some things you should keep a watch on while writing a proposal or coding throughout the summer.
WRITING A PROPOSAL
Make sure that you submit a proposal that you’re absolutely, positively enthusiastic with. This is absolutely essential, and I double-emphasize the word “enthusiastic” here.
When you’re scrolling through a list of open-source organizations that you can work with and their lists of ideas, you might come up with an urge to submit a project proposal about whatever you think you would be able to get through. Like, “eh, this idea doesn’t seem too cool, but this requires Java and I know Java, so I’ll just give it a try”, or “I can’t see what’s the point of implementing this, but it’s in the ideas page, so I’ll write that up”.
Don’t do that. Not only the code quality would not be that good afterwards, but you’ll find yourself actually struggling through the summer, not enjoying it (and enjoyment is supposed to be part of the program). Actually, even worse - you might not complete the project at all because of your lack of motivation.
Instead, find an idea (in the proposed ideas list or by yourself) that you feel really fascinated about. Even if that particular idea requires you to learn a new language or some other technology, the enthusiasm will get you through the learning like a breeze.
For example, my summer’s project was about implementing Cocoa Touch (think iPhone) API in wxWidgets. I should admit that my C++ knowledge was a bit rusty before the project, but I really wanted that particular project done, so I more or less re-learned the language on the go.
Contact your potential mentor or a development mailing list before submitting a proposal. This suggestion is not new, but I would go even further - I’d say that you shouldn’t even bother submitting your proposal if your name hasn’t shown up in someone’s inbox previously, because your chances when you’re “coming out of nowhere” are too low.
Try to checkout and compile the current project’s source code from trunk by yourself. I should also call this some sort of an prerequisite for submitting a proposal. If you’re unable to build the project, and READMEs don’t answer your questions, don’t hesitate to ask a mailing list or even your mentor. This would not get you labeled as “stupid” - rather, it would show up that you’re genuinely interested in the project.
Find out whether your computer is powerful enough to build the dev build of the project. Heh, this is also a sneaky one ;-) Some projects are really big and require a certain machine capabilities to build in a sane amount of time or to build at all. For example, I think you shouldn’t even consider joining the Chromium project if you don’t have a rather decent multi-core processor with lots (4 GB+) of RAM, because the linker actually uses up that much.
My experience: I was running Mac OS X 10.6 and had only 1 GB of RAM; for a whole month (!) I was trying to figure out why my builds of wxWidgets were that slow - building a single CPP file took ~20 s, and the linker would run for a full minute or so. This was driving me mad, until I looked at the swap usage during the compiling/linking ;-)
Don’t be in a hurry while writing a proposal for the project. Again, take your time to find out from the mentors and other participants in the project’s community (e.g. from the mailing list) what’s needed for the project and how you can help. Don’t get in the “whatever works” game. If you’re able to come up with a single (yet, a good one) proposal for a single project, that’s perfectly fine.
WORKING THROUGH THE SUMMER
If you find it hard to stay concentrated at home, try setting up a 9-to-5 schedule, and head to a library or a coffee shop. This is what freelancers usually struggle with - while staying at home, you don’t have that work-play separation, and you either work for 18 hours straight until you pass out, or sleep/procrastinate for two days and bash yourself for not doing anything useful afterwards. So, this might help: wake up at 8 AM every morning, go to the same library of a coffee shop or whatever, and do some work until it’s 5 PM. Then, head home and read all the f7u13 comics you want ;-) This could or couldn’t work to you, but it might be worth a try.
Stop working only at the point when things are going fine. IIRC, this is Hemingway’s quote ;-) In other words, if it’s 5 PM and you’re about to head home or something, but you just broke some part of the code, or you can’t figure out why this or that isn’t working, it might be a good idea to not give up just now and continue working up until the point when the trunk is fine and things build/work correctly. On the same note, if it’s again 5 PM, and you’re in the “zone” when things seem to be going pretty well, and you think for a moment that hey, I should start this new unknown feature X right now, you better don’t - leave this new feature for tomorrow.
To summarize, the idea is to finish your day’s work in an “optimistic manner” so tomorrow you’ll be more eager to resume working. If you leave your code buggy or incomplete, if you’re “stuck” somewhere, there might be a big urge to procrastinate the next day.
![](http://blog.pypt.lt/wp-content/uploads/2010/10/screen-shot-2010-10-03-at-34102-pm.png "Pseudo-\\"Swedbank\\"")
![Anglonas įrenginiams "iPhone", "iPod touch" ir "iPad"](http://blog.pypt.lt/wp-content/uploads/2010/07/screen-shot-2010-07-14-at-62706-pm.png "Anglonas įrenginiams \")
