On Tue, Mar 8, 2011 at 6:12 PM, Peter Hosey <bore...@adium.im> wrote:
> On Mar 8, 2011, at 15:41:21, Andreas Monitzer wrote: > > I'm not that fluid in Adium's code any more, but I guess I could easily > find my way around again when a student needs some help. > > I won't be mentoring, but for any who will mentor for the first time, > here's a rough guide to what mentoring entails: > > - Work with students from the very beginning on the quality of their > submissions. 90% of the submissions will be crap. Look past this. See what > lies within. If it can be improved, try to get them to improve it. Those who > do will be good students. > - Spur your student to work on code. Make sure they're committing at a > regular and satisfactory rate. > - Ensure your student actually writes code and doesn't just crib together > tutorials and/or Stack Overflow answers and/or ask you to provide code* for > various tasks they need to accomplish. Wildly varying coding styles, > inconsistent variable and method naming, and poor indentation are warning > signs. > - Communicate constantly. This includes the aforementioned spurring your > student to work as well as being available to answer any questions they have > about where things are in our code base, what they need to do to achieve > certain goals or specific sub-tasks, etc. These questions are virtuous; you > should encourage them, just short of demanding them. The student is not that > only in name; they are here both to write code and to learn. > - Find a medium that works for both of you. For me, email (or Twitter, > nowadays) would be best. Maybe you prefer IM, or even voice chat/phone (if > it isn't too expensive). Don't try to force your habits on the student; if > you love the phone but they hate it (or vice versa), a happy medium will > work better. > - Be sure they understand and use Mercurial and good VCS practices > generally. Frequent, discrete commits; neither waiting “until it's done” to > commit (it should compile) nor committing half-done work periodically (e.g., > daily) nor committing amalgams of unrelated work (they should commit > specific sections that comprise a single change). > - Nowadays, I recommend that you have them fork our Bitbucket repo and push > to their fork. > - Review their code constantly. Subscribe to the commits list (or their > fork's commits feed) and review everything they write. > - Read their commit messages, not just their code. Lists are a warning sign > (unrelated changes lumped together). Inadequately describing the change is > also a problem. Work the student out of these habits as soon as possible. > - Don't wait until mid-term exams to sit your student down for a serious > talk about their work or lack thereof. If they're committing garbage, set > them straight as soon as possible—do not wait. If they don't commit, get > them writing and committing as soon as possible. > - Always be ready to fail your student. Be compassionate, understanding of > life's realities; they're not a slave. But they are here to work, and if > they don't do the job or if they do a bad job, be ready to fail them. > - Make sure they know where they stand. If there's 1–2 weeks before exams > and they're still in danger of failing, make sure they know what'll happen > if they don't shape up. > > I can't claim to have been perfect in all of these points in my own > mentoring (many of these I learned by *not* doing them), but it's what I've > found works. > > There might also be something on the GSoC topics about this. Some > viewpoints vary, particularly along the leniency-to-hardassness spectrum. > > *Six words that should worry every mentor or other help-offerer: “Can you > show me a sample?” > > > An excellent list in general. It may be worth putting onto a blog somewhere if you haven't already.
