Whether you are learning to code, looking for a new job, or just want to improve your skills as a developer, you need to master the essential tools of team collaboration. These are as important as knowing how to code.

It is teamwork that makes or breaks software projects.

Your code will work eventually. If you want it to work “on time” and be of good quality, you and your team need to be organized.

• Everyone needs to know what they have to do and when
• People’s work should not overlap or clash
• Common rules need to be followed through by everyone

You can achieve this using the right processes and tools. You want your team to focus on coding 90% of the time (the remaining 10% are for coffee breaks and Windows Updates).

Here are four essential things you need to master.

1. Git and Pull Requests

Configuration management is the foundation of team collaboration in software. Many tools exist for it, but luckily one has become the absolute and ultimate reference: Git.

Documentation on the key aspects is well described in the Git Book.

There are plenty of turnkey services to get started: GitHub is probably the most popular, but also BitBucket or GitLab.

A great graphical tool to work with is SourceTree. I recommend you master the command line before reaching for UI tools, though.

Below are the questions you should know how to answer:

• How do I merge or rebase my branch, and what is the difference?
• How do I resolve conflicts? For example, mine versus theirs versus manual merge
• What is a feature branch?
• What is a pull request?
• What are the different collaboration workflows in Git?

That’s it, and this is pretty straightforward. After reading the theory and with some practice, you will become a Git master in a jiffy.

2. The Agile board

The first thing a team needs to do when starting a project or a larger task is to split the job. Over the last 10 years, the “Agile” methodology replaced the traditional waterfall planning. The Agile manifesto is here.

Practically speaking it says “let’s not plan too much ahead, because inputs and assumptions we have today about the project will change”. This is almost always true, and nowadays there is hardly any team under the sun that is not (sometimes self-proclaimed) “Agile”.

Here are the practical things you need to know:

• The most popular Agile way of working is Scrum. Divide your project into “sprints” of two weeks and put “tasks” in the content of the sprint. All the rest is for the future and is called the “backlog”. This is useful to track progress, adjust planning going forward, and improve team velocity over time.
• Another Agile approach is Kanban. The idea is to limit the number of tasks that are “in progress”. This way, you are sure to close one item fully before moving to the next. There are no sprints or time frames like in Scrum. You just go through tasks one after the other until you’re done. In Agile, a software project will be split into tens or hundreds of tasks. You need a tool to manage them. The reference tool is JIRA.

Other tools exist of course, but you will probably have to work with JIRA at some point. So if you are new to these all the tools, just go for JIRA. There is a free 7 day trial. It is more than enough to get an overview of how things work. Again, this is fairly straightforward, and very well-documented.

3. Testing and Continuous Integration

Git and agile tools allow teams to go fast. With speed inevitably come errors and bugs. Consider a team of five developers working on rather independent pieces of code. Each of them will make a pull request to the repository. Two problems can arise:

• Once the code of the “first developer” gets to the Git repository, the code of the others is no longer valid or working because some things have changed. This is not a mistake from “the first developer”, it is just life and it will happen.
• Once all the developers pushed their code to the Git repository, chances that everything work as expected out of the box are rather low. Again, this is not a reflection of poor teamwork. It will just happen.

Therefore, you need to test your software. Even after each developer has pushed their code? It would be great, but a waste of time.

When other developers push their code, we’ll need to repeat this task. Should you test once everyone has pushed their code? Also great, but you’ll find bugs late in the process, which can delay the whole project. So how can you solve this?

Automated tests and Continuous Integration are there to the rescue.

Automated testing is a topic one could write many books about. Each language and framework has its own set of tools. Listing them all would not make sense here. Just keep in mind that testing is time consuming and not always planned for.

Regardless, you should know how to write unit tests for your code and be proactive about writing them. If you don’t have time to actually do it, you should at least be aware that it’s wrong.

Continuous Integration is a process in which every push to your repository triggers a build and runs your tests automatically. A red flag is raised as soon as a faulty commit goes in. Pull requests should also be tested automatically before merging to avoid bugs that impact the whole team.

Continuous Delivery is the extension of Continuous Integration. If the tests pass properly, the tested version is pushed to the production environment automatically.

As an example: at Quora, they track the time between a push to the repository and deployment of that code to production servers. The last benchmark I read about was 15 minutes … for around 100 developers. This is the most powerful setup a team could hope for.

Popular continuous integration servers are Jenkins, Travis, CircleCI, and a few more. We at Fire CI promote a serverless approach to Continuous Integration to put developers productivity at its best. You do not need to know how to set the server up and everything, but you should know such tools exist, and a red alert should trigger in your head if your team do not use any.

4. Patience and understanding

As a developer your main frustration will not come from the code. You might spend a few hours searching Google and Stack Overflow for answers
but this is a driving activity. The real pain will come from the outside:

• Unclear or misunderstood requirements
• People unhappy with the end result of your work because they didn't knew what they wanted in the first place and they expected you to figure it out
• Tools that become slow or stop working for some reasons
• Interruptions now and then because people think that sitting at your desk means they can disturb you any time

The keyword here is "patience". Try to understand the people around you. They don't know everything. Remember that you don't either. Do make them understand though that your time is valuable and that they should respect it.

The last but not the least when it comes to customers and requirements: do not accept low level or clumsy detailed requirements if you didn't get a brief on the big picture. You need to understand the business you are building software for. At the end of the day your code is here to improve an existing process or enable new ones.

The better your understand the business side of things, the better developer you'll be.

Conclusion

The core of a developer’s job is coding. Once you move from solo/hobbyist to member of a performing team, proper use of the key collaboration tools is as important as writing clean code. Hopefully this article gave you an overview of what these tools are and how to dig further to be the best at what you do!

Originally published at Fire CI Blog on April 5th, 2019.