A journal for all Learners Guild Coaches to share their experiences and knowledge
###Priorities as a coach:
- MUST be a pair (or more) <-strict, never coach only one person, have they asked the other team?
- no overtime (don’t spend more than 30 min at a time with a group)
- if none are ready, and you have free time, review others reviews
- useful, actionable, specific feedback. Don't just point out what doesn't work, point out what works. Positivity
- if it’s juicy, too tough, flag SEP (software engineering practicioner)
- share resources (links) with everyone on echo, write blog post or create resource if a good one doesn’t exist. Cross pollinate knowledge (like bees)
identify problem, identity small subproblem
review
links, did well, good name clear specs, clean, challenging, tests?
coaching guide (github?, google doc?, git book) share with sheriff what makes a good code review?
Coaches be reviewing code
Coaches, if you're not actively helping a team, please be on top of code reviews in prrr. Claim them, review them. Practice reading other people's code and giving useful, actionable, specific feedback. Don't just point out what doesn't work, point out what works. Code style, naming, architecture, tests...etc. Make sure to review the specs.
ways to ask for help -detailed -general -drowning
Code review ideas: https://www.kevinlondon.com/2015/05/05/code-review-best-practices.html
Clean code ideas: https://github.com/ryanmcdermott/clean-code-javascript/blob/master/README.md
When reviewing pr's it may be useful to clone the repo to get a better feel for things and read/play with the code in atom