Anyone who has walked the path of a developer knows, in the beginning, a big fear is working as a team. Even if you are learning how to code formally, through a college or university, you undoubtedly get nervous when the words, teamwork, or group project, come up for the first time. Perhaps, this idea of working in a group and writing code together is even more frightening if you’re teaching yourself. When teaching yourself you don’t always have a mentor to turn to if you’re worried your code is bad. Well let me tell you, you have nothing to worry about at all. It doesn’t matter if you learned how to write code through formal education, or informal education, in the end everyone is still just writing code.
My first group project was with the python_thursday group in the CodeNewbie Slack chat. I can’t say that it was a first for us all, but I know it was a first for me and I was truly terrified because I didn’t want to mess up and I admittedly did not want to be told my code was bad. However, after the details and issues for the project were laid out, me and another pythonista Jamal began to work on the project. We were all given a rundown of how github worked and were given resources so we could read up on the feature branch workflow and Object Oriented Programming(OOP), but nothing prepares you better than just diving in head first. The first few weeks I just started grabbing issues and coding what I thought was the best solution, albeit not knowing OOP all that well. The first task I took on was creating code that built out all the rooms in our project. However, the next task that was taken on needed to use the rooms class, and we decided we were going to include test driven development(TDD). Things were rapidly changing, and my rooms class had to be rewritten,and I knew why. I had mixed functional and Object Oriented programming and that was going to make further integration very difficult.
When TDD came up I was like a deer in headlights. Especially since I would have to redo more commits in my Pull Request because they were not backed up by tests. I was not upset though, I was more afraid that I would write the tests wrong. The first TDD Pull Request was the toughest because of the fact that with TDD you have to write the tests first. I worked through it and got the tests to pass and I got the Pull merged. It was then I realized that doing the project with TDD in mind really helped because now you were able to see what you were messing up if you were adding in new features. Just write some code, run the tests and see what you broke. After several weeks of writing code the group went and refactored everything, twice and we switched to pytest because it had better error handling and pointed out which tests broke and why they broke. This made the task of learning TDD much more easy. I would have to say, after that, the rest of the project went fairly smooth, almost two months in we were all fairly well versed in the art of TDD and comfortable enough with each other that pointing out bugs or flaws in the code was no big deal.
So although I was more nervous than I had been in a very long time, participating in the group project was nothing but beneficial for me and for the rest of the group. I had gained a bunch of new friends who enjoy writing code as much as I do and I had drilled in some concepts that were very new to me, like TDD, Object Oriented Programming, and github’s feature branch workflow. Looking back the only thing I might change is the code contained within my very first pull request. It was not very user friendly, but this is just another perk of group work, your group will let you know when your code is too tough to work with. What you should keep in mind when you’re thinking of getting into group projects, or any open source (since it is essentially the same thing), is do not be afraid to speak up or mess up. Someone is going to have questions about your code, and vice versa. You shouldn’t be afraid to listen to what they have to say, ninety percent of the time they are only trying to help anyway.