Faraz Sherwani from the University of Waterloo shares his thoughts on the UCOSP program this term.
Why you may want to UCOSP
- Meet, work with and be mentored by some really smart people in your field.
- Learn a new language, or set of tools that a particular project uses, but that you are not too familiar or experienced with.
- Learn the details of a particular source control workflow that you may not have used in the past.
- Take a course that is altogether different from the Computer Science or Software Engineering courses you have taken or will take.
- Improve your coding style, habits and the general quality of the code you create.
- Code sprint (more below)
Why you may NOT want to UCOSP
- You do not want to or cannot handle doing some work (coding, designing, or discussing etc.) for a course, every week. 8-10 hours of work a week is generally expected for UCOSP.
- You have some course requirements for your major that you need to fulfill but that UCOSP doesn’t qualify for (At the University of Waterloo where I study, UCOSP counts as an elective, not a CS course). Check with your faculty for details on this.
I’m just going to write about what the UCOSP experience was like for me, and hopefully this will help someone who wants to know more about what the program is like.
Getting into UCOSP
I first heard about UCOSP, when I got an email from the head of the CS department at the University of Waterloo, suggesting that I apply. I was told it was a competitive program, where you worked on an open-source project for a course credit. As I read more about it and the projects available this term, it sounded like a great opportunity. I had put effort into my application letter, but didn’t think I would actually get in, so it was quite a pleasant surprise when I did.
Selecting my Project
After getting accepted into the program, in picking a project, I felt I had two options: to pick one for which I was familiar with the language and/or the topic and not have to put in as much effort into the course, or the opposite. I chose the latter, because having to use a particular language or toolset is probably the best way to force yourself to learn more about it, and this was part of the reason why I wanted to join UCOSP. The project I chose was Freeseer, which is written completely in Python; a language I had no previous experience with. There are obviously other criteria upon which you can base your selection, but in my opinion, this is one of the important ones. (You actually give a priority to each of the projects available, and then UCOSP tries to accommodate your preferences in the project they assign you to, but I got the project I had highest on my list so this wasn’t an issue)
I spent about a week before classes started (which is when your UCOSP work starts), learning what I could about Python and Freeseer. I read up on how Python differs from other languages I already knew, and the conventions and coding style it uses. The mentors for Freeseer had emailed us on how to get acquainted with the project. They sent us links for videos that explained what the app was about, and some checklists on things we would have to do to setup our development environment for the project, as well a project proposal template and some other useful stuff.
The mentors don’t expect too much from you in the first week. They had told us that they knew that setting up the development environment would take some time, but that we should try to get some tiny piece of code merged into the main branch, since this is what most people struggle with in the beginning. They also said that people who merge early, tend to get more work done over the term (and therefore a better grade), because they know how the workflow works and they’re not dreading the hassle of trying to merge. I had some issues with setting up my environment but managed to get something merged in the first week and was feeling a lot more comfortable with the project.
The code sprint is probably the best part about UCOSP. The location differs from term to term, but for our term, we had been told that we would be flown out to Facebook headquarters in California, which was pretty exciting for all of us. You can imagine my disappointment then, when the location was changed to Mozilla offices in Toronto, due to scheduling issues. I won’t go into the details about the scheduling issues because it doesn’t matter too much, but despite my disappointment about the location change, the code sprint was a great experience. I got to meet the other students on my project team, as well as the mentors (the one’s who could make it), and a lot of great people from the other groups. As I said earlier, UCOSP is pretty competitive, so all the people you meet are probably going to be a lot like you, because they’ll all have the same (or a similar) major as yours and will all be from the top of their class. Everyone was great, and I found a bunch of people who I shared interests with. Everyone had rooms on the same floor in the same hotel, and would go out in bunches to explore the city. In the mornings, we were to show up bright and early to the sprint location, where each team/project had their own giant table on which to set up their laptops and work. All in all, I would say that the code sprint itself made the whole UCOSP experience worth it. On top of that I enjoyed the work, but I would have done it just for the code sprint, even if I didn’t like the rest of it.
I’m not sure if this part differs from project to project, but in my case, we were told to come up with a proposal for what we wanted to work on for the term, why that work was a good idea, how we would do it, as well as a schedule for how long each component would take. Most of this was to be done near the beginning of the term, but certain things like schedule and implementation details would have to be added/modified as time went on. I tried to find a balance between not proposing enough work, and proposing more work than I would have time for. I wound up being ahead of schedule towards the end of the term and worked on some minor tasks for the remainder of my time but this is probably better than being behind schedule and scrambling to get the rest of your work done.
I really enjoyed UCOSP; it was a great opportunity, and I’m glad I chose to do it. If you’re not sure if UCOSP is for you, hopefully this helped.
Yanjia Xin from the University of Waterloo summarizes her UCOSP experience:
Now you made it into UCOSP! Congratulations! If you’re nervous about what is going to happen, don’t worry, it will pass. You will meet a lot of new people just like you and as time goes by, everything will become easier.
One thing to get started is to poking around the code base and get familiar with the tools you are going to use. That is to say, be prepared. Once you are prepared, there is nothing left to fear. Once you pick a project to work on, get some time to understand your situation before making any changes. Make a plan, and talk to your mentor about it so that you will be working towards the right direction.
Believe it or not, I often underestimate the time I need to finish a week’s job, especially during exam period. If you’re one of those super-organized people, this tip will be easy for you. The rest of us, however, need to develop a system for keeping track of meetings, appointments, assignments, and projects. Get an organizer or planner and keep on top of all your work. Schedule some concrete time each week to do your work and don’t wait till the end. You will never know what will come up to block your progress. And as you look ahead, set goals for yourself — and then strive to achieve them.
Take some notes
Take notes, and you’ll thank yourself later. If you’re a whiz with your handheld, jot notes electronically. Otherwise, invest in a small notebook that you can stick in your pocket and pull out when any idea comes up. This helps extremely when you allocate a small chunk of time for planning, and would like to pick up where you have left off later.
Ask for help
One of the most important thing I learned from UCOSP is asking for help. Don’t hesitate to ask questions when you are stuck. Mentors are humans, and extremely helpful humans. Remember, there’s no such thing as a dumb question. All right, that’s a lie. But after I struggled for days tracking a small bug which takes my mentor one minute to point out, I realized the dumbest thing that can happen is to waste time blocking yourself from making progress.
Think for the future
Another important skill I learned is to write clear documentation. This is very useful in real industry. If you’re stuck on the documentation writing, and aren’t sure how to actually write it, this is my mentor’s ultimate tip to get started: pick up a rubber duck or find someone and explain what you’re doing to them, explain it a few times, then write that down. A good documentation should be fully self-descriptive, allowing someone down the road to read through it and know exactly what you’re doing, why, and how, without having to dive into the code.
That’s pretty much it! To sum up, UCOSP is awesome! I really had a enjoyable time working on Review Board team. It was not so easy to get started, but once you get used to it, you will start to have fun. To me, it was a rewarding experience and I would highly recommend getting involved in UCOSP to anyone want to contribute. Enjoy!
Peter from UofT checks in:
ReviewBoard is a web service which facilitates code review amongst developers
within a repository (Git, SVN, etc). The project I am working on is an
implementation of TogetherJS, an extension (or plugin) that organizations can
choose to install within their instance of ReviewBoard. TogetherJS is a
text and voice chat and live cursor interaction. A demo is available here.
<https://www.youtube.com/watch?v=tEfbREmTBjc> It is similar to screen sharing
on Skype but has limited capabilities. Some of the features I have been
assigned to implement are to decouple this service from the Mozilla servers
and to reduce dependency on WebRTC. There will be an interesting balancing act
between taking advantage of all the available tools from the library and
keeping the extension a standalone project that services the needs of
ReviewBoard. The objective of this project is to help multiple developers
discuss a single commit in real time while in remote locations.
The most important lesson I have learnt in UCOSP is that this is not a course.
There are supervisors from the faculty, mentors of the project and peers.
However, there are no lectures, no assignments, no deadlines, no tests.
Throughout undergrad, attending lectures, keeping tabs on assignment and test
deadlines, and starting early to meet these demands helped me succeed. However
this does not work well with UCOSP. UCOSP requires a different type of
dedication. You really need to set aside time to work on it on a regular
basis. Furthermore you need to ask questions frequently. It’s very unintuitive
because with regular courses, the more time you spend on a problem on your
own, the more you learn. The opposite is true here. The more time you waste
trying to solve something on your own, the worse your overall performance. It
is much more productive to consult your mentors at every roadblock. Some
people may find asking many little questions bothersome but the mentors love
it. If they did not like helping, they would not have become mentors. The
UCOSP learning experience is really different, but there is no reason you can
not succeed because there is so much help available if you take advantage of