So, the sixth week of software factory is now over, and we’re almost half way through the course. This week we made some progress on our eager loading feature, but not as much as we would have liked. This was due to some parts of the task being a bit unclear to us, and the lack of feedback on what we’ve done so far. At the moment we have some kind of an implementation ready, but we are not sure if it’s what they want. We remember Aaron mentioning the compiling of templates and something about mutexes at the code sprint, but our code deals with neither of those. On Monday, we sent emails to Aaron and Matthew (the mentors who know about our task) asking for feedback and explanation about the compiling, but they have still not answered. We tried contacting them in our project’s chat room as well but had no luck with that, I guess they are too busy at the moment. If they have not answered by Monday, we are considering briefing Eileen (another mentor) on our task and asking her if she knows anything about it, as she seems to answer other peoples questions quite actively in the chat room.

In the end, this week consisted of mostly just waiting for an answer, so I hope we can get it early next week and start finishing up our task. In today’s post I’ll write a bit about collaboration between students in our project.

Or the lack of it

As far as I know, collaboration in our project is mostly just collaboration between students that are in the same school with each other. So far, I have not seen team work between students from different schools. This could be due to the fact that the tasks that we can do are often small and unrelated to each other (bugs or small features), so it’s better to give them to individual students or small teams that are in the same school. We have not been given any big features that require a lot of people, so collaboration with students other than the ones at our school has been non-existant. This might still change though, as it feels like many are still just beginning the project, and our weekly meeting have not yet been organized. If we do start working with student’s from other schools, I imagine we will be using the tools that are already setup (campfire chat room, email, github and mailing list). We’ll see what happens.

Our local branch

So how does the team at our school collaborate? Since there are only four of us, it’s quite easy to figure out a schedule that works for everyone, so usually everyone in our team works at the university at the same time. Currently we work Monday to Friday from 10am to 4pm. Being only four, it’s also quite easy for us all to work on the same computer and on the same task, which is another benefit of being a small team. This is how we have done most of our work so far. One of us writes code while others give their suggestions and insights. If someone doesn’t understand something, it is explained by someone who does before we move on. This way of working has the benefit of everyone being on the same page and understanding everything that’s being done. It also lessens the chance of making mistakes and makes debugging faster as there are multiple people looking at the same thing. But it also has some bad sides, such as lower productivity. I actually prefer working alone. I find it’s easier to concentrate and get an understanding of the things I’m looking at when I get to do it at my own pace in a way that fits my working style best. This week and last week I had to increase the amount of work I do alone, and I feel like I accomplished more that way. I’m not going to abandon coding as a group though, it still has its benefits. I just need to find the right balance between those two working styles.

Online our team uses a communication tool called slack. Since we mostly work at the same place at the same time, we haven’t used it that much. We used it to communicate when I was sick and working from home, and it was useful in informing each other about what everyone was doing. For version control we of course use github. We have a private Rails repository to which we make changes, and a test application repository with which we test our changes. If someone wants to make a change, they make it locally, test it out with our test app and then pushes the code to our repository from which everyone can get it.