CAREFULLY READ ALL THE INSTRUCTIONS BEFORE STARTING THESE EXERCISES!
To start this assignment:
- Click the button in the upper right-hand corner that says Fork. This is now your copy of the document.
- Click the Edit button when you're ready to start adding your answers.
- To save your work, click the green button in the bottom right-hand corner. You can always come back and re-edit your gist.
You will be a contributor in several paired/group project throughout your Turing career working on complex technical challenges. You may be surprised to find out that < 1% of failing projects at Turing are due solely to technical definicines - in fact, the majority of failing projects are due to intrapersonal/team issues. In order to set yourself (and your teammates) up for success, it is critical to clearly communicate and set expectations with your teammates.
Before every project kickoff, we ask students to participate in a exercise known as Defining the Relationship (DTR), where you will work to set realistic expectations with your teammates around workflow, communication, etc.
However, prior starting Mod 1, it is crucial for you to reflect on what works for YOU! Obviously, this will change over the course of your Turing career as your learn more about your strengths and weaknesses, which is why this will be used as a living document.
As you work through this document, avoid the following pitfalls:
- "I'm flexible!" or "I'm down for whatever the group wants to do!"
- This is typically where problems start. You actually DO have preferences and opinions - it's better to communicate these from the get-go rather than have trouble come up later.
-
Pair Programming: This method involves working with your teammate(s) side-by-side/virtually on the same machine and writing code together. A common approach to this is to use a
Driver-Navigatorapproach, where one person is giving direction on what to type and why (Navigator) and on person is actually typing the syntax (Driver).- Benefits: reduces opportunities for missed communication, allows all team members to contribute, great for when all members are learning a new concept, allows for more natural brainstorming/sandboxing
- Considerations: more time consuming, more difficult to delegate tasks/features
-
Divide and Conquer: This method involves different team members each taking a small part of the feature/project to work on more independently and then rejoining at an agreed upon day/time to fit all the pieces together.
- Benefits: faster workflow than Pair Programmimg, easier to delegate tasks/features
- Considerations: requires excellent asynchronous communication, issues can arise when trying to combine features/work, more independent workflow (makes brainstorming/sandboxing more difficult)
For this initial exploration into what you bring to a team, try to avoid thinking about your TECHNICAL skills. Your answers to these questions should apply to any project/team that you work on:
How would you describe your preferred working style?
What strengths do you bring to a team?
How do you prefer to handle disagreements that come up? Trust me, they will come up!
How do you communicate best? What tools do you need to communicate well with your teammates?
How do you prefer to make decisions as a team?
What do you need (resources, environment, communication) to do your best work?
What scheduling constraints do you have? What are your preferred work times outside of normal school hours?
How do you prefer to receive feedback? How do you prefer to give feedback?
How do you want the group to solve problems when members run into blockers on the project?
What are some potential life things that could affect your ability to focus, and what plan can you come up with to approach those moments?
Quarantine is tough, so it’s important to make note of our mental/emotional state when working with others. How can we make space to check in on each other’s well being, in addition to the work that needs to be done?