A group project to redefine group projects.

For most of my educational career the term, ‘group project’ carried a negative connotation. Whenever a teacher would utter those two words, it usually meant being force placed into an awkward situation, where one person would self appoint themselves as the leader, and another person would figure out they didn’t need to contribute more than their name to get credit.
That’s why when I found out my project three for General Assembly would be done in a group, I got a little nervous. To this point, we’ve had two major projects, both of which required a lot of time and a lot of work. Adding the hurdles of poor communication and the inevitable, ‘lazy one’ that come with every group project seemed like a recipe for disaster.
My mind started to change, however, when I saw my group. I was assigned three people who, based on our class time together, seemed pretty compatible and easygoing. They liked to joke, liked to work, and all seemed to handle problems in a healthy and mature way. We got together, started talking, and my mind got firmly put at ease when someone suggested we get our pre-planning done during our day off, and everyone agreed.
We ended up meeting on a Sunday, and the very first thing we did was outline our strengths and weaknesses. We talked about how we communicate best, and how we like to be communicated with, and when everyone was on the same page, we moved on to picking out our idea.
We ended up choosing to build an app that would contain census data for the top 50 cities in the United States. One of my partners was recently moving and she thought it’d be helpful to know information on the people and the culture of a city before further looking into it. From there, we decided to divide up into two groups, have one work on the back-end and the other work on the front-end.
At the time I was feeling a little uncomfortable with REACT.js, so I asked my partners if they wouldn’t mind if I focused on the front-end, without hesitation they all agreed. We set up our wireframes, created our user stories, and ended our first meeting feeling great.
Then came the work, and man was there a lot of it. We decided to schedule team meetings every day at 8:00 A.M. and from there we usually worked until 9:00 P.M. taking the occasional, “I have to get away from the screen right now” break. Both sides ran into issues with the code, the back-end was trying something new by creating CRUD (Create, Read, Update, Delete) functionality focusing only on one aspect of our Schema. Meanwhile My partner and I were traversing the REACT.js terrain, and learning about why the, “componentDidUpdate” method is so useful.
After countless hours we were able to combine our front-end and back-end together, and get our app working. We then got all four of us together to finish up the styling, build out the README.md, and go over each others code to see what we all learned. When it was all said and done, I couldn’t help but reflect on what a successful experience the entire thing was. Everyone put in their time and effort, everyone communicated well, and the only problems we faced and conquered came from the code itself.
While group projects in the past may have created a poor stigma, this most recent one showed me how helpful and beneficial it is to work with a team, especially one as hard working, passionate, and patient as the one I was assigned to. I couldn’t be more happy with the app, but also the experience, I was able to get better footing with REACT.js, I was able to understand a whole new approach to CRUD functionality, and I was able to see the great benefit and joy of collaboration.
For those interested here is a link to our project three:
I never thought I would say this, but… I can’t wait for my next group project.