Skip to content

Instantly share code, notes, and snippets.

@julien-truffaut
Last active December 18, 2019 14:08
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save julien-truffaut/9bed85ed4bb61211ffbf91ac90d2ac42 to your computer and use it in GitHub Desktop.
Save julien-truffaut/9bed85ed4bb61211ffbf91ac90d2ac42 to your computer and use it in GitHub Desktop.
What I learnt writing a functional programming course

Around a year ago, I started working on one of my most significant projects: a functional programming training course. As the year ends, it is a good time for introspection. In this post, I will analyse what worked out and what didn't. Hopefully, my experience can help other people who intend to prepare and run workshops.

Summary

The course is called Foundation, and all the content is available on GitHub at https://github.com/fp-tower/foundation. It contains four modules that roughly take 4-5 hours to go through. I wrote two additional modules which require a more experienced audience in functional programming, so I moved them to another repository https://github.com/fp-tower/abstraction.

At the moment I am writing this article, I run the course seven times using various configurations: monthly 2-hour workshop, 2-day course (consecutive days or not), on-site or remote.

What I did wrong

I will start each section with an advise I would have liked to receive. Then, I will explain the mistakes I made and how I tried to fix them.

  1. Break your content in pieces and make it coherent. I spent 3-4 years thinking about doing a functional programming course. I started multiple times, but I always abandoned quickly. I wanted to talk about a bunch of topics, but no connections between them. It is only at the beginning of 2019 I had the idea to first explain the basic building blocks of functional programming (function, types and typeclasses) and then move to concrete applications (error handling, side effect/IO, reader/state). I only found the motivation to work on my course when I had a coherent narrative between the pieces.
  2. Identify your target audience. It is obvious, but I didn't think about who would wish to take my course. I didn't want to teach about the Scala language, so I ended up targeting "intermediate" Scala developers (e.g. 1-4 years experience). This way, I could assume familiarity with syntax and basic concepts like classes and traits. In September 2019, when I finished the initial version of the course and started to look for customers, I realised it is a tough segment to target. Most companies I talked to were either looking for beginner level content or advanced material. My course was too complicated for new Scala developers, and I didn't know how to make it appealing to more experienced developers (most people do not feel the need to revisit fundamentals). I decided to rework Foundation to make it more beginner-friendly, this meant rearranging and reordering several modules to assume as little previous knowledge as possible.
  3. Choose a programming language and embrace it. I wanted to create a course about typed functional programming such as it could be useful for developers using different programming languages: Scala, Haskell, Elm, O'Caml, Purescript, etc. The problem is that each programming language is unique; it has his own sets of features, limitations, bugs and workarounds. If you do not cover all these particularities, your course will have limited value. In my case, I decided to use Scala because you can code functionally and imperatively, which facilitate the transition for people coming from Java, Javascript or Python.
  4. Start with a problem and then show solutions. I planned to start with three modules somewhat theoretical and then move on to more practical subjects. For example, I thought it would be easier to explain the difference between Either and Validated if one knows about Monad and Applicative. It might have been a good idea if people were robots, but in practice, attendees will not finish your course if they don't know why they should learn abstract concepts. On the other hand, if you start by a problem statement and then propose solutions, your audience knows exactly why they learn something new. For example, in Scala, programmers do not know if a function can throw an exception without looking at the code. This lack of documentation makes refactoring more challenging. In functional programming, functions must return a value for all inputs. We cannot bail out and throw an exception. Therefore, we need to return a value that describes an error, hence better documentation.
  5. Identify objectives. What should people get at the end of your course? You both need to be realistic and appealing. I didn't have a clear goal when I started this project, and I found it difficult to summarise the entire course with a couple of bullet points. However, it was much easier to find objectives for each module because they target a specific content, e.g. getting familiar with Scala type inference is an objective of the function module.

If I had only one advice to give you is: don't skip planning and do your research. It is such a long project that an hour invested at the beginning will save you a dozen of hours down the line.

Surprisingly, quite a few things worked out very well. I will talk about them in my next post.

Please don't hesitate to reach out to me on twitter https://twitter.com/JulienTruffaut. I would be happy to discuss functional programming or training with you!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment