[erlang-questions] Onboarding programmers who are new to Erlang
Fri Aug 29 02:07:39 CEST 2014
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
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.
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
I prefer to start out with something totally alien up front, namely SICP, and
see how they do with it.
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
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
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
 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.
 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.
More information about the erlang-questions