By Noel Welsh on 31 Jul 2019

In an earlier post I described our first run of ScalaBridge London. Now I want to turn to the future and talk about lessons learned and what we’re planning for the next run. Some of these plans are more concrete than others. One of the great things about ScalaBridge is we’re learning as we do it, and almost everything is subject to change.

The Two-Year Master Plan

To quickly recap, at the beginning of the year we ran six ScalaBridge sessions over twelve weeks. It was clear to me that our students made good progress, but equally clear that most would need more time to really learn the language. I want to run ScalaBridge London for two years, and see what our results are like after that. I think two years is enough time to cover a significant chunk of material at our meetings and a lot of time for independent practice.

The On-Season and the Off-Season

ScalaBridge London is a lot of work for everyone involved, and this includes the students. We need breaks to catch up with life but I think there is real value is regular (weekly or fortnightly) meetings. Frequent meetings keep enthusiasm high and forgetting low. If we were a school we’d have semesters and holidays. I want a similar model, but I don’t want to completely go on holiday when we’re not going 100%. Hence the on-season and off-season.

During the on-season we’ll have regular meetings and during the off-season we’ll have occasional meetings. The next on-season will start in September 2019, and I’d like to experiment with weekly meetings. Last time we had lots of absences due to holidays and so on, and I think having a shorter on-season would allow us to arrange the schedule to avoid the main breaks. However once a week might be too frequent; I don’t really know and it’s something we’ll have to experiment with. I think the six session block still works well. For one thing, it’s basically the same as the school calendar which means our seasons should in theory fit around school holidays. Meeting once a month is the goal for the off-season, and here our meetings will be more relaxed, giving time for more socialising. However I think we’ll still need some structure for the meetings. I’m not sure exactly what we’ll do. This is something to think (and experiment) about. First my first thought is to go with an “unconference” structure, where participants suggest topics.

Groups and Curriculum

Last time the groups didn’t work so well. Groups broke apart when people dropped out or progressed at different rates. I’m not sure what to do here. One possibility is to change the structure as follows:

  • students develop a learning plan of topics at the first session;
  • each week a mentor or group of mentors is responsible for a given topic;
  • each week students assign themselves to a topic that is either the next step on their learning plan, or their current topic if they feel they have not mastered the material yet.

This is very similar to mastery learning. There are two issues I see here. Firstly we may lose the effects of peer learning if we don’t have groups staying together—but we didn’t have that in the first place in many cases. The second issue is the work needed to formally map out the curriculum, and train the mentors in it.

On the subject of curriculum it’s clear that there are a lot of useful things we could cover that we don’t currently teach. I divide these into three groups:

  • tool usage, such as SBT and test frameworks;
  • larger projects that show programming techniques in context; and
  • data science, which is often a different kind of programming (i.e. Spark) to the more typical web services.

For all of these we can take some material from the Inner Product / Underscore training vaults, but the material is not as well developed as our core material (which is mostly in our books). We could develop this material but I know it’s a lot of work create high quality material.

So these issues are something I feel we should do something about but I’m not sure what is feasible. More feedback and experimentation is required.

Be Intentional

I definitely want to be more intentional in the practices we use to teach the students. This means giving the mentors specific techniques to use when teaching, practicing those techniques, and reinforcing them during our on-season.

Why do this? I know from my own experience, and from the literature, that how we teach can make a big impact on how effective teaching is. Furthermore, we can’t improve unless we understand what we are currently doing.

Evaluation

To improve we need to measure progress. This is where I run into problems. ScalaBridge London is not a course that has definite goals. We’re not trying to get people hired to use Scala, for example, though this could certainly happen. Instead, we’re trying to give the students the opportunity to do what they want to do with Scala. This could be getting a job, and in many cases it is, but it could also be learning for fun or to tackle a specific project, for example. We also need to support more than just learning Scala. To get a job we can do introductions to potential employers, coach people for interviews, and all that sort of thing. We also want to provide a network as we known that having a strong professional network has a huge influence on career.

All this means there isn’t a one thing we can measure that will tell us if we’ve succeeded. We can’t, for instance, measure employment rates like many bootcamps do.

At this point I feel like I’m out of my depth. My best guess is the most useful measure would be changes in our students’ attitudes over time. Do they feel more competent and capable at the end of the on-season, for instance? To me it feels like this problem needs tools from sociology and qualitative research techniques. I don’t have any background here. If you have ideas please send them my way!

Finally, I think what we’re doing at ScalaBridge London is quite unique, and if we can present what we’ve done and what we’ve learned in a coherent way we can extend our reach outside of London. I want to do that.