You just found out that your team is migrating to a new framework or language... How do you ramp up? What do you do to practice and get become competent?
For me, I just throw myself in there. Straight into the frying pan as it were. One tip ive learned is, don't ask questions like. How do I do Class Inheritence in Javascript... because someone will answer you. Instead, ask questions, how to design re-usable code in javascript, you'll find much better answers to your question that way! :) cheers.
I like to make a small project (build a TODO list) or work though a problem set like Project Euler. Do others do that? Where do you get your ideas?
Most of my initial tactics are among the following list. Some are more appropriate to one or the other type new tech, frameworks vs. languages. Some are more easily accomplished, depending on the nature of the existing population of adopters.
I'd spend a bit of time, like several hours, reading about the concepts and purpose of the new tool. What does it solve and how?
Then I'd just jump in and start using it. If it's interesting enough I'll do something at home, but otherwise just use it at work and look up any problems.
(Although, if the team is switching to a new technology, chances are I'm one of the people who has been pushing for that for a while, so perhaps I'm already familiar...).
Richard Uie
"Live and learn" should have been "LEARN or DIE."
My first thought is actually that the team as a whole needs a plan. Also, not all changes are equal. Consider these two scenarios:
1) A team going from jQuery to vanilla JS is a quite direct translation, basically just syntax with no big conceptual leaps. There will be a minor productivity hit while they change over, but that's about it.
2) A team going from jQuery to React+Flow is not a direct translation. They are now learning SPA-style state management and a static type system, as well as all the syntax changes. They are also probably learning a bunch of ecosystem stuff like webpack, Jest, etc. They will need a lot more training before they can get back to their usual productivity.
The team in scenario (2) is basically learning a whole new coding paradigm. That's pretty big.
Regardless, these sorts of changes are more human than technical. Change Management is important. You have to look at....
On the individual level - most frameworks have an intro tutorial. It's good for everyone to do the same one so they can help each other out; and later on help new starters if required. That step is the starting point to cover basics around the new tech, learn syntax basics and so on. You don't want people doing that in production code bases.
After that it's good if you have leads who can guide people through the architecture they're putting in place, so people can do further training in the absolute specifics. For example a React project might choose Flow, Typescript or just stick with vanilla ES6 - doesn't matter what you pick, the team needs to know what the conventions and expectations are.
From that point people will probably want to move into real work tasks, with some extra time allowed to get used to the new way. The finer details depend heavily on the people involved, their experience levels and how they learn.