Clojure training feedback (June 2014)

feedback.md

Clojure training feedback (June 2014)

In June 2014 Futurice bought a two-day Clojure training from Metosin. It was held in our office in Helsinki, and had 20-something participant Helsinki, Tampere and Berlin. I was there as well, as a total Clojure-newbie.

It was two days very well spent. However I felt that there were quite a many things that could have gone better. As I managed to miss the official feedback form, I decided to write this letter. As many of the things I'm going to list here are quite generic things and ideas, I decided to make this into a gist, so other tech trainers can benefit from it as well.

Metosin dudes, don't get me wrong. I'm writing this to help you, not to bash you. I think you are incrediably talented people, and you have all what it takes to give world-class Clojure trainings. I just want to help you to get there.

What went well

• You had a very good start. You started by telling about how Clojure code is evaluated and how functions and macros are handled as a part of it. You also included a notion about the quote form very early. This all clarified some stuff which was totally confusing when doing the Clojure Koans.

And what did not went so well

• Demand a more uniform audience. Among the participants there were total Clojure newbies like me, people with some experience, and people with a lot of experience. During the training you joked how you will probably leave some people confused and some people bored. I'd say that is indeed what happened. Even though this was far more our fault than yours, you could have demanded an audience with a more uniform experience-level. One solution could have been to have two separate and smaller trainings.

• Focus on a single set of tools. In the pre-material you gave set-up instructions for multiple different IDEs, but you did not gave clear requirements what should be working before coming to the training. That resulted as a huge load of problems. While you were resolving those, we kept hearing lines like "Is your REPL running?" "Are you connected to the REPL?" "I'm not using this myself, but..." "Can you do X here?" Instead of all this, you should just declare a single environment, demand it from the participants, and you use by yourself during the training as well. It just benefits the training situation so much. We are professionals, which means we will be OK with the idea of using Eclipse for a few days for the sake of a training; we can safely return to our Emacs vs. vim flame wars afterwards.

• Tell about the development workflow. Development workflow is quite an important thing while learning a new programming language and a new environment. You gave almost no love at all to explaining why REPL is just a fantastic thing, what kind of things you can do with it, and how you normally use it as your daily development tool. If you would have demanded a common environement from everyone (let say Eclipse+CCW) you could have gone through these kind of things via live coding: "Now all of you select this block here. After that, press A+B. It's a keyboard shortcut for C, which with normal-people language means D. And that's a really useful feature because..."

• Tell people beforehand why are you going to tell them something. That's called introductions, and can be utilized on sections as well. After the Clojure code evaluation part you started to speak about Java, Java inter-op, and how Clojure works on top of Java. Seriously, I could not have cared less. Yes, I do have a history with JavaEE as well as with JavaME. I happen to know that some things in Java are just so totally f***ed up that it's impossible to enjoy coding of eg. a web app with it. However I released myself from that pain years ago (by switching to JavaScript; and no, it's not a joke). So if you are going to spend half an hour speaking about Java+Clojure stuff, please first tell people why you are going to do it. Why is it important? Why should I care?

• Speak clearly. You were quite good with this one; sometimes there just were parts which were hard to hear to the backrow.

• Do not engage in small-group discussions when you are supposed to talk to all. If you're answering to question, which spins off a small sub-discussion, make sure that everyone can hear it and that everyone understands what you are talking about.

• Only few exercises vs. too many exercises vs. live coding? On the first day you had planned all too many exercises for the time available. That was frustrating, as we saw that we were probably missing many exercises. On the second day you used mostly live coding instead, and hoped that everyone coded at the same time. It was nearly impossible to follow it, as you were coding so fast and switching windows all the time. It was almost like a cooking show on a fast-forward. It is possible to organize a successful training with each of the three strategies, but all of those require careful planning.

• During exercises, provide help. You had four trainers. I would imagine that while the participants are coding an exercise, there would be 3-4 trainers wandering around and helping. Most of the time, about just one of you did that.

• Prepare beforehand and be involved during the training (even if it's not your turn on the stage). Related to the previous one.

• Channel enthusiasm into real-life benefits. At some points you were totally enthusiasted about some things. Eg. core.async was one of these things. However you failed to channel that enthusiasm of yours into real-life benefits. Eg. during that core.async part I remember thinking that "man, that's just like Promises or FRP in JavaScript, but with a lousier syntax". In other words, as a trainer, it is not enough that you say something is cool, you also have to explain why it's cool.

• Give reasons for your opinions. At one point I started to count how many times you use phrase "smaller is better". After hearing it three times in five minutes, I gave up counting. (I personally don't believe smaller is always better in code. I gladly add some noise to it if I can increase readability with it.) If you're being opinionated, please tell if it's just you, or if it's a common opinion eg. among Clojure developers, and why do you think that way.

• Tell about coding conventions. You told something about this one, but it would have been interesting to hear more. Eg. why Clojure code (both core function names as well as other example code) is so full of abbreviations...

• Don't use abbreaviations in code snippets. :D But hey, seriously, a couple of times you coded an ad-hoc example for some problem that arise in discussions. Don't you think it would be easier to understand if you didn't use a, :a and 'a in the very same one-liner?

• Tell what it's like to code with Clojure. How vibrant is the community? How would you define the overal quality of 3rd party libraries? Why do you like Clojure so much yourself? These kind of things matter to coders nowadays, as there is plethora of languages and runtimes available to be chosen from.

• Where's the beauty? As so many people keep talking about the beauty of Clojure code, it would have been nice if you had mentioned at least something about it. Why do you (or they) think it's so beautiful? I would at least have been interested in that one :)

• Provide a path forward. It's always nice if a trainer can provide some ideas about where to go next. What to read, what to try out, how to get real benefit from the things one has just learned, etc. I tried to ask it from the Internet afterwards, and all I got was this lousy flame war.

So was it that bad?

No, it certainly wasn't. I understand that one may get that impression by reading this gist. It was awesome. The trainers were awesome and the participants were awesome. I just feel that it could have been even better.