This week I embark on my second remote team project as part of the Chingu Cohorts. In doing so, I’d like to take a minute to reflect on what I learned in my first ‘Voyage’ cohort.
Working as part of a team is not something new to me. I’ve spent the past 20 years doing research in the pharmaceutical industry, all of which were spent on teams of various sizes and levels of interaction. This was, however, my first experience as a part of a development team and it provided some new challenges versus developing a project on my own.
My group was comprised of three people, all of whom had experience developing full stack applications and two of whom (not me) had experience with previous group projects through Chingu.
Of course, heading into the project, I had the usual apprehensions and nervousness about coding as part of a group, like “What if my code isn’t up to par with the others in the group?” and “What if I make a mistake and completely destroy the group’s code base?” and so on…
As usual, these kinds of apprehensions worked themselves out as we began to dig into the project and I’d like to think that I walked away a much better developer for having been part of it. I learned a lot from the other two members of the team, and I’d like to think that they were able to learn something from me in return.
As I reflect on the experience as a whole, I find there were two key elements that greatly impacted the progress and overall success of the team project that don’t come into play in individual projects, communication and workflow. As you’ll see below, these elements are very much intertwined, but I’ll address each of them individually.
Communication
When you’re working on a project by yourself you have a complete picture of the scope and state of your project at all times. If you don’t, it’s pretty safe to say your project is going to have some serious issues…
As part of a group project, however, you are dependent on your teammates to provide you with any and all changes they’ve made (and they are dependent on you for the same).
These communications can come in different forms, and we’ll get into some of them below in the workflow section, but suffice to say that if you’ve made a change to the project and have not communicated it in some way to your teammates, they are not aware of it!
Which means they will continue with their own tasks as if your change has not happened. This can lead to unnecessary headaches and many wasted hours down the road… All of which could have been prevented through good communication among the team members.
On the surface, this may sound like an obvious concept and not exactly worth writing (or reading) an entire article about. But if you are used to working alone, with all the communication happening unconsciously in your own head, this represents a critically important change in your normal process.
As such, make sure you act like a good teammate and keep everyone in the loop. This doesn’t have to be difficult or time consuming. Chances are your team has established lines of communication. Keeping everyone in the loop can be as simple as updating the status on a Trello card or dropping a quick line in a slack channel.
When in doubt, err on the side of more communication.
Meaning, if you’re not sure if something is relevant to the team, just throw a quick FYI out there to whatever channel the team is using and move on.
I doubt there are many former teams out there saying “I couldn’t do my work, there was just too much communication going on!” but there are plenty out there saying “Our team fell apart because nobody communicated…”.
Workflow
Which brings us to workflow.
By workflow, I mean how your team manages the git process and if they are effectively using branches, commits, pull requests, etc.
As I said before, this was my first group development project. I had used git previously for my solo projects but I had a lot to learn when it came to using git as part of a team.
Fortunately, Francesco Agnoletto has written a series of guides that clearly outline how git should be used in a team setting. I highly recommend reading (and bookmarking for future reference) all three articles. They can be found here — part 1, part 2 and part 3.
Personally, I’ve read them each several times and our group used them as the rule for how our team would handle workflow.
I’m not going to restate what Francesco has written in his articles, as I think he covers the material very clearly, but I do want to highlight several points that he makes as it relates to this article.
First, when done effectively, good workflow enhances team communication. As I stated earlier, communication and workflow are very much intertwined, and each can enhance the other.
Choosing (and sticking to) a good naming convention for branches will clearly let your teammates know exactly what you are working on. This, paired with clear and simple titles for your commits, not only provide the intended version control, but also a map of what each team member is (and was) working on.
The aforementioned guides have advice on naming conventions for both branches and commits. Read them!
Now that we’ve all read Francesco’s articles and are all on the same page as far as workflow is concerned, there’s one last point I’d like to make. Be very diligent about not making changes that are outside the scope of your branch.
This is very important and can not be understated! When working as part of a team, do not make changes that are not in the scope of the branch on which you are working!
In the spirit of honesty, this is something that I have a bad habit of doing when I’m working on solo projects. If I’m working on one feature and remember something that I meant to change in a different part of the code base, I just go and change it without worrying about what branch I’m on.
While this might be bad practice, it probably won’t get you into too much trouble when working alone. Doing this as part of a team project on the other hand, can have very bad consequences.
Making a change to code that one of your teammates is actively working on (in addition to pissing them off) has the potential to cause all kinds of conflicts when they try to merge their changes. They might spend just as much time resolving merge conflicts as they did making changes to the branch in the first place.
Not good for team dynamics…
Summary
If you plan on making a career out of software development, you’re going to have to learn to work as part of a team. This is definitely one of those soft skills that can greatly enhance (or hinder) your effectiveness as a developer.
It doesn’t have to be difficult though, it just takes some conscious effort. Stay mindful that you are part of a team and act as such. Strong communication and workflow will make your team greater than the sum of it’s parts, but the opposite will absolutely drag your team’s progress to a halt.
And if you’re working to become a developer, do yourself a favor and look into the Chingu Cohorts. It’s an awesome global community of developers and aspiring developers working together to do great things.
-Jeremy