Four months ago I went to my first Civic Hacknight meetup held by Code for DC. I didn’t know how much I would be able to contribute, but as it turns out they are used to having new people show up and start hacking. Even though I had never coded in a team before, they showed me the ropes and got me involved in a project.

Work was divided up through the Github repository issues list, which described the bugs that needed to be fixed and features and tests to be added. Some of the issues were very small and simple and I think may have been added to the list just to help the new people get on board. Each of us picked the issue we wanted to work on and made a pull request to have our code merged into the main repository.

These are some of the things I learned from coding in a team for the first time:

1. Keep looking for a way to contribute.

When I first saw the code base and issues list, I was a bit intimidated. The code base was larger and more complicated than any toy app I’d made. The coding style was different from what I was used to, and some of the technologies were unfamiliar. They were using Mongo as the database, and I had never used Mongo before and didn’t know how it worked. Looking at the issues list, at first I didn’t see any that I could just code up off the top of my head and feel confident about. I finally picked a simple integration test to work on. Even though I wasn’t familiar with the Minitest syntax, I could look through the other integration tests and pull the syntax and coding style from there. Over time I got more accustomed to taking issues that I wasn’t familiar with and just researching them. I realized that I didn’t need to know the answer off the top of my head or get it right on the first try, and could always communicate with the team leader about any problems I was having.

2. Learn the code base.

I spent most of my time on the project poking around the code base and trying to understand it. Since I only worked on it sporadically, maybe once every few weeks, I needed to keep reacquainting myself even with those parts I was somewhat familiar with, as well as dealing with a constantly evolving code base. I’ve learned a lot from reading other people’s code, and some ways of doing things that I’ve never seen before.

3. Use Github as a communication tool.

We had a Slack channel to use between meetups, but Github became my main way of talking to the team, seeing what work needed to be done, and explaining what was going through my head in my pull requests. Issues, commits and pull requests all became tools of communication. The more clearly they were explained, the easier it was to get things done.

4. Develop awareness of my commits.

Working on projects alone I didn’t develop much awareness of my commits. I committed when I wanted to and often put multiple features or bug fixes into one commit. But on a team the commit changes are what gets seen and pulled into the master branch. For example, on one occasion I pulled from the upstream master branch and due to a change from Unicorn to Puma I was unable to get my server started and asked my mentor to help me get it working. He made some changes to Puma and Spring but I didn’t commit those changes and started working on my issue, then put all those changes into one commit. The next day the main repository switched back to Unicorn and when I made my pull request I had a merge conflict. If I had isolated the server changes in a separate commit the master branch could have cherry-picked my issue commit. Instead I ended up having to clean up my merge conflict.

I hope these tips can be of help to someone, but the best way to learn about coding in a team is just to do it. Going to a meetup or hacknight is a great way to get started.

Tags: , ,

In categories: programming, web development

COMMENTS

LEAVE A REPLY

Only the name field is required. Your email will not be published.