5 ms·

After ten years of using Scala, I think if I was running a Scala team, the safest thing would be to hire people who are not excited about Scala. Like it, yes, b

by dkarl 4y ago

After ten years of using Scala, I think if I was running a Scala team, the safest thing would be to hire people who are not excited about Scala. Like it, yes, but not be super pumped. Developers who are primarily motivated by the excitement of learning new technology tend to write code that commits everyone around them to learning just as much, just as fast, which obstructs and pisses off developers who are primarily motivated by getting shit done. A team needs to strike a healthy balance between powering up with new ideas and getting shit done, and having people in the team who skew to one side too much to either side of that balance is a recipe for conflict. Eventually people will leave, often highly productive get-shit-done people, unless you fire the disruptors first.

didericis 4y ago
I’ve had the good fortune to work at a small place where the understanding between R&D disruptor types and get-shit-done GSD types was pretty good. When R&D types contain themselves/keep the playground from spilling over until whatever they’re playing with is ready/explored, and the GSD types don’t bulldoze the playground and let it feed them new tools/approaches/ideas when ready, it’s like an organization level flow state. Wish I had a formula for how to replicate that, is magical.
- rgoulter 4y ago
  In my experience, the failure mode for "GSD" is more likely a thoughtless approach of pumping out code, without consideration for efficiency or effectiveness towards providing value.
adamwk 4y ago
As an ex-Scala developer I feel like Scala is also the worst language in this regard, even compared to more academic languages. At least Haskell is somewhat prescriptive; in Scala people continually invent new ways to do the same thing. How many iterations of dependency injection or IO are we at now?
- therealdrag0 4y ago
  Can’t be more than Java has :p. New libraries and ways of doing things are great for the ecosystem.
- rgoulter 4y ago
  Ruby is another language where I wouldn't want an unrestrained/undisciplined amount of smart/clever code. My impression of Scala from a few years ago was that the language itself was so flexible (ranging from 'not quite Java' to 'not quite Haskell'), that you'd really want strict adherence to a particular style (or set of features) for a codebase to have hope of being maintainable.
  - michaelcampbell 4y ago
    I love and hate ruby for this reason. I'm working in it now, and it does allow some really fast-to-ship coding, but some of the LargeBrainedOne's framework stuff is so weirdly overly abstracted and metaprogramming'd ... They'll write 500 lines of inscrutable framework code to save having to write 5 lines of boilerplate 3 or 4 times.
ironmagma 4y ago
What are you doing running a company that uses Scala without having people who largely know the stuff already, though? Regardless of how quickly some newbie learns, the senior folks should already know all that stuff, or at least most of it. If they don't, that's the actual problem.
- Kamq 4y ago
  As someone who works on a legacy scala codebase, Scala's an easy language to get into this situation with. Scala's flexible enough that the old lisp pitfalls apply (though not nearly to the extent of lisp). That is to say, learning the language itself doesn't necessarily mean you're going to have any sort of grasp on a particular codebase, or even a different part of the same codebase. There's a particular style of scala that involves bringing in and stringing together dsls. Which is both extremely powerful, and can make code completely unreadable to someone who doesn't know that exact combination of packages. If you're not careful, your bus-factor is 1 and even the other seniors won't have any idea what's going on right away.
  - noisy_boy 4y ago
    > There's a particular style of scala that involves bringing in and stringing together dsls. Which is both extremely powerful, and can make code completely unreadable to someone who doesn't know that exact combination of packages. This is main point which, more often than not, turns out to be a negative for Scala (there could be specific circumstances where this may be a big positive but, usually not). The rule of thumb for me for Scala code is, only follow constructs/idioms/style mentioned in the Scala Book[0]. Most of the time, everything else is unnecessary trouble. [0]: https://docs.scala-lang.org/overviews/scala-book/introduction.html https://docs.scala-lang.org/overviews/scala-book/introductio...
    - Kamq 4y ago
      > there could be specific circumstances where this may be a big positive but, usually not I mean, I think that those circumstances would be a solo passion project. I still think scala is a beautiful and expressive language. But I think that expressiveness actually inhibits collaboration. If you're expressing novel thoughts in a novel way, you've added syntactic overhead to the already significant conceptual overhead. So, yeah. Quite personally rewarding, but I can't recommend it for a work project in good faith after having worked in it. Enterprise projects should probably use java/kotlin if they want to be on the jvm, or go/python/js if they don't.
nitwit005 4y ago
I see this as true generally. Managers want people who seem super excited, but people who treat the job as mundane often seem to get the best results.
- noisy_boy 4y ago
  There is the other end of the spectrum though, where people who overwhelmingly focus on getting it done, quite often, don't apply the requisite care to the code. I encountered an actual example of this, where devs were copy pasting hundreds of lines of code, no functions/methods with liberal hardcoding to scores of scripts. Each had the same warts since they were all copies. They all got the shit done while nobody bothered to clean up the mess into reusable chunks. As a new member of the team, I took the opportunity to cleanup when I got a similar assignment, which took an extra day. Subsequently when another dev had to do a similar task, he used my setup and basically had to make changes in 3 config lines which took a minuscule fraction of what he would have spent doing copy/paste and modifications. He was happy and I was puzzled why none of them bothered to do it for so long; my cleanup wasn't rocket science and any of them could have done it. As with all things, balance is the key.
Buttons840 4y ago
> getting shit done A team that gets shit done will later look back and see that what they've done is shit.

by dkarl 4y ago

didericis 4y ago

I’ve had the good fortune to work at a small place where the understanding between R&D disruptor types and get-shit-done GSD types was pretty good. When R&D types contain themselves/keep the playground from spilling over until whatever they’re playing with is ready/explored, and the GSD types don’t bulldoze the playground and let it feed them new tools/approaches/ideas when ready, it’s like an organization level flow state. Wish I had a formula for how to replicate that, is magical.

rgoulter 4y ago
In my experience, the failure mode for "GSD" is more likely a thoughtless approach of pumping out code, without consideration for efficiency or effectiveness towards providing value.

adamwk 4y ago

As an ex-Scala developer I feel like Scala is also the worst language in this regard, even compared to more academic languages. At least Haskell is somewhat prescriptive; in Scala people continually invent new ways to do the same thing. How many iterations of dependency injection or IO are we at now?

therealdrag0 4y ago
Can’t be more than Java has :p. New libraries and ways of doing things are great for the ecosystem.
rgoulter 4y ago
Ruby is another language where I wouldn't want an unrestrained/undisciplined amount of smart/clever code. My impression of Scala from a few years ago was that the language itself was so flexible (ranging from 'not quite Java' to 'not quite Haskell'), that you'd really want strict adherence to a particular style (or set of features) for a codebase to have hope of being maintainable.
- michaelcampbell 4y ago
  I love and hate ruby for this reason. I'm working in it now, and it does allow some really fast-to-ship coding, but some of the LargeBrainedOne's framework stuff is so weirdly overly abstracted and metaprogramming'd ... They'll write 500 lines of inscrutable framework code to save having to write 5 lines of boilerplate 3 or 4 times.

ironmagma 4y ago

What are you doing running a company that uses Scala without having people who largely know the stuff already, though? Regardless of how quickly some newbie learns, the senior folks should already know all that stuff, or at least most of it. If they don't, that's the actual problem.

Kamq 4y ago
As someone who works on a legacy scala codebase, Scala's an easy language to get into this situation with. Scala's flexible enough that the old lisp pitfalls apply (though not nearly to the extent of lisp). That is to say, learning the language itself doesn't necessarily mean you're going to have any sort of grasp on a particular codebase, or even a different part of the same codebase. There's a particular style of scala that involves bringing in and stringing together dsls. Which is both extremely powerful, and can make code completely unreadable to someone who doesn't know that exact combination of packages. If you're not careful, your bus-factor is 1 and even the other seniors won't have any idea what's going on right away.
- noisy_boy 4y ago
  > There's a particular style of scala that involves bringing in and stringing together dsls. Which is both extremely powerful, and can make code completely unreadable to someone who doesn't know that exact combination of packages. This is main point which, more often than not, turns out to be a negative for Scala (there could be specific circumstances where this may be a big positive but, usually not). The rule of thumb for me for Scala code is, only follow constructs/idioms/style mentioned in the Scala Book[0]. Most of the time, everything else is unnecessary trouble. [0]: https://docs.scala-lang.org/overviews/scala-book/introduction.html https://docs.scala-lang.org/overviews/scala-book/introductio...
  - Kamq 4y ago
    > there could be specific circumstances where this may be a big positive but, usually not I mean, I think that those circumstances would be a solo passion project. I still think scala is a beautiful and expressive language. But I think that expressiveness actually inhibits collaboration. If you're expressing novel thoughts in a novel way, you've added syntactic overhead to the already significant conceptual overhead. So, yeah. Quite personally rewarding, but I can't recommend it for a work project in good faith after having worked in it. Enterprise projects should probably use java/kotlin if they want to be on the jvm, or go/python/js if they don't.

nitwit005 4y ago

I see this as true generally. Managers want people who seem super excited, but people who treat the job as mundane often seem to get the best results.

noisy_boy 4y ago
There is the other end of the spectrum though, where people who overwhelmingly focus on getting it done, quite often, don't apply the requisite care to the code. I encountered an actual example of this, where devs were copy pasting hundreds of lines of code, no functions/methods with liberal hardcoding to scores of scripts. Each had the same warts since they were all copies. They all got the shit done while nobody bothered to clean up the mess into reusable chunks. As a new member of the team, I took the opportunity to cleanup when I got a similar assignment, which took an extra day. Subsequently when another dev had to do a similar task, he used my setup and basically had to make changes in 3 config lines which took a minuscule fraction of what he would have spent doing copy/paste and modifications. He was happy and I was puzzled why none of them bothered to do it for so long; my cleanup wasn't rocket science and any of them could have done it. As with all things, balance is the key.

Buttons840 4y ago

> getting shit done A team that gets shit done will later look back and see that what they've done is shit.