Team Collaboration

Version Control with Git

Git is essential for team programming. It tracks changes, prevents conflicts, and lets multiple people work on code simultaneously.

Basic Git Workflow

# 1. Pull latest changes before starting work
git pull

# 2. Make your changes to the code

# 3. Check what you changed
git status
git diff

# 4. Stage your changes
git add .

# 5. Commit with a descriptive message
git commit -m "Add autonomous red left path"

# 6. Push to remote repository
git push

Commit Messages

Write clear commit messages that explain what and why:

Good commit messages:

Add encoder-based drivetrain movement

Implement autonomous red left side path
- Drive to specimen scoring zone
- Score preloaded specimen
- Park in ascent zone

Fix arm motor direction (was reversed)

Update TRACK_WIDTH calibration to 14.52 inches

Bad commit messages:

update
fixed stuff
changes
test
asdfasdf

Format:

First line: Brief summary (50 chars or less)
Blank line
Detailed description if needed (what changed and why)

Branching Strategy

Use branches to keep main code stable:

# Create a new branch for your feature
git checkout -b feature/autonomous-scoring

# Work on your changes
# ... edit files ...

# Commit your work
git add .
git commit -m "Add autonomous scoring logic"

# Push your branch
git push -u origin feature/autonomous-scoring

# When ready, merge back to main
git checkout main
git merge feature/autonomous-scoring

Branch naming conventions:

feature/description - New features
fix/description - Bug fixes
test/description - Experimental code
docs/description - Documentation updates

What to Commit

Do commit:

Source code (.java, .kt files)
Configuration files
Documentation (README.md, comments)
Build files (build.gradle)

Don't commit:

Build outputs (.apk, .class files)
IDE settings (.idea/, .vscode/)
Personal configurations
Large binary files (videos, CAD files)

Use .gitignore:

# Build outputs
build/
*.apk
*.class

# IDE files
.idea/
.vscode/
*.iml

# OS files
.DS_Store
Thumbs.db

# Personal notes
PERSONAL_NOTES.txt

Code Reviews

Code reviews catch bugs and spread knowledge across the team.

Before Submitting Code

Self-review checklist:

Does it compile without errors?
Did you test it on the robot?
Are variable names clear?
Did you remove debug statements?
Is the code formatted consistently?
Did you add comments for complex logic?

Reviewing Someone Else's Code

What to look for:

Logic errors or edge cases
Potential performance issues
Code clarity and readability
Consistency with team conventions
Missing error handling

Good review comments:

"What happens if the sensor returns null here?"

"Consider extracting these 20 lines into a separate method
called calculateArmPower() for clarity."

"Nice solution! One suggestion: using a constant instead of 0.8
would make this more maintainable."

"This looks good. Did you test it with the actual robot?"

Bad review comments:

"This is wrong."
"Why did you do it this way?"
"I would have done it differently."
"This code is bad."

Be constructive:

Point out what's good, not just problems
Suggest improvements, don't just critique
Ask questions instead of making demands
Remember you're reviewing code, not the person

Pair Programming

Two programmers, one computer:

Driver (keyboard):

Types the code
Focuses on tactical implementation
Asks questions when stuck

Navigator (thinking):

Reviews code as it's written
Thinks about strategy and approach
Spots mistakes early
Looks up documentation

Benefits:

Catch bugs immediately
Share knowledge between programmers
Onboard new team members faster
Higher code quality

Tips:

Switch roles every 20-30 minutes
Communicate constantly
Navigator shouldn't micromanage ("type this...")
Both should understand the code being written

Communication

Code Comments for Teammates

Leave helpful comments when your code affects others:

// TODO: @Sarah - Need your help calibrating this value
private static final double STRAFE_COEFFICIENT = 1.1;

// NOTE: This assumes the arm is in travel position. 
// Make sure autonomous calls arm.moveToTravel() first.
public void startIntake() {
    // ...
}

// BREAKING CHANGE: Renamed driveDistance() to driveForward()
// Update all autonomous OpModes to use new name
@Deprecated
public void driveDistance(double inches) {
    driveForward(inches);
}

Slack/Discord/Teams

Keep team communication organized:

Channels:

#programming - Code questions and discussions
#robot - Hardware and mechanical updates
#competition - Event schedules and planning
#general - Everything else

When to use chat vs. in-person:

Chat: Quick questions, sharing links/code snippets
In-person: Complex debugging, design decisions, teaching

Pin important messages:

Drive station login
Robot configuration names
Competition schedule
Calibration values

Documentation

Keep a programming notebook or wiki:

Document:

Calibration procedures and values
Known bugs and workarounds
Testing procedures
Robot capabilities and limitations
Design decisions and why

Example entries:

## 2025-02-10: Track Width Calibration

Performed 10-rotation test with new mecanum wheels.
Robot rotated 10 times, measured 359.5 inches traveled.

Calculation:
- Circumference = 359.5 / 10 = 35.95"
- Track width = 35.95 / π = 11.44"

Updated Constants.TRACK_WIDTH to 11.44

## 2025-02-08: Color Sensor Issue

REV Color Sensor V3 occasionally returns 0 for all RGB values.
Workaround: Read sensor twice, discard first reading.
See commit a3d5f2e for implementation.

TODO: Contact REV support about this issue.

Handling Conflicts

Merge Conflicts

When two people edit the same code:

<<<<<<< HEAD
motor.setPower(0.8);
=======
motor.setPower(0.6);
>>>>>>> feature/slower-arm

To resolve:

Discuss with your teammate which version is correct
Edit the file to keep the right code
Remove the conflict markers (<<<<, ====, >>>>)
Test that it works
Commit the resolved conflict

# After manually fixing conflicts
git add .
git commit -m "Resolve merge conflict in arm power"
git push

Code Conflicts

When you disagree on implementation:

Good approach:

Explain your reasoning
Ask questions to understand their perspective
Test both approaches if possible
Involve a mentor or lead programmer
Focus on what's best for the robot, not who's right

Example discussion:

Programmer A: "I think we should use PID for the arm."
Programmer B: "I think we should just use RUN_TO_POSITION."

A: "Why do you prefer RUN_TO_POSITION?"
B: "It's simpler and we understand it better."
A: "That's fair. But PID gives us more control over speed."

Together: "Let's try both and see which performs better in testing."

Onboarding New Team Members

Help new programmers get started:

Setup Checklist

## New Programmer Onboarding

- [ ] Install Android Studio
- [ ] Clone team repository from GitHub
- [ ] Set up Driver Station on laptop
- [ ] Connect to robot Control Hub
- [ ] Run a simple TeleOp to verify setup
- [ ] Read team coding conventions document
- [ ] Complete FTC tutorial OpModes
- [ ] Shadow experienced programmer for a meeting
- [ ] Make first code contribution (with review)

Starter Tasks

Give new programmers manageable tasks:

Good first tasks:

Add telemetry display for a sensor
Adjust a constant value (motor power, servo position)
Create a test OpMode for a single motor
Add a new button binding to TeleOp
Document an existing function

Not good first tasks:

Rewrite entire autonomous system
Implement complex path following
Debug intermittent hardware issues
Refactor subsystem architecture

Mentoring

As a mentor:

Pair program to demonstrate workflow
Explain your thought process out loud
Let them drive (type) while you guide
Answer questions patiently
Review their code quickly
Celebrate their progress

As a new programmer:

Ask questions when stuck
Take notes on setup and processes
Read existing code to learn patterns
Test your changes thoroughly
Don't be afraid to make mistakes
Contribute ideas even as a beginner

Competition Day Best Practices

Before Competition

Code freeze:

No major changes 1-2 days before competition
Only critical bug fixes
Test everything thoroughly

Pre-competition checklist:

- [ ] All code committed and pushed
- [ ] Robot configuration matches code
- [ ] Autonomous modes tested
- [ ] TeleOp controls verified
- [ ] Bring backup laptop with code
- [ ] Charge all batteries
- [ ] Print driver controls diagram

During Competition

Match preparation:

Don't modify code between matches unless critical bug
Keep laptop charged and ready
Have backup phone/tablet with Driver Station
Document any issues that occur

If something breaks:

Stay calm
Identify the problem clearly
Make minimal changes
Test before next match
Have a rollback plan

Division of labor:

One programmer monitors robot during matches
One programmer ready to debug if needed
Don't have 5 people crowded around one laptop

Quick Tips

Do:

Pull before you start working
Commit working code frequently
Write descriptive commit messages
Test your changes on the robot
Communicate with your team
Review code before pushing
Ask for help when stuck

Don't:

Commit broken code
Force push to main branch
Ignore merge conflicts
Make major changes right before competition
Work on the same file simultaneously without coordination
Delete someone else's code without asking
Blame teammates for bugs

Next Steps

Review all the principles in this section by returning to the Introduction.

You now have the foundations for writing clean, collaborative FTC robot code!