The Buddy System
We advocate a less sever form of Pair Programming: the Buddy System. In the Buddy System you will pair up with at least one other person to complete each of the course projects. Try buddying up with someone different every couple projects, especially if they're at a different level than you or have different strengths than you. When you've finished the project you were working on together, give each other a code review and your contract has ended.
Pair Programming is a well-defined dynamic with set roles and procedures. These roles work for some people, and can be very productive if both developers are more experienced. But we've found that in the initial phases of learning it can be a lot to follow these rules and figure out how everything works at the same time.
So if you're interested in trying out true Pair Programming, go for it! There is a good guide in the Resources section.
If you prefer to work more freely with your Buddy, go for it! Find a dynamic that works for both of you.
- Active Collaboration
- Teaching & Being Taught
- Planning & Coordination
- Code Reviews
- Static Code Analysis
- Create a code review template
- Pair up with a buddy or two and read/discuss through the code review articles.
- Create a new repository and call it something like "code-review-template"
- (Put it on your portfolio, like always)
- Turn the README into a generalized code review template you will use from now on
- If you have a few different ideas, make a few branches!
- Code Review:
- Code review each others' code review template repos using the process below.
- Work on each project with a buddy or two:
- How you work together or split up the project is your choice. There is no single best way to do this, it will depend on your strengths and personalities. What's important is that you are continuously engaging with another person while building these projects.
- Code Reviews:
- Requesting a code review:
- Create an issue in the repo you want reviewed
- Specify if you have any specific concerns with the code
- Mention whoever you'd like to take a look through your code (ie. @elewa-student)
- Giving a code review:
- Fork the repo you will be reviewing
- Create a new branch for your code review
- Read over their project, keeping an eye out for their specific concerns
- Read over their project, keeping an eye out for the three audiences:
- End Users
- Future Developers
- Runtime Environment
- Complete a code review template and include it in your fork
- Don't hesitate to make new branches in your c-r-t repo
- Every project is unique and your code reading is always improving
- Having a large library of code smells to look out for will be handy later
- Send a pull request to let them know you've finished
- Requesting a code review:
- Why Code Review?
- Review Smarter, Not Harder
- Thorough Guidelines
- Leveling Up
- Code Reviews with GitHub
Static Code Analyzers:
Living Study Buddies:
Inanimate Study Buddies:
Finding Buddies Online: