With more students starting to work with me on Natural Language Processing projects, I’ve decided to make a few posts on collaboration basics. Hopefully, these posts will help us plan and pursue our projects more efficiently and enjoy a distinguishable team work. This first post contains some general notes on teamwork and some more specific information on collaborative program development and writing.
Introduce yourself and your interests!
It is important to introduce yourself as clearly as possible as soon as you start working with a new group. It will help them identify your skills, interests, potentials and goals for suggesting the best fitting project to you. Therefore remember these four keywords and make sure you talk about them in your first meeting with the project manager or the main collaborator. If you hope to get financial help, have a publication, or someone to support you as a recommendation letter writer at the end, you should consider mentioning that in your conversation. For example some labs have a very good reputation or might help you get handson experience with some new techniques or research areas but cannot offer money or resources. So, be clear from the very first!
Be ready to learn and teach!
Starting any type of collaboration needs motivation and patience. If you miss one of these, teamwork does not suit you. Regardless of you being superior or not in the share of knowledge and skills you’re bringing into the project, you should always be welcome to new approaches, ideas and strategies. I personally, believe in the famous quotes of Steve Jobs “Stay hungry. Stay foolish.” The first part suggest that you should always push yourself to learn and experience different things. The second part though, means you should trust your intuition as well, thus don’t be afraid of sharing your ideas if you think something needs to be done differently, reason about it! It is usually perceived positively when you introduce a new technique or tools that the other people in the group have not been aware of… but don’t insist too much, specially if you’re being supervised by a more senior and experiences fellow! Instead, try to make it work and come back with good results. In other words, be responsible about what you propose and everybody will be happy in the end even though you might sound stupid at the beginning ;)
Be reliable!
Reliability is sometimes more important than performance. When people invest their time and energy to share their ideas and work with you, it means that they trust you. Make sure you keep in touch with your collaborators, even if you need a break, you’re too busy to work on the project for a while, or need to postpone a delivery. If you need to figure out a new schedule for yourself, let your supervisor know you’d be away for a while (in such situations, I usually tell them “I’ll send an email when the next part is ready but it will be in February/within a month/week/…”). Another important point is regarding sharing privileges: inform your collaborators in advance and get permission if you’re sharing data, code or unpublished results with someone outside the project. Finally, make sure you share your contribution fully with the project manager or supervisor. Leaving without a useful delivery (complete or easily extendible code/documentation) would be considered as if you wasted other people’s time. It’s neither a fruitful collaboration for your partners, nor a beneficial practice for yourself in the longterm.
Shared repository
We usually keep a shared repository for our collaborative work on dropbox, github, or a university server. It is essential for you to learn the basics of shared repositories and version control systems (git/svn). If you’re not familiar with version control, it would be a good start for you to create an account and set up a homepage for yourself on github. Many tutorials can be found on web. Check the following links as starters.
- For a proper introduction to version control systems see this.
- For a helloworld start with github see this.
- To make a personal homepage like mine on github have a look at Jonathan McGlone’s tuturial.
Documentation
Documentation is a very helpful means of communication between you and other people working on the project at the same time or in the future. Try to create README files, add comments to your code, and deliver technical reports at the end of each phase of a project. Communicate as few as possible important details via email and other volatile media. Instead write them down in your favorite format and place them on a shared repository (it doesn’t have to be the same place you commit your code or actual project material). Even if your supervisor is lazy to read your documents or does not contribute in creating them, you should do so because it will become useful if you decide to share the code or reuse parts of it in the future. Another type of documentation, which is less common in technical fields than in business, is meeting notes. Make sure you take notes of the issues discussed in a meeting, decisions, new goals and milestones. You can keep a shared folder on dropbox, where your notes are named and archived based on the meeting dates. It will function as a valid sign of your activity and continual commitment to the project. It is possible that you fail to deliver the results you were expecting you would at the beginning of a project; having documented the progress will help you explain why (to yourself and your collaborators). It is legitimate to spend up to ten percent of your time for the project on the documentation activities.