I think of the second half much more as reference. I can give it to a junior engineer or early mid-level and say "here is an example."

It's harder if they can't read the older examples, but I can google for a more modern example as well. It gives nomenclature and examples.

▲ dotancohen 3 days ago | parent [-]

  > It's harder if they can't read the older examples, but I can google for a more modern example as well. It gives nomenclature and examples.

Don't do that. Ostensibly you're giving these people the book so that they'll learn to deal with legacy code. Those older examples are exactly what they need to see, even if they're in a language that those devs are not using.

▲

ebiester 2 days ago | parent [-]

Junior developers in javascript codebases of 7-10 years old will not have the experience necessary in some cases. I am coaching them as a manager trying to introduce a concept, not a professor.

I may be doing a disservice to their long term development at the cost of short term gains. However, I don't think this is true. There are a lot of developers who will never work in a C, C++, C#, or Java codebase. And I try to adhere to Krashen's "comprehensible input" theory as it has a lot of application to learning the language of software development as well.

(See https://www.languagehumanities.org/what-is-the-input-hypothe... )

	▲	dotancohen 2 days ago \| parent [-]
		Why do you have junior developers maintaining codebases older than themselves? ))