I'm writing down my thoughts after a discussion with @gregmcintyre and others at RailsCamp Sydney regarding how to help newbies get more out of RailsCamp, and other events (eg. DevHub). 'Newbies' mainly refers to people who have had a basic intro through something like InstallFest, Rails Girls, or General Assembly, and are wondering what to do next. They may or may not have prior (non-ruby) programming experience.
The two main events I'm talking about improving are RailsCamp, and DevHub - both opportunities for newbies to get help from more experienced devs and get over the 'newbie hump'. However, the ideas are probably relevant to all kinds of potential events.
What doesn't work now
Events are very free-form and unstructured; people do whatever they want. Experienced devs float around, sometimes wanting to mentor, sometimes preferring to just hang out (and fair enough). Newbies wander about, with varying degrees of purpose, self-assuredness and direction.
Newbies aren't always sure who wants to help them, or who will be best to help with what. Furthermore, newbies often aren't sure what they really want to know, or what they should try to learn next - apart from 'all the things'.
More structure, or at least, the option to take part in something more structured, would help.
Too much structure won't work
Developing a brilliant 10 - 15 hour, 10-step course is useless in this situation. The following restrictions need to be kept in mind:
RailsCamp Restrictions
- No one will want to be in a structured environment the whole camp
- Both mentors and newbies can't be relied upon to turn up to any given session (warewolf may start at any time!)
- Having attended one session, people (both mentors and newbies) can't be relied upon to turn up to a follow-up one.
- Most people won't want to work hard for more than an hour or two at a time.
- A mentor / newbie pair may not click, and both mentor and newbie are potentially unreliable. Therefore people shouldn't commit to an official 'mentor relationship' up front (or even at all?)
- People (both mentors and newbies) will be of VERY varying degrees of ability. (Therefore referring to 'mentors' and 'newbies' is kind of stupid, but whatever.)
- Overall, we can't depend on any level of reliability, commitment, or willingness to prepare in advance, both from potential mentors, or from newbies.
- Overall, we can depend on a time commitment (from mentors and newbies) of around 1-2 hours, made on the spot, or maybe half an hour in advance.
Dev Hub Restrictions
You'll have much the same issues. People (both mentors and newbies) can't commit to attend a given dev hub ahead of time. And they certainly can't commit to coming to two in a row, ahead of time. If they do attend a dev hub, they can't be relied upon to commit to doing something structured. The current free-form format might suit them for that day.
The Solution Is…
I think the solution is to offer these things which, for lack of a better term, I'm just going to call courses. No… MiniCourses. Wait… no… MicroCourses. They're courses, but they're micro. A MicroCourse should fit most of the following criteria, to whatever extent possible (I've made up a few words here, but whatevs):
- Short. It (or at least a self-contained chunk of it) can be done in an hour or two
- Discrete / self-contained. Ideally it should have minimal dependencies in terms of prior experience / assumed knowledge
- Practical. It has some useful lesson or take-home
- Adaptable. It can easily be adapted, on the fly, to varying levels of ability, from total coding beginner through to intermediate. (Perhaps courses have some 'advanced excercies' at the end or something)
- Impromtuable. It can be picked up by an intermediate to experienced dev, and taught impromptu, without more than a few minutes preparation.
- Small-groupable. It is suitable for a 1-1 environment, or a small group (eg. 4-5 people of relatively similar ability)
- Pass-on-able. Once a beginner has taken a MicroCourse, it would be awesome if they could teach, or at least assist in teaching, a future session of that MicroCourse.
- A4-pageable. A MicroCourse curriculum should be printable on 1-2 sheets of A4 paper. Possibly a GitHub repo with sample code / starting point code / final solutions accompanies the printed curriculum.
I also think a MicroCourse should have:
- a brief eg. 5 min introduction (the teacher gives an overview of the topic)
- Most of the time spent hand-on, writing code, free-flowing Q & A, etc.
- a 5 min wrap-up covering next steps / optional homework tasks / how to learn more about the topic.
- (possibly?) an anonymous feedback form for improving future MicroCourses
Sample MicroCourse Titles
MicroCourse might be things like:
- Basics of Git (Why use a VCS? git init, staging, commiting, git gui's - install sourcetree)
- Intermediate Git (branching, merging, resolving conflicts, rebasing, interactive rebasing)
- Recursion for Beginners (code, Fibonacci numbers, and other fun patterns)
- ATM - Beginners guide to programming a basic ruby ATM. (as in, the things you get cash out of)
- Ruby Warrior - Coding Artificial Intelligence for Complete Beginners
- Ruby Koans - Learning basic ruby syntax and cool features
- Beginners Guide to Variable Scope (parametes, instance vars, local vars, class vars)
-
| do |
teach |
end - A beginners guide to procs, blocks and lambdas |
- Making your first Rails Helper
- InstallFest blog - adding categories to posts
- Ruby syntactic sugar (examples of common shortcuts, and what's really going on)
- Introduction to Rails Migrations (why they're needed, how they work, why they're timestamped, rake related tasks, how the databse knows what migration it's up to, etc)
- A kind of special case MicroCourse might just be "1 hour of one-on-one mentoring / pair programming with whatever you're working on". So, it's just a formal opportunity for a newbie to pair up. You'd have to be careful with this option, because I think a lot of people would choose it thinking it's best for them, when in fact a more structured basic course would be better. Maybe only offer this option in the afternoons, not the mornings, or something like that.
How they'd fit in to Rails Camp
At a RailsCamp, there might be 10 or so MicroCourses, just printed on sheets of paper. Someone announces: "Those who want to take, or teach, a MicroCourse, meet here after breakfast." Some may have MicroCourses they're keen to teach; some might have mico-courses they're keen to take. Down the track, some may even have MicroCourses that they've prepared themselves, that they're keen to try out. A facilitator helps connect teachers with learners. They pair up for an hour or two, and finish the course.
At a Rails Camp, there might be MicroCourse meetups twice per day - eg. at 10am and 3pm. So a newbie could potentially take 4 MicroCourses in a weekend.
MicroCourses also provide the opportunity for people to meet, and for an informal, ongoing mentoring relationship to organically form.