pair programming rebrand

common-content/en/blocks/study-group/index.md

@@ -54,7 +54,7 @@ Pair programming is very common in industry so it's good to practice it now! Fin
 - Switch between driver and navigator roles after {{<timer>}}10{{</timer>}}
 - Don't dominate - this is teamwork
 
-There are further details in our [Pair Programming Guide](/guides/pair-programming/#drivernavigator-pair-programming).
+There are further details in our [Pair Programming Guide](/guides/pair-programming/).
 
 </details>
 

common-content/en/module/how-our-curriculum-works/dialogue/index.md

@@ -26,7 +26,7 @@ We learn best when we ask questions and explore possible answers. Dialogue is a
 - Presenters are expected to clearly and succinctly explain a topic or project.
 - The audience is expected to give useful constructive feedback.
 
-#### Mentored Pair programming
+#### Mentored coding
 
 - Learners are expected to explain their thought processes and understanding
 - Mentors are expected to ask questions and drive learners in the right direction
@@ -35,5 +35,3 @@ We learn best when we ask questions and explore possible answers. Dialogue is a
 
 - Drivers are expected to listen to their navigator and implement their directions
 - Navigators are expected to talk to their drivers and articulate their strategy
-
-

common-content/en/module/how-our-curriculum-works/no-lectures/index.md

@@ -14,4 +14,4 @@ We don’t lecture trainees during live sessions. We are not against lectures; i
 
 At {{<our-name>}} we have to _maximise the time we have together_, by working in person on projects, hitting blockers, and learning together. We are not a school. We are a community of professionals coming together to share skills and build real things to help people get real jobs inside one year.
 
-Time is very important at {{<our-name>}}. We try our best to use everyone's time as well as we can. We want to use our time together to help learners with the things they can't do at home: debugging, pair programming, code review, demos, and building projects.
+Time is very important at {{<our-name>}}. We try our best to use everyone's time as well as we can. We want to use our time together to help learners with the things they can't do at home: debugging, mentored coding, code review, demos, and building projects.

common-content/en/module/how-our-curriculum-works/tasks-and-ratios/index.md

@@ -29,7 +29,7 @@ The basic tasks are:
 - Afternoon study group. You can also do the following tasks during study group, or async online during the week:
   - [Code review](/itp/prs-needing-review): at least one per learner per sprint
   - [Step review](https://dashboard.codeyourfuture.io/): one per learner per module
-  - [Pair programming](/guides/pair-programming/): at least one per learner per module
+  - [Mentored coding](/guides/mentored-coding/): at least one per learner per module
   - [Demo](/guides/presenting/demoing/): attend at least one demo by a learner per module
 
 There are additional beneficial activities you can support learners with:

common-content/en/workshops/itp-ai-guidelines/index.md

@@ -16,7 +16,7 @@ Learning a new computing language is not a quick task, and software engineering
 
 Building understanding is why we:
 
-- Prioritise feedback at all times with demos, pair programming, mock interviews, and pull request code reviews etc.
+- Prioritise feedback at all times with demos, mentored coding, mock interviews, and pull request code reviews etc.
 - Avoid giving answers and instead ask more questions when you have blockers in your work.
 - Run [Checkpoint](https://curriculum.codeyourfuture.io/checkpoint/) before people can progress to [SDC](https://curriculum.codeyourfuture.io/sdc/).
 - Build up your knowledge from fundamental HTML+CSS, into JavaScript, and then into wider and deeper computer concepts in the SDC.

org-cyf-guides/content/employability/interview/common-issues/index.md

@@ -14,13 +14,13 @@ Every Tuesday evening and Friday morning CYF hosts demo/presentation practice se
 
 ## Problem solving / Turning ideas into code
 
-Mentored Pair Programming sessions are great ways to practice problem solving skills. They're organised in [#cyf-pair-programming on Slack](https://codeyourfutur-yov6609.slack.com/archives/C07PA66MQMC).
+Mentored Coding sessions are great ways to practice problem solving skills. They're organised in [#cyf-mentored-coding on Slack](https://codeyourfutur-yov6609.slack.com/archives/C07PA66MQMC).
 
 Trainees can also practice exercises on their own on [Codewars](https://www.codewars.com/) (which they should be used to). We strongly encourage people to make a plan, write it down, test it by hand with examples, then turn it into code.
 
 ## Code explanation
 
-Mentored Pair Programming sessions are great ways to practice code explanation skills. They're organised in [#cyf-pair-programming on Slack](https://codeyourfutur-yov6609.slack.com/archives/C07PA66MQMC).
+Mentored Coding sessions are great ways to practice code explanation skills. They're organised in [#cyf-mentored-coding on Slack](https://codeyourfutur-yov6609.slack.com/archives/C07PA66MQMC).
 
 ## CV tailoring
 
@@ -32,4 +32,4 @@ The weekly employability calls advertised in [#cyf-employment on Slack](https://
 
 ## English fluency
 
-See [Working on your English level](/improving-english).
+See [Working on your English level](/improving-english).

org-cyf-guides/content/mentored-coding/index.md

@@ -0,0 +1,70 @@
++++
+title = 'Mentored coding'
+description = 'Practice writing code and getting support'
++++
+
+Mentored coding is working on solving a coding problem with the mentorship of a volunteer or member of CYF staff.
+
+## Why
+
+Mentored coding is an excellent way to develop programming and communication skills.
+
+Coding mentors can provide feedback on trainees' code quality and problem solving approach.
+
+Mentored coding prepares our trainees for technical interviews when they'll code in front of other people and be expected to talk confidently and clearly about the code they are writing.
+
+## How
+
+We assign mentored coding as a coursework assignment throughout the course.
+Each session should last between 30-60 minutes.
+
+**Before** a mentored coding session, learners should decide what they're going to work on during it and share this with the volunteer, e.g. by sharing a link to a particular Codewars exercise, a particular piece of coursework, or some other problem.
+
+**During** mentored coding, the **learner** should:
+
+- **Explain** their thought process
+- **Break down** the problem
+- **Plan** what code to write
+- **Write** all of the code
+- **Check** that it works
+
+The **mentor** should:
+
+- **Ask questions** to get the trainee thinking. It's always better to _ask_ than tell.
+- Help the trainee think about breaking down the problem
+- Support the trainee if they encounter hurdles
+- Stretch the trainee by bringing up edge cases or complications
+
+## Arranging a session
+
+A **trainee** that wants to do mentored coding should:
+
+- Visit the `#cyf-mentored-coding` slack channel
+- Book a time using a mentor's calendar
+- If you do lots of mentored coding, try to book with different mentors to get more diverse help
+
+A **volunteer** that wants to be a coding mentor should:
+
+- Create a bookable calendar for 45-60 minute appointments, something like [Google Calendar](https://support.google.com/calendar/answer/10729749?hl=en) or [Calendly](https://calendly.com/integration#calendars) works well
+- Share your calendar in the `#cyf-mentored-coding` slack channel and canvas page (link at the top of the channel)
+- For your first mentored coding sessions, ask another mentor to shadow you to get feedback on your approach
+
+## Tips for learners
+
+When approaching a problem, you need to **explain your thought process**, **plan out what to do**, **write the code**, and **check that it works**.
+
+If you jump in to writing code without explaining your thinking, it will be more difficult for the mentor to offer you help.
+
+## Tips for mentors
+
+**The goal is teaching**: Rather than driver/navigator pair programming you may use in your work, where the goal is to produce code for a project, the goal of mentored coding is to teach a trainee how to become self sufficient when faced with a programming challenge. The **ultimate goal** of mentored coding is to get the trainee in a position where the next time they encounter a similar problem, they will be able to solve it better than they did this time.
+
+**Help people learn**: Most of the exercises the trainees are doing aren't useful in their own right. The point is for the trainee to learn and grow through them. Focus on understanding, and techniques that will help solve the next problem.
+
+**Don't take over!** It's important trainees get used to figuring things out. Provide guidance and assistance but trainees need to struggle to overcome any obstacles with understanding and technical communication. It can be uncomfortable to watch someone struggle, but make sure they've considered and tried all of their ideas before you intervene.
+
+**Give honest feedback**: Trainees can't develop if they don't receive honest feedback about their progress.
+
+**Ask questions!** Asking a clarifying question can help learners discover errors and often promotes more thoughtful responses. **Asking is better than telling.** Asking questions also helps to avoid long silences, and it can help push a trainee who is stuck and doesn't know how to proceed.
+
+**Encourage re-usable techniques**: Reinforce techniques like reading error messages carefully, looking up documentation, and thinking about edge cases. You might feel tempted to search for something on your own screen, instead ask the trainee to do it and this will help them learn the right kind of things to search for if they get stuck.

org-cyf-guides/content/pair-programming/index.md

@@ -1,89 +1,70 @@
 +++
 title = 'Pair programming'
-description = 'Practice writing code and getting support'
+description = 'Solving coding problems in a pair'
 +++
 
-Pair programming is working together with someone else to code a solution to a problem.
+Pair programming is working together with someone else to code a solution to a problem. It is a common industry practice and can be used effectively by engineers spanning all skill levels, not just as a learning tool but as a means of writing high quality, professional code.
 
-There are 2 main types of pair programming: Mentored and Driver/Navigator. At CYF you will use **Mentored Pair Programming** with volunteers, and you can do **Driver/Navigator** style when working with other trainees.
+As a CYF trainee you might find it useful when working in pairs on a project with another trainee, or trying to get past a blocker.
 
-## Why
-Pair programming is an excellent way to develop programming and communication skills.
+## The Driver and The Navigator
 
-It can be easier to work through a problem when working with someone 1-to-1.
+In a pair programming scenario, one person is the **driver** and the other is the **navigator**. Understanding the responsibilities of these roles and how to fulfil them is key to learning how to pair program productively.
 
-Pair programming prepares our trainees for technical interviews when they'll code in front of other people.
+### The Navigator
 
-## How
-You can do pair programming in person sharing one computer.
+The navigator is responsible for outlining the approach to solving the current problem. It's their job to provide high-level instructions to the driver about what to implement and to review the code that is written.
 
-You can also do it remotely:
-* By sharing your screen using a slack huddle
-* Scheduling a google meet, or similar online meeting
-* Using a VS Code extension like [CodeTogether](https://marketplace.visualstudio.com/items?itemName=genuitecllc.codetogether) or [Live Share](https://marketplace.visualstudio.com/items?itemName=MS-vsliveshare.vsliveshare).
+Tips for being a good navigator:
 
-A **trainee** that wants to do pair programming should:
-* Visit the `#cyf-pair-programming` slack channel
-* Book a time using a mentor's calendar
-* If you do lots of pair programming, try to book with different mentors to get more diverse help
+- Focus on the broader guidlines and avoid specifics, i.e. you should favour "we should loop through this array" rather than "you should write 'for' and then an opening bracket, then the `let` keyword...", unless the driver has asked for specifics
+- Listen and respond to questions or requests for clarification from the driver
+- Don't dominate; whilst it's your responsibility to guide the solution, you should still be open and receptive to suggestions from the driver
+- Resist temptation to write code, including avoiding sending code to the driver to be copied into the codebase
 
-A **mentor** that wants to do pair programming should:
-* Create a bookable calendar for 30 minute appointments, something like [Google Calendar](https://support.google.com/calendar/answer/10729749?hl=en) or [Calendly](https://calendly.com/integration#calendars) works well
-* Share your calendar in the `#cyf-pair-programming` slack channel and canvas page (link at the top of the channel)
-* For your first pair programming, ask another mentor to shadow you on your first call to get feedback on your approach
+### The Driver
 
-## Mentored Pair Programming
-We assign **mentored pair programming** as a coursework assignment throughout the course.
-Each session should last between 30-60 minutes.
+The driver is the one who is writing the code. They have their hands on the keyboard and are responsible for implementing the high-level instructions given to them by the navigator.
 
-**Before** a mentored pair programming session, learners should decide what they're going to pair on and share this with the volunteer, e.g. by sharing a link to a particular Codewars exercise, a particular piece of coursework, or some other problem.
+Tips for being a good driver:
 
-**During** mentored pair programming, the **learner** should:
-* **Explain** their thought process
-* **Break down** the problem
-* **Plan** what code to write
-* **Write** all of the code
-* **Check** that it works
+- Be willing to implement the navigator's suggestions, even if it might be different from how you would approach the solution
+- Feel free to offer suggestions and ideas, but respect that the navigator will make the final decision about approach in that moment
+- Don't be afraid to ask questions and engage the navigator in a discussion, especially when their instructions aren't fully clear to you
 
-The **mentor** should:
-* **Ask questions** to get the trainee thinking. It's always better to _ask_ than tell.
-* Help the trainee think about breaking down the problem
-* Support the trainee if they encounter hurdles
-* Stretch the trainee by bringing up edge cases or complications
+### Swapping Roles
 
-## Tips for learners
-When approaching a problem, you need to **explain your thought process**, **plan out what to do**, **write the code**, and **check that it works**.
+You should swap roles regularly. A good baseline to start from is:
 
-If you jump in to writing code without explaining your thinking, it will be more difficult for the mentor to offer you help.
+- Swap roles every 25 minutes
+- Each time you swap, take a 5 minute break
 
-## Tips for mentors
-**The goal is teaching**: Rather than driver/navigator programming you may use in your work, where the goal is to produce code for a project, the goal of mentored pair programming is to teach a trainee how to become self sufficient when faced with a programming challenge. The **ultimate goal** of mentored pair programming is to get the trainee in a position where the next time they encounter a similar problem, they will be able to solve it better than they did this time.
+## Why
 
-**Help people learn**: Most of the exercises the trainees are doing aren't useful in their own right. The point is for the trainee to learn and grow through them. Focus on understanding, and techniques that will help solve the next problem.
+There are lots of benefits to pair programming, including:
 
-**Don't take over!** It's important trainees get used to figuring things out. Provide guidance and assistance but trainees need to struggle to overcome any obstacles with understanding and technical communication. It can be uncomfortable to watch someone struggle, but make sure they've considered and tried all of their ideas before you intervene.
+- Live code review - there's always another programmer present to check the quality and robustness of the code being written
+- Faster debugging - a second person looking through the code can help speed up the process of catching bugs
+- Filling knowledge gaps - you can navigate your pair through a topic they're less familiar with, and vice versa
+- Learning - regular opportunities to learn from someone with different expertise
+- Developing communication skills - by definition, you're having to explain your approach clearly and succintly to someone else
 
-**Give honest feedback**: Trainees can't develop if they don't receive honest feedback about their progress.
+Can you think of any more?
 
-**Ask questions!** Asking a clarifying question can help learners discover errors and often promotes more thoughtful responses. **Asking is better than telling.** Asking questions also helps to avoid long silences, and it can help push a trainee who is stuck and doesn't know how to proceed.
+## How
 
-**Encourage re-usable techniques**: Reinforce techniques like reading error messages carefully, looking up documentation, and thinking about edge cases. You might feel tempted to search for something on your own screen, instead ask the trainee to do it and this will help them learn the right kind of things to search for if they get stuck.
+You can do pair programming in person by sharing one computer.
 
-## Driver/Navigator Pair Programming
-Driver/Navigator is a different model of pair programming.
-This is the style you would encounter in a workplace.
-As a CYF trainee you might find it useful when working in pairs on a project, or trying to get past a blocker.
-There is no single mentor offering support, instead you work together to solve a task.
+You can also do it remotely:
 
-It differs from the mentored style because both developers in the pair take turns coding:
-* One acts as the **driver** - using the keyboard to write code, following the navigator's suggestions.
-* One acts as the **navigator** - providing a high level plan of what to implement, and reviewing what is typed.
-* You swap every 10 minutes.
-* After you have both had a go, take a 5 minute break.
+- By sharing your screen using a slack huddle
+- Scheduling a Google Meet, or similar online meeting
+- Using a VS Code extension like [CodeTogether](https://marketplace.visualstudio.com/items?itemName=genuitecllc.codetogether) or [Live Share](https://marketplace.visualstudio.com/items?itemName=MS-vsliveshare.vsliveshare).
 
-You can do driver/navigator pair programming regardless of the levels of the pairs. Lots of people do this at work as software engineers. This is not just a learning tool, it is used to make professional code.
+## Extra Links
 
 You may find these links helpful if you want to learn more about the Driver/Navigator style:
-* [Tips for trainees pair programming together](https://www.csteachingtips.org/tips-pair-programming)
-* [Guidance on pair programming for learning](https://teachtogether.tech/en/#s:classroom-pair)
-* [More tips for pair programming](https://dev.to/documatic/pair-programming-best-practices-and-tools-154j)
+
+- [Tips for trainees pair programming together](https://www.csteachingtips.org/tips-pair-programming)
+- [Guidance on pair programming for learning](https://teachtogether.tech/en/#s:classroom-pair)
+- [More tips for pair programming](https://dev.to/documatic/pair-programming-best-practices-and-tools-154j)