18F
Write document on mentorship pairing model
In order for the front end guild to potentially setup 1 on 1 mentorships, write a document that models how the mentorship could work.
Talk to @ccostino about how this could interface with his mentorship research
I decided to write about the mentorship between Elaine and I as a way to pull out a model for future internships.
Elaine and I were paired with each other by an engineering manager suggesting it and talking to us both about it.
We meet once every week at a specified time. Before our mentor ship started, I checked with Elaine to see what their goals and expectations of the mentorship were. Some of the general questions I wanted to get answered:
- What are your primary goals?
- Is it more the design side or the dev side of front end, or equally both?
- Any secondary goals?
- If you're planning on learning so-and-so language, what do you want to end up using it for?
- What experience do you already have in so-and-so language
- What do you enjoy? What parts of what you do now do you enjoy? What do you think you would enjoy?
From here, I learned Elaine wanted to learn more Javascript in front end developer as well as some more complex CSS.
We decided we could use the 18F site project and the data act to serve as projects to learn with. It helped to have actual projects to use for learning so work that went into mentorship coincided with Elaine's actual work.
Every Friday we would meet for an hour. Our meeting would usually consist of attempting a piece of work on one of the projects. At first, this was building a nodejs tool that could make requests to github and output the results in a csv file. We'd pair together to work on parts of the code. After the meeting, I'd often send Elaine an internet article on a subject for what we were going to work on next. So if we had to work on async web requests, I'd send an article on async in JS. We'd continue working this way until we complete things.
One thing that's worked very well is working on the 18F IRL site redesign. This project takes the old offsite site design and modifies it for the new IRL event. The offsite site is very simple, meaning changing it isn't very hard. This makes refactoring the code easy. It's also easy in that it doesn't have a hard schedule in terms of the work that has to be done. We're using the site to show how to refactor CSS code so it's in a component structure. Our workflow is:
- I create an issue describing a next piece of work, such as moving over a page to all components.
- The issue details some steps that have to be taken to complete
- Elaine works on the issue during the week before we meet
- We look at the work completed by Elaine, essentially doing a pair programmed code review
- We find the next piece of work to be down, write and issue, and potentially start to work on it.
Some weeks we'll go into more detail on a certain subject, such as look at an article and go through some examples. We also switch off on who drives while pair programming.