[erlang-questions] Onboarding programmers who are new to Erlang

[zxq9]

Writing from my experience in a multilingual and multi-paradigm environment 
(both computer and natural langauges)...

On 2014年8月28日 木曜日 12:47:55 Leonard Boyce wrote:
> I'd like to tap the collective wisdom of the group for their
> experiences in onboarding fresh-out-of-college programmers who are new
> to Erlang. This is assuming the new programmer has mostly imperative
> experience (C/C++/Java) and have had a fleeting glimpse of functional
> through Haskell.

If they've had more than a "fleeting" glimpse in Haskell, Scheme or even C, 
Python or Ruby done in a functional(ish) way then count yourself lucky. 

More to the point,  if the first quarter of LYSE, LYAH, Real World Haskell or 
SICP wouldn't be entirely new to their mind then you're dealing with someone 
from a decent school or who has a genuine interest and you have absolutely 
nothing to worry about. Teaching these people isn't necessary -- giving them a 
problem and a partner who has been around a little while is all that is 
needed.

One caveat: "give them a partner" means someone who is there, in person. I 
don't like the phrase "pair programming" because it brings all the XP buzzword 
baggage along with it -- but poisoned language aside, this is the essence of 
what I mean. Two people, one keyboard, unrestricted access to knowledge 
resources (including other people). I've had some great successes with remote 
workers, but nothing compares to having a real person, really there.

> I'm of the mindset to have them work through a book or two over the
> 1st couple of weeks with plenty of rubber ducking and/or pairing on
> simple exercises.
[1]

This sort of process can occur in parallel (and naturally will) for the sort 
of newcomer I mention above: the ones for whom the first quarter of beginner's 
literature isn't completely new. Keep a small library handy and in view of a 
place they will constantly see and magical things will happen. Its best if the 
senior partner of the coding duo is familiar enough with a few of the books to 
point out references as new ideas are encountered.

Directing this process is not necessary if you have the right sort of person 
and they have a smidgen of a background. Giving time for it to happen, 
however, is critical. Standing back for a bit and letting someone learn is the 
part I see most often gotten wrong. Sometimes it is hard to do, depending on 
whatever other business pressures you're facing at the time.

OTOH, if you're dealing with someone who lacks a functional background 
entirely...

I prefer to start out with something totally alien up front, namely SICP, and 
see how they do with it.[2]

They don't have to master all the material -- what you want is for them to see 
the basic functional list operations in use, see a data structure implemented 
as a higher order function, see a Java-style object built out of functions, 
and understand the difference between iterative/recursive processes and 
understand the independence of that idea from the idea of a recursive function 
definition which might create either sort of process.

I've thought about writing a pre-SICP short text in something closer to their 
experience, like Python, but haven't because I'm still on the fence about 
whether there really is a value in shocking the mind fully at first. In 
particular, Scheme's near lack of syntax seems to be a very healthy thing for 
early learning and makes SICP the most speedy entry to flexible ways of 
thinking about programs I've yet encountered, regardless of the person's prior 
background. The lack of syntactic sugar forces the learner to reconsider much, 
which is the whole point.

After those bits of SICP, showing them the JSON parser example in Real World 
Haskell is a big winner. That single example and its commentary gives 
precisely the sort of background necessary to understand Joe's discussions in 
Programming Erlang.

If your new guy's head hasn't exploded yet (but its totally OK if he's still a 
bit confused on some details) then you've got the right person. At this point 
I would feel comfortable handing them over to an experienced programming 
partner, point them toward LYSE, and advise them to re-read SICP to 
completion.

All of this requires a certain culture of interested exploration within the 
company, and that's not always an easy thing to create, maintain or find. More 
of my actual job these days is keeping an eye on the temperature of my working 
groups than actually coding, precisely because this sort of environment is 
somewhat delicate.

-Craig

[1] A note on "pairing on simple exercises". As much of your code as possible 
should be purely functional (as in, referentially transparent). It follows 
that you want as much of your code as possible to be dealing with rather 
simple things. This means that nearly all your production code that isn't 
doing I/O (in some fashion) should *be* a bunch of simple exercises. The 
syntax and semantics of LangA or LangB are the trivial problem, how to break 
the problem into (literally) simple exercises is the real trick an FP newcomer 
needs to see -- the actual typing part and the details of what characters are 
used is not important.

[2] I particularly like this with the Japanese translation because its a 
*hard* translation into serious, unambiguous, non-kana, no-cognate Japanese 
which itself is alien to the cool web kids. Granted, this particular detail is 
pretty region-specific, of course, and is a bit of a trial by fire. But I'm so 
absolutely disgusted with Rails and Java types who show up with their Macs, 
spewing buzzwords as if they make sense, looking for something "cool" and 
"social" to do on the "web" -- all in incomprehensible katakanized English-
injected slangy Japanese -- that I want them to quit right away if a technical 
translation performed by a mathematician turns them off.