4 ms·

I'm leading a scala transition at a javashop. I think you need a crital mass of people who understand scala as well as a lot of respect for your colleagues for

I'm leading a scala transition at a javashop. I think you need a crital mass of people who understand scala as well as a lot of respect for your colleagues for this to go smoothly, 10x so if you have legacy code. There will be some very tense discussions about how things ought to be implemented, and if not well managed, it can feel like "this approach is wrong, your code is bad and you are a bad engineer" which is toxic to any team. Sorry on mobile or I would write more. There is a lot of blog activity on this subject both from successful teams and unsuccessful that your leads absolutely must understand

catnaroek 13y ago
It should be evident to anyone with a modicum of understanding of what types are for, that Scala is a superior language to Java. (And Haskell even much more so, but Scala is friendlier to your existing investment in a Java codebase.) > There will be some very tense discussions about how things things ought to be implemented (...) Encoding as much as possible of the problem domain's logical constraints in types. Any property enforced by a type checker (and not subverted via a type system escape hatch) is a property that you do not have to test. > (...) and if not well managed, it can feel like "this approach is wrong. your code is bad and you are a bad engineer" My experience with most programmers using Java/C#/Python/whatever is precisely that: "Their approach is wrong. Their code is bad. And they are bad engineers." I have to waste my precious time subverting their brittle type systems (downcasts, reflection, assuming stuff is not null, etc.) and enforcing correctness the hard way (extensive testing or even good old non-computer-assisted brain usage), when I could simply read type signatures, get free theorems, run a couple of tests for checking stuff that cannot be inferred from types, and move on to the next thing.
- wpietri 13y ago
  You omitted the part where the previous poster described that quote as toxic. If you see your time as much more precious than your colleagues, and default to treating them with contempt, you're going to have a hard time finding colleagues. Which you may not care about. But what should matter to you is that it's basically a self-fulfilling prophecy. If you treat your colleagues like that, they're never going to get better, and they're going to be the ones who eventually vote to throw out all your beautiful code and go back to Java, where they at least understand what's going on and nobody condescends to them all day.
- dustingetz 13y ago
  raw tactical coding abilities is one axis of many that a business might value. More important than that, to our business, is that several of our engineers have extensive pharma domain knowledge, two of them we recruited away from our customers. It seems to me that most businesses are like this; a monad stack outside the context of a business is just generating heat.

catnaroek 13y ago

It should be evident to anyone with a modicum of understanding of what types are for, that Scala is a superior language to Java. (And Haskell even much more so, but Scala is friendlier to your existing investment in a Java codebase.) > There will be some very tense discussions about how things things ought to be implemented (...) Encoding as much as possible of the problem domain's logical constraints in types. Any property enforced by a type checker (and not subverted via a type system escape hatch) is a property that you do not have to test. > (...) and if not well managed, it can feel like "this approach is wrong. your code is bad and you are a bad engineer" My experience with most programmers using Java/C#/Python/whatever is precisely that: "Their approach is wrong. Their code is bad. And they are bad engineers." I have to waste my precious time subverting their brittle type systems (downcasts, reflection, assuming stuff is not null, etc.) and enforcing correctness the hard way (extensive testing or even good old non-computer-assisted brain usage), when I could simply read type signatures, get free theorems, run a couple of tests for checking stuff that cannot be inferred from types, and move on to the next thing.

wpietri 13y ago
You omitted the part where the previous poster described that quote as toxic. If you see your time as much more precious than your colleagues, and default to treating them with contempt, you're going to have a hard time finding colleagues. Which you may not care about. But what should matter to you is that it's basically a self-fulfilling prophecy. If you treat your colleagues like that, they're never going to get better, and they're going to be the ones who eventually vote to throw out all your beautiful code and go back to Java, where they at least understand what's going on and nobody condescends to them all day.
dustingetz 13y ago
raw tactical coding abilities is one axis of many that a business might value. More important than that, to our business, is that several of our engineers have extensive pharma domain knowledge, two of them we recruited away from our customers. It seems to me that most businesses are like this; a monad stack outside the context of a business is just generating heat.