Skip to content

Instantly share code, notes, and snippets.

@rektide
Forked from anonymous/gist:1406238
Created November 30, 2011 18:48
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save rektide/1410258 to your computer and use it in GitHub Desktop.
Save rektide/1410258 to your computer and use it in GitHub Desktop.
Originally:
https://gist.github.com/7565976a89d5da1511ce
> Not being able to rely on a strong community presence meant we had to fend for
> ourselves in figuring out what "good" Scala was. In hindsight, I definitely
> underestimated both the difficulty and importance of learning (and teaching)
> Scala. Because it's effectively impossible to hire people with prior Scala
> experience (of the hundreds of people we've interviewed perhaps three had Scala
> experience, of those three we hired one), this matters much more than it might
> otherwise. If we take even the strongest of JVM engineers and rush them into
> writing Scala, we increase our maintenance burden with their funky code; if we
> invest heavily in teaching new hires Scala they won't be writing production code
> for a while, increasing our time-to-market. Contrast this with the default for
> the JVM ecosystem: if new hires write Java, they're productive as soon as we can
> get them a keyboard.
Hi Yammer. This, this is fascinating.
What were your candidates reaction when you told them Scala featured heavily at
Yammer? How many candidates do you think were more hesitant to join? How many
was it a perk for? What kind of enthusiasm curve did new people have coming in,
and over time as they spooled up to the domain of a production-ready coder. How
many otherwise qualified candidates did you turn down beause you were afraid of
how they'd interact with Scala?
What techniques did you use to battle harden the novices code? Code review, up
front code architecting, test/interface driven design; did any of these or any
other techniques factor in as training tools to accelerate the transformation
from dumb new guys Scala novice code to robust battle ready Yammer approved prod
code?
What were the breakdowns on this sunk investment cost? On one hand, people are
coming in and having to learn a new, very complex language. On the other hand,
it sounds like Yammer was also establishing it's own practice of what Scala
looked like at Yammer, that Scala forced Yammer to consider very hard what forms
and expectations it had for code, and to build patterns for making code.
Ultimately your experiment leaves me with a chain of questions; what were the
cultural impellers Yammer created to bring people in to Yammer's own practice
of Scala, what entities artifacts processes or other were most effective at
communicating what the standards and expectations of that practice were, what
were weak and ineffectual, and what of those indoctrination techniques would
have value in the Java world? Alternatively, do you feel that Java enforces such
rigorously consistent coding practice at the language level, to the extreme
degree where you can expect new hires to follow along and emulate from the code
alone?
Do you feel Yammer ever got to the point where it could run the pornography test,
where you had people who "knew [Yammer Scala code] when they saw it," and knew
Scala code being written didn't match any of the practices at Yammer?
> Even once our team members got up to speed on Scala, the development story was
> never as easy as I'd thought it would be. Because one never writes pure Scala in
> an industrial setting, we found ourselves having to superimpose four different
> levels of mental model — the Scala we wrote, the Java we didn't write, the
> bytecode it all compiles into, and the actual problem we were writing code to
> solve. It wasn't until I wrote some pure Java that I realized how much extra
> burden that had been, and I've heard similar comments from other team members.
> Even with services that only used Scala libraries, the choice was never between
> Java and Scala; it was between Java and Scala-and-Java.
I'm not entirely blind to interop concerns, and your staging of the problem as
four levelled isn't entirely amiss, but the additional taxation you describes is
only one level: holding the Java isomorphism in your head; otherwise your mental
stack sounds the same Java or Scala. Why did you feel the need to maintain an
isomorphic model of your code to Java code? When in Scala world, what kind of
Java v. Scala-and-Java battles were you experiencing, and why does Java feature
in both of those columns?
Last, please find someone at Yammer who would volunteer themselves as having worked
on a roughly similar size/shape of team from back in the perl webdev days, and have
them write up a diff report. My interest here is definitely in Yammer having to
have set up a practice for using their language, and Perl is the last great
existential language I would turn to, the last major language that required that
kind of concensus generating experience from it's teams, and I'd love to hear how
the team dynamics reflect each particular existential language in use.
Thanks,
rektide de la faye
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment