What Am I Actually Learning When I Attend a Training Course?

The Erlang/Elixir 2017 conference in San Francisco wrapped up last week. This time, I didn’t attend — after weighing things back and forth, I chose this week’s Complete OTP training instead. After all, the conference videos will surface on YouTube sooner or later, and I can catch up on them at my leisure; a training session, once missed, is gone for good.

Attending a technical training is usually expensive. A four-day course like this one costs over two thousand dollars, and it’s hard to argue how much it’s really worth — half the topics were things I already understood or had mastered, and in the past month or two I’d even trained my own team on them. For the other half, I could have simply carved out four days to read books or the Erlang docs myself and probably learned no less than I would here. So what, exactly, is the point of paying this kind of money to attend?

Think about it for a moment.

Finding like-minded engineers? No. Using training to achieve that end is neither scalable nor economical — you’d be better off schmoozing at a relevant meetup.

Bonding with the instructor and building a relationship? Hmmm… What do you think four days can produce? We’re all honest programmers here, and we respect people who talk the talk by walking the walk; those who do good work naturally admire one another (I’ve arranged to have coffee with the instructor when he’s in the Bay Area in May); those who don’t, well, they’re strangers once the training ends.

Thinking along these lines is too simple, sometimes naive.

In truth, the ultimate meaning of paying for training is this (listen up): you are buying a consulting engagement with a training course attached.

Take the Complete OTP training I attended. The instructor, Francesco, is the founder of Erlang Solutions. Erlang Solutions is a consulting firm; many famous open-source projects (RabbitMQ, Riak, MongooseIM) originated there, and they were the ones who started the Erlang/Elixir conference. Given that profile, try walking into Erlang Solutions and buying four days of consulting — who knows what caliber of consultant they’d send you, and the starting price would surely be tens of thousands, not less. Two thousand? Dream on.

Unfortunately, no one else seems to get this. And fortunately, no one else gets this — the course was so quiet that the entire roster of Erlang/Elixir programmers worldwide (admittedly a small base), including me, numbered only nine. And the only ones constantly asking questions were me and an engineer from Apple (yes, Apple has projects internally using Elixir — yeah, Erlang/Elixir programmers can celebrate, then get back to whatever they were doing). And the questions focused on problems encountered in day-to-day work, related to company business, were basically all mine.

The Complete OTP course content isn’t especially dense — the exercise of building an ebank project took up nearly half the time. That precious window for asking every kind of dumb question — you know what happened? — the vast majority of engineers were silently grinding away at their code, occasionally asking Francesco what this meant or why that wouldn’t compile.

This is like having Bian Que at your side, refusing to let him diagnose you, and instead asking him to trim your nails.

Or, to use a joke programmers know well: a girl tells a programmer, “If you can get the entire forum to start arguing, I’m yours tonight.” The programmer posts: “PHP is the best language in the world…”

A tragic waste of treasure.

Do the exercises have no value? Not at all. The exercises used in this training are truly classic — from gen_server, gen_fsm, gen_event, all the way through supervisor, application, and using sasl to understand the release process in depth. If you can complete the entire set of exercises on your own, I’d say you could beat 80% of Elixir programmers — you could genuinely claim on your résumé that you’ve mastered OTP.

Very valuable — but the timing for realizing that value is wrong.

The truth is that only I in the class had finished the exercises beforehand (or afterward), and during exercise time I asked all the questions I hadn’t had time for during the course, plus every pitfall I’d stumbled into at work.

Look at some of the “silly” questions I asked:

• Why is start_link said to be a synchronous process?
• Why does an application start two processes before launching the supervisor? (Actually, I’d seen the answer in a book — I just wanted to draw out more questions to make sure I understood it correctly.)
• What’s the point of group_leader? (I think I get it, but I don’t know whether I really get it.)
• Is using a global process a good practice? (This time I shamelessly opened up the auto-compiler code I’d written at work and discussed it with him.)

And so on. At Francesco’s recommendation, I even read through some OTP source code and discussed the finer details of it with him.

That’s how you make effective use of this kind of “consulting engagement with training attached.”

If you agree with what I’m saying, then let’s look at how to extract the maximum benefit from a training session.

Choose the Right Instructor

If you’re holding the goal I described above, then the content of the training is actually secondary. Since you’re treating it as consulting, you need to pick the right “consultant.”

The instructor this time, as mentioned, was Francesco Cesarini. We’ve already noted that he’s the founder of Erlang Solutions (let’s set that identity aside for now). His other identities (the ones that drew me in) are: author of Designing for Scalability with Erlang/OTP, and a developer of Erlang/OTP R1.

In other words, apart from a handful of Erlang founders, if you were to hold a worldwide talent scouting for ten people qualified to teach OTP, he’d have to be one of them — and near the top.

I know most readers don’t know Erlang/OTP, and probably can’t distinguish Francesco from San Francisco. Let me put it another way —

If you run a WeChat service, and the uncle surnamed Zhang whom you burn incense to worship on a daily basis opened a small class showing you how to build WeChat services at a ticket price of ten thousand, while some random programmer gave essentially the same training for a rock-bottom hundred, which would you attend?

Once you’ve sorted out that choice, let’s try another: Rich Hickey is giving a Clojure training, or Guido van Rossum is teaching Dive into Python, aimed at intermediate programmers — as a Clojure or Python grandmaster, would you attend?

Do Your Homework

Should you preview in advance the content the training is likely to cover, organize all the questions you haven’t figured out, and ask them at any moment during the session?

At work, after working in one direction long enough and becoming familiar with the business, we become so-called “experts,” and if everyone around us in our domain is far worse than we are, we begin to think highly of ourselves. Can we take an opportunity like this to pull out all the problems we’ve hit at work — the ones we don’t understand, the ones we half-understand, the ones we think we understand, the ones we think we’re right about — and argue them through with the instructor?

Use the Opportunity to Break Through the Plateau

Programmers all know the ten-thousand-hour theory — enough time (ten thousand being a rough figure) of deliberate training in a field can make you an expert. From this we firmly believe that learning C++ in 24 hours is wrong and shallow; conversely, given sufficient effort, one can master C++.

That doesn’t seem quite right either.

Because I’ve met far too many mediocre programmers who’ve worked for over a decade. They seem trapped in a plateau that no amount of effort can break through — this is the no-fly zone of the ten-thousand-hour theory.

The classmates in this training all had far more Erlang/Elixir work experience than I did — I had three months of Elixir, three thousand lines of code, and zero Erlang work experience. Before the exercise, I couldn’t even tell when to use a semicolon versus a comma when writing code.

But after four days, I feel my Erlang coding level (slow though it still is, and I still drop the occasional period) is no longer much worse than that of classmates with years of Erlang experience.

Why?

I think many people misunderstand what deliberate training means — grinding toward a goal with your hair tied to a beam and your thigh prodded by an awl is fine, but you need to know how to break through the plateau and advance. Recently I’ve been taking my little girl ice skating every Saturday night. I know that no matter how hard she practices with me, skating a hundred laps without a single pause for an hour each time, she’ll never become the next Michelle Kwan. My ceiling determines her ceiling; but if she were lucky enough to skate with Michelle Kwan for a year and receive her guidance, at the same effort level — I daren’t promise much — a year from now she’d dominate her Cupertino age bracket without breaking a sweat.

So a crucial component of deliberate training is the feedback loop. Yes, I’m going to pour out the build-measure-learn chicken soup again. If you mechanically build, build, build without measuring, how will you ever learn? Measurement is crucial. Even more crucial is how you measure, who measures, and by what criteria you measure — that’s what makes all the difference.

Spending a few days learning from a master, even if your skill doesn’t skyrocket, at least shows you where the meridian you need to unlock lies. Haven’t we all read the story of Linghu Chong and Feng Qingyang on the Cliff of Reflection?

Make good use of your teachers. Teachers aren’t only the ones with flesh and blood, made of carbon; they’re also the colorless, odorless source code that evolved from 0s and 1s.

As Linus says: read the F**KING code!

When we read an excellent book, it’s like a heart-to-heart exchange with the author; when we read a piece of beautiful source code, it’s like the passing of the torch from elder to younger. In this world, perhaps only writing and coding allow the transmission of knowledge and experience as effortlessly as Wuyazi transferring his internal energy to Xuzhu.

For many of the questions I asked, Francesco suggested I go read the source code in such-and-such directory. Take the application master, or gen_server — I’d sit with the source, sketching the flow on paper, murmuring to myself: bravo!

When I reached a place I couldn’t follow, I’d go discuss it with him again.

You see — wasn’t that how the simpleton Guo Jing grew up under the tutelage of the Seven Masters?