Collaboration Tips

Note: This page is a reference for instructors who advise student teams. Students can also use it to draft a plan, then review that plan with an instructor or experienced student.

Note: Some of this advice applies to projects, or engineering projects, or software projects, in general. Some of it is specific to physical computing or the Arduino.

Alternatives for how students can work together remotely:

• Divide the project into pieces (components); each do some of them. There’s an art to dividing a project into pieces that can be done separately, and it’s especially difficult if you haven’t done a lot of projects before. There’s more on this below, but it’s good to run your work plan proposal by an instructor or other advisor.
• Use collaboration tools, so that you can work on the same component together on one screen. See the section below, on Collaborating on Code.
• It’s often nice to combine these techniques and/or switch back and forth between them. For example, work on a component alone while your partner works on another component, but switch to working on the same thing together: if one of you gets stuck, or to give each other feedback and fresh ideas, or to make sure both of you get more learning out of the project.

Separating a project into components

• A larger project can be broken down into an ordered list of tasks. Each person takes a new task from the list, when they’ve completed the one they were working on.
• An easy way to divide a project is by fabrication technique; for example, code vs circuit vs fabrication of housing or enclosure, etc. This may be enough, especially with a short project and a small team, and if you have distinct learning objectives (you aren’t both trying to learn about coding, and you aren’t both being assessed on coding).
• If your project has stages or levels, you may be able to develop each stage separately. This division requires extra coordination when stages share behavior. It does not help much with a platform game whose levels differ only in the arrangement of walls and obstacles.
• During development, you can stub a component: replace it temporarily with a stand-in that is faster to build but does not yet have the required behavior, fit, or finish. Stubs let other components proceed before the final version is ready.
• Dividing a project into components is part of fabrication planning. Do enough planning to identify independent work, but expect the division to change as you build and learn more about the project.

Separating an Arduino Sketch

Thoughts on dividing the coding part of an Arduino project into pieces:

• If the sketch can be divided into pieces that use different physical components (different sensors and/or outputs), one student can work on the code that uses one sensor or output, and the other on code that uses another sensor or output
• You can simulate a sensor you don’t have by using a button. For example, if the device is supposed to run a fan in a certain way when the user waves their hands in front of a detector and you’re responsible for running the fan, make it happen when the sketch starts or when the user presses a button.
• You can simulate an output that you don’t have by using an LED. For example, if the device is supposed to run a fan when the user waves in front of a detector and you’re responsible for detecting the wave, flash the LED instead of running the fan.

Integration hell refers to the difficulty of getting separately developed pieces to work together. If you divide the work, combine the pieces early and often. Integration failure is the most common failure mode of a team project with separate components.

Dividing a project into pieces is useful even when you are not working remotely from your teammate. You can both work at the same time.

Dividing a project into pieces is also useful when you are working alone. You can develop and debug one part in isolation. There is less to build before you can test it, and fewer places to look when something goes wrong.

Collaborating on Code

Screen sharing

One way to collaborate on code is to work on the same code at the same time, by having it “live” on one person’s computer and sharing that computer with the other team member(s).

Zoom is good for one-way screen sharing (where one person shares their screen for the other person to see, but not control). Zoom implement two-way screen control as well, but on a slower connection it doesn’t work as well as…

https://screen.so lets both participants type while sharing control of a screen.

For Arduino code, the Tinkercad simulator probably makes it easier to collaborate.

Note: For web development there are other possibilities. So if you take a course such as Creative Coding that involves web development or server development, you will have the opportunity to use other collaboration tools that can work better than the ones described here.

Sending Code back and Forth

The other way to collaborate on code is to send lines of code or files back and forth.

Slack is particularly good at talking about code, as well as sending snippets of code back and forth. Surround a word by backticks to quote it as code e.g.function setup()`. Start a line with three backticks ``` to paste in a multi-line sketch or fragment of a sketch, to preserve its code formatting.

Git, GitHub, and GitHub Desktop automate this, so that it is easier to share new versions and to see what has changed since the previous version. They can be used with the Arduino and Processing IDEs. Although git is easier to use once a project has been set up with it (especially using GitHub Desktop), it is more difficult to set up a project so that you and your team members have access to it, and is beyond the scope of this course.