Contents

5.1.3. Coding in Teams

Collaborative coding is so essential to the process of solving interesting finance problems, that it underlies the objectives at the front of this website.

This page is focused on helping your teams attack the project in the most effective way. And it includes a few things that will push your existing GitHub comfort level up and make your team more productive.

Q: How should you “meet”?

A: It’s up to you! Be entrepreneurial and run your group as you all see fit. (WhatsApp, groupme, google doc, zoom, skype…)

Q: How should you approach working concurrently on the project?

A: You basically have three approaches:

  1. Sequentially divide tasks and conquer, e.g. Person A does part 1, Person B does part 2 after A is done.

    • I.e. in asgn-05 we had three files: download_wiki, measure_risk, and analysis. You can split up your project in a similar fashion.

    • Main advantages: Specialization + this “gives ownership” to one person for each part

  2. Co-work on a task simultaneously: Persons A and B do a zoom share meeting and co code on person A’s computer via screen share + remote control. Advantage: More brainpower, and good when the whole group is stuck.

  3. Separately attack the same task, then combine your answers: Persons A and B separately do part 1, and compare answers/approach, and put together a finalized solution to part 1. This creates duplicate and discarded work product, but will generate more ideas on getting to the solution.

Q: How do we work in the project repo “at the same time”?

The main issue is that two people might make conflicting changes. E.g., Johnny added a line to data.py but Cindy deleted a line from data.py.

A: You have, basically, two approaches, and you might use both at different points of the project:

  1. Free-for-all approach. Everyone works in the “master” branch of the repo all the time. This is what your default instinct might be. It can work, but you will probably have to fix merge conflicts to proceed at some point.

  2. The “branching” approach. Basically, you create a clone of the “master” branch to work on, and when you’ve finished your changes, you create a “pull request” where you ask the main project’s owner (you and your own team, in this case) to pull your branch’s changes into the master branch. See the demo video below.

Warning

Warning! Warning! Warning!

FOLLOW THESE RULES EVERY SINGLE TIME YOU WORK ON CODE OR DO ANYTHING IN THE REPO

  1. BEFORE YOU START ANY WORK FOR THE DAY: Go to GH Desktop and “Fetch/Pull” origin

  2. WHEN YOU ARE DONE WITH A WORKING SESSION: Clear your code, rerun all, save file, then push to cloud

If you forget to fetch/pull before you start (and someone made a change on the github repo since you last synced), or if someone is working at the same time (and pushes a change to the github repo that conflicts with a change you made), you are likely to receive a “Merge Conflict” notification from GH Desktop.

Collaboration as a group

I would love your feedback on how you deal with the asynchronous work problem!

  • Please let me know what issues/problems your group runs into

  • What solutions did you use (were they good or awful?)

  • If your group has an easy time, or finds something that works well, please let me and your classmates know!

  • Submit your experience on this via the discussion board

5.1.3.1. Branching Demo

Here’s the side text from the video:

  • Open GH Desktop and create a toy repo

  • start new branch “my work”

  • add data/data.txt into folder (to simulate some work you’ve done)

  • see how GH Desktop sees a change?

  • click to try to switch branch (don’t though)

    • it says “leave changes on this branch or bring to master” –> only the branch you’re “in” can see/push changes you make

    • cancel

  • commit to branch

  • publish up to GH website

  • view on GH

    • switch branches to see the new files

    • compare: you’re able to merge

    • can explain your argument for changes (to convince others to adopt in distributed projects), submit

    • merge, confirm

    • look at master branch - it should have data/data.txt

    • create “cynthia_did_some_work.txt” which says inside: “while i was sleeping”

  • go back to desktop like you’re going to work on the project

    • go to master… pulling origin would sync it but dont

    • go to “my work” branch

    • fetch / update from master: this gets the cynthia file, and I can continue

    • push this new file back up to my own branch on GH’s servers

    • make a new fake work file

      • publish/push

      • pull request

      • merge into main one more time

5.1.2. The modeling process 5.1.4. Sharing large files