Delivering a Technical Course to Busy Developers

At work, I'm experimenting with how to deliver a technical course to my fellow employees in such a way that participants succeed and our team doesn't have to put in too much time on top of our regular duties. Just making them available for self-directed study results in most folks poking in for an hour and never returning. If we can come up with the right delivery model, we can make all the courses we create for other purposes available to our colleagues without adding stress to our already busy schedules.

Many of our courses were designed for students in our work-integrated learning program first. Most material is curated with our own added context and assessment, and courses are intended to be completed in a self-directed manner. For our WIL students, we provide lots of feedback on their work and hold in-person sessions that range from formal tutorials to quizzes to pair programming assignments, all of which require quite a bit of time and attention from our education team.

I chose a Ruby programming course for my first experiment this summer since the majority of our development is with Ruby on Rails. I put together a series of short workshops previewing Ruby to our Dev Degree students and a more in-depth project-based course the same students took later on. The students spent two hours each on five workshops and about 20 hours a week for 3 weeks on the project.

I initially made the new course 8 weeks long, though we added a breather week partway through. Interested learners were asked to get lead buy-in, and were told they'd need to spend some time during work to succeed. I sent students some pre-learning resources both to set expectations of prerequisite knowledge, and to offer help for those who wanted to fill in any gaps. I recruited experienced Ruby developers as mentors who would answer questions, formally review project work, and run weekly tutorials using video conferencing software. Assignments were due each week, but with soft deadlines; getting an assignment in on time meant being paired up automatically for a peer review.

The course started with over 50 confirmed learners. Many have dropped off since, which isn't unexpected. Some realized that they didn't have enough problem-solving-oriented knowledge, and will likely take one of our intro to CS courses when the opportunity arises. Others found the everyday demands of their jobs made it difficult to keep up, and though there are exceptions, it seemed that once someone fell behind, they more often than not just stopped working on the course.

The course didn't end up being too demanding on my time, but it doesn't look like very many students will finish it. We wrap up next week, at which point I'll start to dig into who finished, who didn't, and why. I plan to have some anonymous surveys as well as focus group discussions. It will be really interesting to see whether we can find some tweaks that result in more success stories.

Have you ever tried to deliver a technical course to your colleagues? What did it look like? What structure worked well?