Skip to content

Instantly share code, notes, and snippets.

@jusrez

jusrez/DTR_guiding_questions.md

Forked from ericweissman/DTR_guiding_questions.md
Last active April 23, 2022 21:00
Show Gist options
  • Save jusrez/8b5d2e2fe5ab81bf5197ccd5dae7be7e to your computer and use it in GitHub Desktop.
Save jusrez/8b5d2e2fe5ab81bf5197ccd5dae7be7e to your computer and use it in GitHub Desktop.
Download ZIP
Raw
DTR_guiding_questions.md

CAREFULLY READ ALL THE INSTRUCTIONS BEFORE STARTING THESE EXERCISES!

To start this assignment:

  1. Click the button in the upper right-hand corner that says Fork. This is now your copy of the document.
  2. Click the Edit button when you're ready to start adding your answers.
  3. To save your work, click the green button in the bottom right-hand corner. You can always come back and re-edit your gist.

Purpose

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.

Words of Wisdom

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.

Collaboration Styles

  • 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-Navigator approach, 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)

Guiding Questions

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:

  1. How would you describe your preferred working style?
  • I'm personally a fan of the "Divide and Conquer" method, but I think that there's value in pair programming. Pair programming allows for you to identify and strengthen any weaknesses you or your partner may have and to develop trust in each other's abilities. It probably makes sense to transition over to Divide and Conquer once you've worked together closely on pair programming.
  1. What strengths do you bring to a team?
  • I like to be organized and overcommunicate to avoid any confusion/miscommunication. I'm also patient as I would hope others are patient with me if I don't understand something.
  1. How do you prefer to handle disagreements that come up? Trust me, they will come up!
  • Ask more questions. Disagreements are usually a result of misunderstanding. The more we understand one another and where we're coming from, the less we may have to disagree on.
  1. How do you communicate best? What tools do you need to communicate well with your teammates?
  • I think I communicate more clearly via asynchronous messaging (text,slack), but when I need to discuss something more complex it's easier to have face time via a call or in-person meeting.
  1. How do you prefer to make decisions as a team?
  • Everyone should feel good about the decisions we make. It's good practice to check in with everyone and make sure they understand why we're moving forward with a decision vs. just speaking over everyone and expecting them to get on board just because you feel good about it.
  1. What do you need (resources, environment, communication) to do your best work?
  • Open and clear communication with my team. I've seen many teams filled with really bright people fail to accomplish something because they couldn't communicate frequently and honestly. You can be kind and forthcoming at the same time. It's important to create that space for each other.
  1. What scheduling constraints do you have? What are your preferred work times outside of normal school hours?
  • No constraints on weekdays but would like to plan ahead if it's necessary to work on the weekends since that's when I plan to spend a majority of the day with family/friends.
  1. How do you prefer to receive feedback? How do you prefer to give feedback?
  • I would like (and hope) to receive honest feedback from instructors/classmates. I'm not easily offended and encourage people to speak to me in whatever way they feel is authentic and real to them.
  • I prefer to be honest with my feedback, but making sure to frame it in a way that's productive and not insulting or demoralizing.
  1. How do you want the group to solve problems when members run into blockers on the project?
  • Address a blocker or problems as soon as you can identify them. One of us might have hit that wall or experienced that problem before and may know how to guide someone else out of it. There's no point in struggling alone or thinking you're not good at what you do because you're experiencing difficulty.
  1. 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?
  • I'm moving back to NYC at the end of Mod 1 and selling my house here in Florida during Mod 1. I've already made arrangements to account for that, so I don't anticipate any issues BUT if something comes up, I'll be sure to set expectations with my teammates as soon as I anticipate them impacting my ability to pull my weight.
  1. 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?
  • I'd like to start any meetings by asking how everyone else is doing. It's good for morale, and it makes people feel seen. Sometimes just sharing your struggles can improve your outlook, which will in turn lead to better cohesion within the team (and better work!).
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment