Skip to content

Latest commit

 

History

History
51 lines (31 loc) · 5.3 KB

article-5.md

File metadata and controls

51 lines (31 loc) · 5.3 KB

Back <

Article 5/5: Working in a team is f***ing hard!

Hey guys, today I bring you my last article. You won't be finding any code or tutorials in this one, you will, however, hopefully, learn something from it. Today I just want to sit down and talk about working in a team. Do you know why? Well, it is f***ing hard.

For the past five weeks, I have been working with a small team of five students. We all worked together and shared the same goals. However, in the end, all we wanted to accomplish was to complete the given assignment. We worked as a team but didn't share the same grades or interests. This, however, does not mean we didn't care about each other, on the contrary, we did and a lot.

From day one we had planned every task around everyone’s personal goals. We tried to make sure each one of us learned everything he wanted to and that each one of us had something to showcase in the end. But you know, this was hard, very hard. At the beginning of this project, we had to choose if we were going to work as a group or as individuals. We all agreed to work together. We just wanted to make our client and teachers happy. We didn't want to deliver another prototype but a real product for once. In the end, we had noticed something quite shocking, if we had worked as individuals, each one of us should have delivered a more complete product.

You are now probably wondering how a team of five manages to deliver less than five individuals. Well, this is a university, and we are here to learn as much as possible. There is no point in assigning tasks to people who are already good or comfortable with them. We also spend some time pair programming and passing on our knowledge to each other. Yes, working alone meant that we could deliver a finished product, functional but dull. Doing so meant not learning anything and passing on the great friendship we have built together. Therefore I wish to thank everyone that endured my stubbornness during this project, and I wish to thank every one of my teammates for the great time we have spent together, thank you, for everything.

Below you can find a list of problems we have faced and endured together as a team. I am not saying these are the only solutions or even good solutions, all I am saying is that these worked for our team.

Git & GitHub

While working with a team on something, you need a place to store and manage all your files. Applications like Google Drive and Dropbox works fine when dealing with text files but not when dealing with codebases. Version control is a must, and the first duo that comes to mind is Git & GitHub.

We as a team were pushing about 100 commits each week, while this is far from ideal it gave us a relaxed feeling of safekeeping. If someone was to break something it could easily be fixed. But Git & GitHub is nothing new to most of you so let me share some Tips & Tricks I learned during this project.

  • Work in multiple branches: doing so will keep your codebase clean and easy to understand.
  • Merge master or develop into your own branch: doing so will prevent future merge conflicts. Do it early and often.
  • Don't merge pull-request, squash them and then merge: doing so will keep your master or develop branch clean and easy to follow.
  • Provide each commit with a title and a comprehensive description.
  • Start commit titles with prefixes. For example, fix, add or create.
  • Use GitHub issues together with GitHub Projects for an integrated Trello board system.

Tooling & Code conventions

Do you have any idea what the hardest thing is for developers while working together? Well, there are multiple ones:

  • Deciding if you should use 2 spaces, 4 spaces or a single tab.
  • Deciding if you should use single quotes or double quotes.
  • Deciding if you should use a semicolon or not.

Do you find these arguments as stupid as I do? Well, then you need Prettier. Prettier is an opinionated code formatter. It enforces a consistent style by parsing your code and re-printing it with its own rules that take the maximum line length into account, wrapping code when necessary. You can run Prettier on save or even before committing to GitHub. There is even support for your huge, non-necessary ESlint config file.

I don't care with task runner you choose to use, it can be Gulp, Grunt or npm Scripts. Just make sure that you use one. It can automate almost any boring but necessary tasks. For example, compiling files or optimizing images. Don't make the same mistake we did, implement a task runner before writing any code, do not waste your time doing this mid-project.

The End.

I am not sure if this article was helpful to anyone, these are just some thoughts I wanted to share with everyone before completing this project. These past five weeks were not always easy, but in the end, I am very grateful I was able to run this project with the people I did. You probably won't be hearing from me for a very long time, if ever. I do want to thank anyone that spend their time reading one of my articles and I really hope that at least one of them was somewhat helpful to you. Take care and code on!

Resources

Back <