This is a project to create a new curriculum for ScalaBridge. See the open issues for the outstanding tasks. Read on for the project goals, background, and ways to participate.
Our current curriculum is insufficient:
- it does not give students the skills they need; and
- it does not give mentors enough detail to deliver consistent teaching and effectively support teachers.
For ScalaBridge to achieve its goal we need to do better.
Our curriculum content should be guided by:
- the needs of our students;
- the expectations of employers; and
- our beliefs about what makes an effective curriculum.
My belief is the majority of our students fall into two groups: junior developers with some knowledge of Scala, and people with limited programming experience (sometimes none, sometimes they've completed a bootcamp or simliar) who are not currently employed as developers. The former want to advance their career. The latter want to switch to a programming career. We do often have more advanced students. They are difficult for us to serve: their more diverse backgrounds means it is difficult to form groups that have similar levels of knowledge. Given our limited resources I propose we don't serve advanced students at this point in time.
If the majority of our students are at an early career stage we should find out what employers prioritise in these developers and use this an input to our curriculum. This will likely involve domain specific knowledge such as web and database fundamentals.
In addition to core programming skills we should consider covering programming practices such as version control and testing.
Giving students the skills to advance their career in the short term (if that truly is a major goal) is important but we also need to consider their longer term prospects. Ideally we would weave in enough computer science fundamentals to bootstrap their own future learning. (I am not one of those who believe computer science is irrelevant to professional programming.)
I strongly believe in programming strategies for systematic program construction. We'll keep doing that.
There are many other resources to learn Scala (e.g. the various Coursera courses). If students come to ScalaBridge instead of using another option we must offer something they do not. A large part of this is our community: people to learn with, connections to employers, and support from mentors. This allows us to do things like peer learning that aren't so easy online. We can also (try) to do better in our curriculum.
Most existing courses use examples that relates to STEM subjects or simplified business applications. There is evidence from the "media computation" work that examples which connect to other domains (e.g. visual design, social science, biology) increase diversity. I feel we have already been successful with this to some extent with our use of Doodle, but we should extend this further into our curriculum and draw from a wider pool of examples. We should also cover examples that are relevant to employers. I expect it will work best to start with examples that connect to other domains and shift towards examples that connect to industry and CS fundamentals (though motivating CS fundamentals, such as algorithms, is likely to connect to other domains).
A spiral curriculum has worked for us in the past and I think we should continue to use that model.
If we run 3 seasons a year we have (3 * 6 * 2) = 36 contact hours per year, with perhaps (3 * 6 * 4) = 72 hours of time outside meetings (4 hours per fortnight) that we can reasonably ask students to dedicate to ScalaBridge. A typical university course has about 40 hours of contact time, so we can realistically achieve in a year roughly what a single University course can achieve in a semester.
The model liberal arts curriculum is a fairly minimal curriculum. It has a core sequence that covers three courses and 115 hours of class time. We clearly cannot emulate a University education in breadth and depth. We must focus on the core needs of our attendees, where they intersect with our goal of improving diversity within the Scala community.
Our open issues indicate what we're currently working on. We also have a mind map on Miro documenting the scope we're intending to cover.
Anyone is welcome to participate in the project, so long as they're prepared to operate within our code of conduct. Most discussion will take place within the Github issues and the ScalaBridge slack.