Olessia Karpova from the University of Toronto summarizes her UCOSP experience:

First steps

The first step after being accepted into the program is picking the project. This year there were over 20 projects, how do you choose the right one? This is something you’ll be working on for a considerable amount of time – think about what your priorities are: is it to dive deeper into a topic you are already comfortable with? Dive into something completely new?It will be challenging either way – I thought that being familiar with the technologies used in the project will make the experience less overwhelming. This turned out to be completely wrong – jumping in on a project with a big existing code base is always overwhelming at first. The lesson to learn as quickly as possible is to ask questions. Personally, I’ve always preferred working things out on my own and not have to bug anyone. It takes some time to get used to the idea that the mentors are happy to answer questions, and that really, instead of spending hours trying to figure something out it is much better, for the project, if you spent ten minutes talking to someone who knows the code inside out and will probably be able to figure out what the block is from as vague a description as “the tests in file x all suddenly fail, and I didn’t do anything” (true story).

Working habits and expectations

Throughout my university experience I’ve been quite organized so I had no concerns about being able to put in the required number of hours each week, and keeping up with the workload without having to set aside specific time to work on the project. This turned out to be only partially true – I quickly realized that while I had no problem putting in the hours throughout the week, it was best to set aside a day when I could focus solely on the project. As students, we do not usually feel this with regular course assignments since they are usually rather small units of work, but with bigger and more complex projects it takes some time to get into the ‘zone’, so to say. It’s simply less productive to break up the 8 hours into 2 hour chunks if every time you have to take 20 minutes just to get back into the mindset and start working.

It is easy to get stressed in the first few weeks, feel unproductive, and completely overwhelmed with code base.

It is important, however, to manage your own expectations. It is completely OK to feel that way, no one expects you to start contributing code to the main branch in the first week. It is completely OK if fixing your first bug takes an entire day. Or if you spend the day trying and failing to solve a problem. The most important thing is that you’ll probably learn more in that one day then in a few weeks of a software engineering class. This really is the most important lesson to take away – and it took me a while to fully appreciate it – we learn best by failing. After struggling through something, we not only learn which solutions work and which ones don’t, but also how to change the approach to the problem, how to step away and look at it at a different angle, how to apply prior knowledge and when to search for new approaches. While failing _is_ learning, it is also important to know when to step away from the issue and ask for help. That’s a balance that can be hard to strike, but if you run out of ideas of what is going wrong it is definitely time to start asking questions.

Preparing the tools

There are a few things you can do to make the term more productive and get a head start. Most importantly, if you are not familiar with the version control system the project uses it is a good idea to get comfortable with it. You will definitely need to know how to update the repository, create branches, and commit your work.

Most of the version control systems have GUI’s these days, but it’s best to be familiar with the main operations and be able to do these from the command line.

Another suggestion is to find a good IDE for the language you’ll be primarily working with, and get familiar with its features. For python development I highly recommend PyCharm by JetBrain. (This advertising is based on a year of working with PyCharm and is not sponsored by anyone. By the way, IntelliJ for Java is also great.). As for features, take a look at how to do refactoring, finding declarations and implementations, code formatting and completion, setting up virtual environments, and many others. I find that it’s easy to get into sort of routine, where you’re comfortable with the tools and the workflow you’re used to, but there’s always, I think, a room for improving the workflow by using better tools, and using the tools you have better.

Final thoughts

It’s been a great semester and I learned a lot from the UCOSP experience.

I had a chance to be involved in cool project, do real, useful work, and meet and work with a number of great people.

It was by no means easy, but it was a great learning experience I would highly recommend getting involved in UCOSP to anyone in the Computer Science program. I am looking forward to sharing my work on the demo day in a few weeks.