Mentorship program (virtual, 3-tier version maybe spearheaded by Andrew!)

General idea: regular one-on-one check-ins for advice and code reviews. Three tiers: the most experienced mentors would mentor more advanced learners, who in turn would mentor complete beginners.

For example: if one advanced mentor can mentor 3 people, and each of those 3 people mentor another 3 people, that way recommendations from the advanced mentor can be shared with all 12 people, plus individualized one-on-one help from their mid-level mentor.

Still need to work out details like timeline, application process, etc

@LearningNerd already made a good summary of how I'd like to approach this. Ultimately, this whole thing is an experiment and everyone is a guinea pig, including myself. I will be presenting this in the meeting tomorrow (in under 5 minutes!), but here's a more detailed breakdown of what I'm thinking:

Expectations

I will likely want to focus on web for now, though I'm certainly open to other types of software (desktop, mobile, IoT) later on. For the lead mentor, this is going to be the biggest challenge, balancing whatever languages/tools their direct mentees will be taking on. There will be a huge up-front cost (in time) for preparing the curriculum and gathering the first of the resources to start off.

Lead Mentor

Knowledgable enough to lead/direct projects, able to work in whatever language(s) direct mentees are comfortable in or ability to pick them up quickly enough to be helpful in project guidance, capacity to have meaningful one-on-one interactions, ability to provide constructive feedback and patience. May need to learn frameworks to guide projects, but may not be necessary (it's easy reading framework code/documentation without knowing the framework explicitly).

Direct Mentees (Mentor-Mentees)

To learn the full stack (if web), or at least have a basic understanding of a full application - from back end to front end. They should be coming in with at least a basic understanding of variable types (boolean, int, etc), control flow (if/else), loops (while/for), methods, classes/objects (this is what they will be teaching!); comfortable in at least one web language or able to pick it up easily enough and interested in learning a basic web framework. Also need to have the capacity and ability to work with new beginners. A full project will include a back-end, front-end, server setup and code version management (likely GitHub). There should be a project to show off by the end.

Fresh Mentees (Mentees)

No prior experience necessary, but time available to dedicate to learning is necessary. Will be covering the above mentioned stuff that's expected for direct mentees to already know.

Organization

Lead mentor => X mentor-mentees => X mentees per mentor-mentee

The idea here being that however many direct mentees a lead mentor will take on, those mentees should be able to take on just as many mentees themselves. Lead mentor should have weekly 1-on-1s with mentor-mentees as a "focus on this for the next week" and "what did you struggle with the past week" sort of thing - plus any resource exchange that might help. At the end of the week, a brief group meeting/review will occur for discussion on challenges with mentoring and we can collectively brainstorm on solutions. This process is then repeated between the mentor-mentees and their mentees, except the end-of-week review is done with those mentees and the lead mentor to have a full loop of feedback and interaction.

One-on-Ones

Each mentor should meet with their mentees at least once a week. This is to be used for their personal review and discussion on where they should focus or work on next. This is also where resources are provided for whatever task/project the mentee should be working on. This might need to be documented somewhere for any subsequent "cohort" of mentees. The lead mentor will likely need to provide resources for both direct mentees and their mentees that could be passed down through direct mentees.

Weekly Review

Collectively, the lead mentor should meet (possibly 30 minutes) with their direct mentees about how their respective mentorship is going and for any personal feedback about the mentorship process. This allows the group to brainstorm solutions together on the mentorship process.

The lead mentor should also have a weekly group meeting with all fresh level mentees on feedback about their mentorship and where improvement can occur. This can be especially helpful if any anonymous feedback needs to be passed on to mentor-mentees.

Project/Practice

This is more for those being mentored than the lead mentor, but this should - ideally - be a bulk of the week's commitment for all mentees. For direct mentees, this will be a project that is built in stages throughout the duration of the mentoring cycle (2-3 months?). For fresh mentees, this is practice problems.

Code Review

The lead mentor should be able to review all code being written by direct mentees and provide meaningful feedback. This will likely need to occur outside of the one-on-ones, it will be handled through pull requests. I might experiment with having direct mentees do a peer review of others' code, though I'm unsure about adding additional time commitments for them. At the very least, direct mentees should review code/assignments for their respective mentees. This could also apply to their mentees, having them review each others' code.

Commitment

X = # of mentor-mentees/mentees

	Lead	Mentor-Mentee	Mentee
One-on-One:	1 hr * X/wk	1 hr * X/wk + 1 hr/wk	1 hr/wk
Weekly Review:	1 hr/wk	0.5 hr/wk	0.5hr/wk
Project/Practice:	N/A	2+ hr/wk	3+ hr/wk
Code Review:	~4 hr/wk	0.5 hr/wk (?)	1 hr/wk (?)
TOTAL:	5 + 1X hr/wk	4 + 1X hr/wk	5.5 hr/wk

This means that, given 3 direct mentees, the expected weekly commitment of a lead mentor is 8 hr/wk. For mentor-mentees, that becomes 7 hr/wk; for fresh mentees, that remains static at ~5.5 hr/wk. For mentees (of both types), they're certainly welcome to invest more into their project/practice as this is just a minimum guideline. Anything more might place some extra burden on code review, though.

Other Notes

In a perfect world, everyone learns (including lead mentors!) and we can get people moving up in tiers. This means that fresh mentees will eventually become direct mentees then lead mentors. How long it takes for that to happen is unknown. Maybe 1-2 cycles at each stage? This is even assuming it's successful enough to have multiple cycles.

Any and all feedback/criticisms are welcome!

Edit: This will be an evolving process. If it seems 1hr/week for one-on-one is too much, it could be alternating weeks. Things can, and likely will, be tweaked as we go to find the right flow. Everyone will get to learn, everyone will get to grow, everyone will get to contribute.

Big 👍 for this post, thanks @x2adrew!! I hadn't realized how much you were envisioning this as a project-based mentorship thing, and now that I read it, I'm seeing it has a lot of overlap with other ideas our group has discussed on how to facilitate more ongoing team projects.

So, a couple of my initial thoughts:

What do you think about having your mentees work on a project together? Only if it's easy enough to find say 3 people around a similar skill level and interested in building the same project. The mentor could still meet with them individually but then the code review time and other overhead would be lessened, since you can sort of review all three mentee's code at the same time since they're building one project together.
Logistics note: we should definitely have a little application process, maybe just a Google form or similar with a few basic questions. Maybe also one pre-interview to make sure they're committed and just see how the conversational chemistry is between mentor/mentee?
Documentation / knowledge sharing: I'd really like to find a way to share the benefits of what we do with a wider circle of people! A couple ideas: blog posts that recap what the mentors and mentees learned? With permission, maybe record and share video chats for mentorship meetings? Plan at the start of each cycle that mentors/mentees will present at our next show-and-tell night if they're able to join?

Another big topic I'd like to bring up: sharing knowledge between mentors on how to be a good mentor! A big part of our leadership team in general, and with this mentorship idea especially, should be finding and sharing knowledge on more than just programming. Not sure exactly how, but I hope we can bake that into the very structure of our programs.

Also, that reminds me -- and this is getting into a tangent but I'm throwing it here for now. One person that comes to mind is Philip Guo, who I've exchanged a couple emails with a long time ago when I was starting Learn to Code LA and asking around for advice on teaching. He did his PhD on computer science education and built pythontutor.com and he's written about mentorship. For example, "Modeling programming knowledge for mentoring at scale" (which I'm sure I can get access to somehow without paying for the journal access). Anyway, hopefully we can tap into the existing knowledge from people like him to make sure we're aware of best practices on mentorship and teaching. :)

I'll add the following to my initial response, but here are my thoughts on everything you've said:

I was thinking about possibly having them work on the same project, but just different portions of it. I don't know how feasible this is at first, especially because of the likelihood that I may be taking on people from different language backgrounds. If I try to establish a common language among them, that may require a higher cost of investment on their part. As a beta program, I think it might be better to have a small project per person rather than trying to add the extra layer of cohesion right out of the gate.
Absolutely! My expectations guidelines are what an application process will be based on. There will be a code assessment and likely a brief interview (~15-30 minutes?).
I mention documentation under one-on-ones, but yes - I would love to document a lot of the process so that it's easily repeatable with minimal duplicated effort. Also, for knowledge-sharing.

As for the other info, thanks! I will look into what Dr. Guo has written about. I agree that mentor-sharing is important, but I want this to start off as a closed-system to begin with so I can see how many variables are shifting throughout.

This first run will very much be a beta (or even an alpha) of how to structure this type of learning. It's very much an experiment and I don't want to stretch it too far beyond the basic idea for now. Subsequent iterations will, hopefully, evolve more. I've already listed the end-of-week reviews for lead mentors to collaborate and brainstorm with their direct mentees, but if you're talking about mentors collaborating with other mentors - I hadn't thought about that.

I sort of assumed I'd be doing this solo to begin with. If others are willing to start with me, that's awesome, though I'd need to rework some things.

EDIT: @LearningNerd - I just realized that was an ACM link! I have a membership. :)

Throwing this in here for reference: the User Experience Professionals Association of LA (UXPALA) just started an online mentorship matchmaking program with a couple interesting ideas. The details are at https://docs.google.com/document/d/1cpgR24iU1GK3RRQcaBYXQmOnQfKkTyqVYvicX7RbltM/edit

Things of interest:

They're combining the online form/matching process with an optional in-person "mentorship speed networking session"
After the match is made, they check in with every mentor/mentee pair to see if it's working out. "If you are not sure if your match is a good fit for you, your details will go back into our database so we can find you another match."
The rest of it is very open-ended. I like @x2adrew's idea of focusing on projects and having a very specific goal and timeline better. :)

LearnTeachCode / leadership