Most coders start their programming journeys alone. Whether taking classes or learning via web tutorials, they toil away, producing a piece of code in isolation and then releasing it into the wild to be judged by the rest of the world. But there comes a point along the journey to becoming a professional where learning to work within a team will be necessary. For someone who has had total control over their code workflow in the past, this can be quite an adjustment!
Your Place Within a Team
Whether contributing to an open source project, or being hired to a department at a company producing software, learning how to navigate sharing code is essential. It requires taking a good look at your relative strengths and weaknesses as a programmer. Are you amazing at writing routes and functions for communicating with a database? Or is nudging elements of a UI into pixel-perfect submission more your thing? Perhaps you are an expert at thinking like the end user and understanding the flow they will take while navigating through your product. Knowing where you can best contribute is a major element of being a successful member of a software development team. This does not always mean that you will be doing what you are absolutely best at. In fact, it may well mean that you watch as someone else does what you consider yourself an expert in while you pitch in with another task at which you are proficient, as no one else on the team has experience in that area. Having a good breadth of skills and a willingness to do whatever is most needed will make you a desirable member of any team!
Being OK With the Other Way
For someone who started the programming journey alone, it can be tempting to want to step in and "optimize" the work of others so that it gets done however you yourself would do it. But in doing that, you are risking the efficiency of the team. Why have two people doing the same thing, when you could be concentrated elsewhere? Now this is not to say that you shouldn't step in when someone is stuck, or when current practice is heading down a path that will cause future headaches for the team and vulnerabilities in the product. But if what they are doing is working, even though slightly different from your style, you will probably actually gain more from letting them do it their way and learning about alternate ways to achieve a programming goal. As coders, we tend to get stuck in patterns that we know, and seeing it done a different way can be valuable for freeing up the creative problem solving process.
Get to Know Git
The second area that a previously solo programmer might find challenging is how to physically share code. When you go it alone, everything lives on your local environment, and you are the only one making changes. If something breaks, you know you are the one who did it, and you can retrace your steps until the error is undone. Splitting code between contributors is largely made possible by version control. Quite often, that takes the form of Git, and its associated repository site, GitHub. The controls offered by Git and GitHub are practically essential to remote collaboration. But the interface itself can be daunting at first!
GitHub stores projects in repositories. They can be cloned or forked onto a local environment so that you can use them or improve upon them. If you program using VSCode, there is a native ability to hook up a remote repository to your local environment so that you can work on the project. But once you have the codebase cloned onto your machine, how to manage the workflow so that you don't overwrite the work of others and so you maintain a clean chain of custody for versions of the code? If it seems a little unclear or overwhelming, don't worry, you are not alone! This greatly confused me the first time I worked on a team... here's a brief overview of one workflow that worked for us.
Whose Code Wins?
Once you have a project stored locally by cloning it from the remote repository, you will by default be in the main branch. Edits you make will change your local version of the code of the project. This is all fine until you have to merge someone else's code with yours. What if you were both working on the same file? Whose version wins? Git is a powerful tool and has some controls in place to try and save you from heartache in such scenarios. If your version of a file is different than one that you are pulling from the remote repository, you will get an error message. You must first stash your changes before adding the remote files. This is as easy as entering
git stash
in your terminal, which will take your versions of the files and push them into a sort of temporary holding bin while you bring in the remote files via
git pull origin main
(It is good practice to do this at the start of any coding session in order to make sure you have the most up to date versions of all files stored in your local main branch). Then, once those files live locally on your machine, you can bring your file changes back safely by using
git stash pop
This will take the most recently stashed file changes and apply them over the most recent version of the files that were pulled to your main branch.
Branching Out
It is a good idea when you are working to be in your own branch. This means that if, for any reason, your code does not work out or you want to go back to the version that lives remotely and everyone else has, you can just check out the main branch again and your branch changes will stay in the branch you created. You create a new branch using
git checkout -b yourbranchnamehere
The process for checking out an existing branch is the same, but omit the '-b', which means create new branch. So to go back to a main branch from the one you are working on, you will enter
git checkout main
And if you wanted to go back to your branch,
git checkout yourbranchnamehere
Gathering Your Work
So, you work on some features in your branch, and when you are ready to send it to others for inclusion in the larger project, you will do a few things. First, in your branch, you will go to your terminal and enter
git add .
which will take any changes made since the main was last pulled and add them to a staging area. (You can also add files individually, but most often, you'll probably be adding everything you worked on, so we'll assume that for the sake of this walkthrough.) It's a good idea to check and make sure that all the files you want to add have indeed been added, which is easy to do by entering
git status
This will show you a list of all files that were tracked, which means they will be updated, and which ones were not tracked, which means they may have changed, but they are not automatically added to what you are sending. If you are happy that all your intended files are present, then you will commit them by entering
git commit -m "yourcommitmessagehere"
Your commit message should be a very short description of the things you changed in this update. For example, "updated the readme with new contact info".
Going Remote
Once committed, you are ready to push the branch to the remote repository for your collaborators to see. You accomplish this by entering
git push origin yourbranchnamehere
This will create a new branch on the remote repository, and upload your files. Whew! Done? Well, not quite!
Next, you need to go to the remote repository on the web, and create a pull request. This is accomplished by visiting the repository organization page via the GitHub website, where you will see a message alerting people that you recently made changes to a branch. Click on this link, and you will be taken to that branch page, at the top of which there is a prominent link to create or manage pull request. To the right side of the screen, you will have the option to request review by someone within the organization, to tag the pull request with appropriate tags like 'bug fixed', and to specify which project you are contributing to. You can also add a comment giving a little background on what you're adding. Once happy with that, click the create pull request button, and your teammates will get pinged that there is something waiting for their review.
Peer Review
If you get such a notice, you can review someone else's work by visiting the pull request page, on which will be a tab at the top saying 'files changed'. You can see each file that has changed, with the old lines in red and the new ones in green. Look over each file, and if everything looks good, you can comment or approve the pull request for merging. Once it has been reviewed by everyone who needs to see the files, then the pull request can be merged with the main branch, and the side branch you created can then be safely deleted, as the code now lives within the main branch.
Conflict Resolution (the drama free way!)
If, for some reason, the files in the branch for review are based on an older version of the main files than the current ones, a merge conflict will arise. Don't worry, such conflicts are easy to fix! You can review the differences between them in a diff file, which will show you both the current version, and the differences in the files you are trying to add. They will each be clearly labeled as to which file the code is coming from within the file. You can then choose which version you prefer to keep by deleting the version you don't need. Once all merge conflicts have been resolved, you can merge the file.
Congratulations, you have now become a contributor to a team project by both adding your own files and reviewing/approving the changes made by others!
Victory Lap
Becoming adept with version control systems and proper teamwork etiquette are both essential to becoming an effective member of a programming organization. Take the time to develop these skills alongside your other programming studies, as being able to work within a team is one of the most important qualities that hiring managers seek when looking to add you to a programming project. It is arguably easier to teach someone a programming language than it is to teach them to become a team player. So if you are a master at working with others as well as knowing your technical craft, you will be considered quite an asset
Can you think of any others skills that you must develop to be an exceptional tech teammate? Post them below! 👇