"Even with bad Java idioms, the veteran is very likely to be turning out much better code because he is thinking about the underlying architectural issues (failure modes, recovery, concurrency) with far more experience."

Careful with that assumption. While there may be instances where this is true, I've met many veterans that couldn't think outside the small specialty they had become locked into.

Idioms are powerful in that the shape how you think about a solution within a fixed language. They shape your thinking and the shape of your thinking changes what solutions you can conceive of. A veteran that shows interest in a broad range of topics will have more failure experience and will be able to offer better results.

> I've met many veterans that couldn't think outside the small specialty they had become locked into.

It's the difference between 10 years of experience, and 1 year of experience repeated 10 times

I too have found this assumption to not always be the case. At my company there are certainly some people who qualify as vets yet insist on writing purely procedural C style code and have yet to adopt modern paradigms like OO design simply because they are so far removed from their education.

To be fair, they might be on to something. I've programmed my whole life in OO and recently started looking into FP. I can see the veterans thinking that OO is a fad after seeing things like BeanFactoryFactoryFactory (I personally do not program in Java and have never encountered the use case for a "Factory", and as such do not know what the use case is). After that, what value do you get to adding the functions to structs? I personally see the value, but I also see the value in not doing that. I would recommend teaching them OO while yourself should study FP and criticisms of OO. After them, it may be easier to evaluate which is better for your use case. It sounds like the vets have already cornered you out of OO, but you also definitely don't want to force the wrong tool onto a project just because it's the tool you understand best.

This makes me think of that study[1] about doctors being away on conferences. I think it likely comes down to recognizing that experience rarely, if ever, trumps solid analytical thinking.

[1]http://archinte.jamanetwork.com/article.aspx?articleid=20389...

> A CS student who knows Java (4+ years of experience) is going to turn out very different programs from a 20 year veteran of Erlang who is just learning Java.

Perhaps. But I would take contention with a CS student claiming 4+ years "experience" with Java unless they were referring to something outside of class work.

When filling a position though, you're usually not comparing "was handed my degree yesterday" candidates with 20 year veterans. . . they're demanding much different compensation and degrees of responsibility.

A more apt comparison of my point would be a 20 year veteran of of Erlang who says "oh, yeah, I can pick Java up. Never seen it, but it'll just take me a couple of weeks." is not, in any way, going to produce the same quality code as a 20 year veteran of Java of relatively comparable experience and general skill.

Why didn't you just write this:

> A CS student is going to turn out very different programs from a 20 year veteran.

Because its so obvious no one cares.

Exactly my point. Adding additional information can't possibly make it less obvious.