[erlang-questions] Onboarding programmers who are new to Erlang
Fri Aug 29 16:48:29 CEST 2014
On Fri, Aug 29, 2014 at 9:56 AM, Garrett Smith <> wrote:
> On Thu, Aug 28, 2014 at 11:47 AM, 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.
>> 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.
> Where are the Erlang leaders (those programmers who are building the
> system today) in this picture?
Right here are ready to mentor. I should clarify that in this specific
instance I'm not looking to 'bring in a lead', I'm looking to add very
talented juniors to the team and give them time and resources to grow
into a more senior role.
Yes, I'm well aware of the costs, both time and productivity, that
we'll incur, and yes, it's a risk investing so much in young talent
who can afford to jump ship.
That said, I'm willing to take that chance and make that investment
> I'd be concerned about sending folks off to a program only to have
> them mildly more prepared for the realities of your particular
> environment. This includes your existing code base, programming
> processes, culture, etc.
This is true for almost anyone joining a team. The only real
difference is the 'new language'.
The purpose of this thread was to gather information of how best to
bring them to a point where 'course work' would not be a total waste,
and given the time frame between courses is measured in months. For
all I know it would be a moot point by the time the next
conference/course comes around.
>> After that maybe have them work on a simple feature or two in some
>> prototypical work we're doing on the side, and of course sending them
>> off to the first available 'bootcamp'/training session available.
> It's a huge cost to pull your experienced Erlang programmers out of
> their day-to-day to help build a team, but you might end up paying
> that cost eventually anyway. Sending someone to a training will get
> them trained in whatever course material they're exposed to. That may
> have very little application in your particular context.
I see training courses more as 'foundational'. You can never learn
everything, and having a good base cannot be hurt.
> On the other hand, getting together with your Erlang leaders and
> working with them to build a training -- that could yield a more
> direct path to getting everyone closer to an independent contributing
Fully agree, but again, that's a trade-off.
>> What have you found is the best way to introduce them to the language
>> and bring them up to a level where they can start standing on their
>> own feet?
> As I think many have mentioned in this thread, it's not hard to pick
> up the basics of the language. IMO it's not that hard to pick up OTP.
While personally I will agree with you, I've been in the situation in
the past where stellar candidates just could not wrap their head
around functional, even given considerable time. Maybe this is a
symptom of the education system in the US (please not intended to
start a flame war), but very few grads I've interviewed even covered
functional programming at Uni/College.
> It's much harder though to put a programmer in position to
> independently solve real world problems (i.e. your specific business
> problems). I would not set that as any short term goal.
> Why are you doing all this in the first place? I imagine you have
> specific work in mind. Get them working on that, even if in a remedial
> way at first. Iterate and improve. You'll need cycles from your Erlang
> leaders though. That's a big cost. If you're not willing to bear that,
> you might consider hiring experienced Erlang programmers off the bat,
> or pulling in ESL for a combo consulting/training services for your
> particular program.
> Maybe... you could find that pointing smart, new programmers at a
> concrete, well defined, problem-that-you-have-to-solve that has real
> stake holders could work over time. It depends on the people
> obviously. But even in that case, if the team doesn't have some
> mentors who are working alongside it, even if just occasionally, it
> will likely flounder.
>> Are there any specific resources (books/sessions/tutorials etc) you've
>> found useful in the past?
> I think $300 will buy you most every Erlang book ever written. Have
> that material on hand and use it when you need to, but *build real
> stuff* to learn.
The bookshelves are already stocked.
You got it right there. "Building real stuff" is key. There are a
number of OSS projects we use which could do with some extra love, and
this is really where I'd expect to have them do their initial real
> I don't mean to be patronizing here, but you might have to adjust to
> the idea that building an effective team is expensive :) If you don't
> have help inside, pay a vendor.
Not at all patronizing. We started with a small team and have managed
to remain that way without overloading anyone. Our platform has been
running stably 24/7 for well over a year now (thanks to Erlang), even
through a couple of datacenter migrations. It's time to fill a slot
which should have been filled months ago, and as I tried to convey in
my initial response, I believe in investing in people.
More information about the erlang-questions