Lessons Learned for Project 2

This was the first and last group project at GA for our cohort. All in all, very great experience.

Working in groups is never without it’s difficulties, but we had a group willing to work together and whose individuals were capable of carrying their own weight. Everyone contributed equally to our success, crushing any fears I had about working in a group the week prior! It’s difficult to find a group where people are willing to get along and even more so for that same group to produce good product. We did that, and I feel fortunate to have had a good experience.

That said, the product got complex FAST …as all projects tend to do. Taking some lessons from my first individual project, we all agreed to start with an extremely simple idea: a blogging platform.

But not just a generic blogging platform! Travelogue, the name of our product, is a place for travellers to interact and learn about each others’ adventures. A user can visit the site, type in a location and read what other travellers have to say about it. The app focuses on being a niche social network for travellers. So what did I learn from this experience?

Prepare

I fell into more of a leadership role, but tried to stay more on the backend of development on our team, believing at the time that it was an area I could best serve us. Everyone pitched in for ideas, brainstorming, task lists and other suggestions, but by the end of the first night it was clear we really need more solid direction. Being the modular and often narrow-thinker that I am, I put together my usual tasks lists that I create when working alone and shared them with the group. It was appreciated.

We used Trello for planning, from wireframes to database models, and also for posting generic task lists. One of our team mates was out of town for a few days, so we tried to keep Trello up to date so that she could keep track of our progress.

We then used Github for most everything else and we centered our use on the Issue Tracker. There, incomplete tasks were logged a long with bugs, feature requests, and status updates. Just like with my first project, this turned out to be invaluable to keeping everyone on track and informed. It also meant that we could look at the issue tracker and just pick a task without needing to arrange meetings to sync up.  We knew from the tracker which tasks were already in progress and who to talk to if we wanted to help with that feature.

Collaboration

Our team met at least twice daily, but usually 3 times: morning Scrum, afternoon sync-up and the final git push of the evening (usually online via chat). In the mornings, we recapped what we did the day before and set our goal for the day. In the afternoons we assessed whether we reached those goals. Sometimes we were still working on finishing a few things which we’d agree to update later on. Finally at the end of the day we got into Hipchat to discuss pull requests and make sure that our master branch was production grade. All merges were committed and we considered ourselves done for the day. We had REALLY great collaboration and that enabled us to have an MVP by Monday afternoon, the first day of the week!

Other than the usual amount of stress and strain that teams experience, I felt like everyone was very helpful toward one another and also very determined to do their part. 90% of the time, when a pull request came it was working on it’s own and required no fixing. In fact, if I had kept count I wouldn’t be surprised if I committed the most errors and therefore most hotfixes to the master branch! Everyone worked hard to work together and I think as a consequence we had an easier time at keeping the app in order.

Levity

I know my team sounds dreamy at this point, but it was. People routinely left encouraging and even comical messages in chat; we brought each other snacks, we reviewed each others’ code and we gave a helping hand when others were stuck. All of us made silly little mistakes somewhere, all of us suffered code-blindness at some point …but we were able to laugh at it sometimes and we were eager to remind one another that we were doing well and that every effort was appreciated.

This gave our team tempo a nice mellow character, very relaxed even as we all felt our own amount of high stress at completing the project. At the end of the day, we made sure to tell each other that we’d accomplished a lot and were on track with our time table and goals. Unless something went wrong in those areas, we reminded one another not to over stress on any singular task: it was just too likely that it would find a solution in time.

Training and Building Simultaneously

So as new developers we’re learning that this is sort of the life we’ll lead, but that doesn’t make it a difficult thing to balance. How much time to spend on a problem before getting help? How much time to spend getting help before deciding on a different approach? How often to change an approach when you’re already days into your code? Each of us had our own experience with this, as we encountered our own hangups.

For me it was just Rails in general. I’d say I feel mostly comfortable with how Rails works on the surface, but I can get hung up on some of it’s intricacies. For example, I still have a lot to learn about using helper modules and building models and controllers for external APIs. I also spent a terrible amount of time trying to get ajax working on the front page before I was finally advised to do something else with it. On the one hand I wanted to move on to something else, but on the other we were at the finish line and there wasn’t much left to do — so why not spend that time on this?

Well there were half dozen reasons to not spend my time banging my head bloody against ajax. I think each of us had this kind of “stuck” moment where we felt defeated at not getting something to work. At the end of the day, we all did a lot of training as we worked on our part of the project.

Up until now I hadn’t worked in this close of a collaboration on any project as a team. It was a great experience and I don’t feel so apprehensive about working with teams in the future …which is a good thing, because I’m already on two open source projects where teamwork is the name of the game! A great shout out to Vikash, Margaret and Tani of the Wampas for project 2!

 

 

Leave a Reply

Your email address will not be published. Required fields are marked *