<commit_before>---
topic: "WIP Mentor Overview"
desc: "Raw notes from J.C.--needs a reformat"
---

These are some raw notes from a document by <NAME>.   As time permits, these could be crafted into a more coherent guide for CS56 mentors.



# Team Leadership for Advanced Applications Programming

1. Expectations

 * _Be a team leader:_ On a base level, mentors are there to lead their student teams and resolve questions and conflicts. Mentors are responsible for reviewing the labs of the students they are mentoring.  

  * _Review legacy code projects:_ The bulk of code review comes from the legacy code projects, which mentors will prepare. Mentors and student teams should be in close contact regarding its progress throughout the quarter
  
  * _Provide meaningful feedback to mentees:_ Unlike TAs, readers, and professors, mentors do not evaluate the performance of the students in a quantifiable way. Mentor evaluations of student work take place in the form of code reviews when the mentors have the opportunity to provide meaningful feedback on student code and habits.
  
2. Take Away: 
   
   The main goals are to gain meaningful insight into working as a manager / scrum master while helping students learn about how to work on a project development team. It’s a learning environment for everyone involved, and at any point feel free to discuss anything with the other mentors, the mentor leader ( if there is one ), the TA(s), and especially with the professor. 

3. Duties:

  * Project manager / scrum master work duties:
  
    * Help Students plan sprints
    
    * Discuss with team their expectations and goals for the quarter
    
    * Check in with team frequently
    
    * Ensure plans are being followed and work with team to ensure they have all that they need ready to complete the work that session

  
```
Moderators / Mentors
Leadership
Project manager / scrum master work duties
Plan sprints
Discuss with team their expectations for the quarter
Check in with team frequently
Ensure plans are being followed and work with team to ensure they have all that they need ready to complete the work that session
Code reviews
Code reviews offer the students a chance to improve their coding practices and mentors a chance to practice analyzing code for performance and best practices for industry. As a team leader or project manager in the real world, a significant goal is to generate an efficient, working piece of code. 
Although the student may have created something that works, it may not be well implemented and now is the opportunity to inform the student of ways to improve upon their code. Separate from their grade in the course, this is a time to show them how their code would be evaluated in the real world, based on a given project specification (not a grading rubric). This means that even if they have working code that satisfies the lab requirements, there may still be room for improvement that they were unaware of.
Any evaluations of student work may be used by the TAs or reader to gain insight into the code for future grading, but the evaluation should be based on the purpose of the code, not the grading rubric.
Labs
Lab preparation
Look over labs material, be prepared to answer questions
Do the lab if unfamiliar with concepts due to not remembering material or have not done it before
Lab time
Arrive a little early if possible
Sit at the head of a row on furthest end of the lab by the windows
If you aren’t leading a row of students during a lab session, find a free seat near the front or back
Oversee team members throughout lab session
Check in with students first
Make sure they know what they need to be doing and any deliverables for the week
Students are given until the following week to complete a lab. This gives them an opportunity to ask any last minute questions about the previous week’s lab, but it should be mostly completed before the following lab session so they have ample time to ask any necessary questions for the next lab. 
Legacy Code Projects
Curation of previous repositories
Look through projects in organization
https://github.com/UCSB-CS56-Projects<commit_msg>Update WIP_mentor_overview.md<commit_after>---
topic: "WIP Mentor Overview"
desc: "Raw notes from J.C.--needs a reformat"
---

These are some raw notes from a document by <NAME>.   As time permits, these could be crafted into a more coherent guide for CS56 mentors.



# Team Leadership for Advanced Applications Programming

1. Expectations

 * _Be a team leader:_ On a base level, mentors are there to lead their student teams and resolve questions and conflicts. Mentors are responsible for reviewing the labs of the students they are mentoring.  

  * _Review legacy code projects:_ The bulk of code review comes from the legacy code projects, which mentors will prepare. Mentors and student teams should be in close contact regarding its progress throughout the quarter
  
  * _Provide meaningful feedback to mentees:_ Unlike TAs, readers, and professors, mentors do not evaluate the performance of the students in a quantifiable way. Mentor evaluations of student work take place in the form of code reviews when the mentors have the opportunity to provide meaningful feedback on student code and habits.
  
2. Take Away: 
   
   The main goals are to gain meaningful insight into working as a manager / scrum master while helping students learn about how to work on a project development team. It’s a learning environment for everyone involved, and at any point feel free to discuss anything with the other mentors, the mentor leader ( if there is one ), the TA(s), and especially with the professor. 

3. Duties:

  * Project manager / scrum master work duties:
  
    * Help Students plan sprints
    * Discuss with team their expectations and goals for the quarter   
    * Check in with team frequently   
    * Ensure plans are being followed and work with team to ensure they have all that they need ready to complete the work that session
   
  * Code reviews
  
    * Main goal is to help team improve
    * Review should be in depth.  Take the opportunity to inform the student of ways to improve upon their code. Show them how their code would be evaluated in the real world, based on a given project specification, not a grading rubric. This means that even if they have working code that satisfies the lab requirements, there may still be room for improvement that they were unaware of.
    * The evaluation should be based on the purpose of the code, not the grading rubric.
    * Secondary goal is to have a project that can continue to develop into something better.  
 * Lab preparation
    * Look over labs material, be prepared to answer questions
    * Do the lab if unfamiliar with concepts due to not remembering material or have not done it before
 * Lab time
Arrive a little early if possible
Sit at the head of a row on furthest end of the lab by the windows
If you aren’t leading a row of students during a lab session, find a free seat near the front or back and be available to help other teams
Oversee team members throughout lab session
Check in with students first
Make sure they know what they need to be doing and any deliverables for the week
Students are given until the following week to complete a lab. This gives them an opportunity to ask any last minute questions about the previous week’s lab.
Encourage them not to fall behind the previous lab should be mostly completed before. 
Legacy Code


  
```
Moderators / Mentors
Leadership
Project manager / scrum master work duties
Plan sprints
Discuss with team their expectations for the quarter
Check in with team frequently
Ensure plans are being followed and work with team to ensure they have all that they need ready to complete the work that session
Code reviews
Code reviews offer the students a chance to improve their coding practices and mentors a chance to practice analyzing code for performance and best practices for industry. As a team leader or project manager in the real world, a significant goal is to generate an efficient, working piece of code. 
Although the student may have created something that works, it may not be well implemented and now is the opportunity to inform the student of ways to improve upon their code. Separate from their grade in the course, this is a time to show them how their code would be evaluated in the real world, based on a given project specification (not a grading rubric). This means that even if they have working code that satisfies the lab requirements, there may still be room for improvement that they were unaware of.
Any evaluations of student work may be used by the TAs or reader to gain insight into the code for future grading, but the evaluation should be based on the purpose of the code, not the grading rubric.
Labs
Lab preparation
Look over labs material, be prepared to answer questions
Do the lab if unfamiliar with concepts due to not remembering material or have not done it before
Lab time
Arrive a little early if possible
Sit at the head of a row on furthest end of the lab by the windows
If you aren’t leading a row of students during a lab session, find a free seat near the front or back
Oversee team members throughout lab session
Check in with students first
Make sure they know what they need to be doing and any deliverables for the week
Students are given until the following week to complete a lab. This gives them an opportunity to ask any last minute questions about the previous week’s lab, but it should be mostly completed before the following lab session so they have ample time to ask any necessary questions for the next lab. 
Legacy Code Projects
Curation of previous repositories
Look through projects in organization
https://github.com/UCSB-CS56-Projects
{'fraction_non_alphanumeric': 0.02316562914583121, 'fraction_numerical': 0.0014287172160424534, 'mean_word_length': 4.096203848153926, 'pattern_counts': {'":': 0, '<': 5, '<?xml version=': 0, '>': 5, 'https://': 2, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '1981481', 'n_tokens_mistral': 2262, 'n_tokens_neox': 2147, 'n_words': 1609}