Curriculum Pacing for Beginners

[Sean Corfield]

As noted before, the morning seems to go fairly well for beginners. San Francisco decided to break up some of the early modules and interleave them to add some variety and that also went well. The functions module has the potential to confuse as we get into higher order functions but it seems that beginners take to those better than some of us expected and they cause more problems for experienced developers coming from an OOP background.

Where we seem to lose our beginners is in the afternoon as we either dig too deep into functions or we move into flow control and logic. Then we try to move into building an application and it gets overwhelming for many - there's a lot of machinery.

So, assuming we're tailoring the curriculum for just beginners at this point, what can we do to make the learning curve more even across the whole day?

Minneapolis's approach of weaving an application into all of the modules seems very promising (exactly what application and how to structure it can be discussed in a separate thread). I got the impression from the Minneapolis team that the only reason their schedule went off the rails was because they went off script in the Functions module and did a bit of a deep dive?

Overall, do folks think the shift started by SF to interleave the module content is positive? It's reflected in the current curriculum here:

https://github.com/ClojureBridge/curriculum

Similarly, do folks think trying to interleave the application throughout the entire day is a step in the right direction? As reflected in the Minneapolis agenda:

https://github.com/clojurebridge-minneapolis/organizing/blob/master/doc/agenda.pdf

Does anyone feel the morning is too slow for beginners? (SF had only 2 or 3 real beginners, MN seemed to have a much larger mix of beginners and is probably better placed to answer this?)

What sort of things can we do to even out the learning curve?

Considering the application aspects of the curriculum, there's clearly a lot of machinery involved (esp. if we really try to get a web app deployed on Heroku). If our focus really is to teach Clojure basics, how can we make the introduction of Leiningen and the project structure more seamless - at SF it seemed to be a sudden wall of complexity with project.clj, dependencies, src tree, test tree (which I think we simply ignored?) and so on...

Sean Corfield -- http://clojurebridge.org

"ClojureBridge aims to increase diversity within the Clojure community by
offering free, beginner-friendly Clojure programming workshops for women."

[Bridget Hillyer]

On Saturday, May 24, 2014 8:52:58 PM UTC-4, Sean Corfield wrote:

As noted before, the morning seems to go fairly well for beginners. San Francisco decided to break up some of the early modules and interleave them to add some variety and that also went well. The functions module has the potential to confuse as we get into higher order functions but it seems that beginners take to those better than some of us expected and they cause more problems for experienced developers coming from an OOP background.

Where we seem to lose our beginners is in the afternoon as we either dig too deep into functions or we move into flow control and logic. Then we try to move into building an application and it gets overwhelming for many - there's a lot of machinery.

So, assuming we're tailoring the curriculum for just beginners at this point, what can we do to make the learning curve more even across the whole day?

The function module seems to be where things go off the rails a bit. The material that is there is good, but I think it is missing discussion of some underlying concepts that beginners don't know about. So I don't think we need to change it, but I do think we need to add something.  That something is the concept of function argument binding. To anyone with experience programming, this is almost obvious. To complete beginners, it is not clear.  

My favorite treatment of this topic in Clojure is Kyle's treatment of the subject:

http://aphyr.com/posts/303-clojure-from-the-ground-up-functions

I really like the way he builds up from let bindings to functions. I don't know that we need to use his approach, but I think we could be inspired by it.

So am I off-base here? Is there something else in the curriculum (besides the app - that's another topic) that is problematic?

Bridget

[Sean Corfield]

On Jun 9, 2014, at 2:05 PM, Bridget Hillyer <bridget...@gmail.com> wrote:

My favorite treatment of this topic in Clojure is Kyle's treatment of the subject:

http://aphyr.com/posts/303-clojure-from-the-ground-up-functions

I really like the way he builds up from let bindings to functions. I don't know that we need to use his approach, but I think we could be inspired by it.

I found that a very interesting approach - Kyle had pointed me at that when we were discussing some of the curriculum material during the (second) teacher training for San Francisco.

What do folks think about introducing `let` before defining functions? Or do folks have other suggestions to make the functions section run more smoothly for students?

[Sean Corfield]

On Jun 9, 2014, at 2:05 PM, Bridget Hillyer <bridget...@gmail.com> wrote:

So am I off-base here? Is there something else in the curriculum (besides the app - that's another topic) that is problematic?

FWIW, I don't recall San Francisco running into problems with anything specific, except the infrastructure / boilerplate around the application (which I think can be addressed by weaving the application into the curriculum more thoroughly so students create and run a very basic application during the first module perhaps?).