I ask my boss if he will let me teach them based in my experience. I know it sound pedantic but I want to help the company and bring them forward.
So, here is my dilemma. Where to start.
Here are my ideas so far:
- web apps patters and structures
- tools and libraries
- developer tools and technologies.
Currently I work with Vue and react in my personal projects.
Any help is appreciated.
3.4K+ developers have started their personal blogs on Hashnode in the last one month.
Write in Markdown · Publish articles on custom domain · Gain readership on day zero · Automatic GitHub backup and more
As an overall suggestion, start out by looking at...
- what your team knows now - eg. are they strong in jQuery for the DOM? are they used to backend MVC patterns?
- what skills and mindset do they have - eg. are you teaching backend devs who've never really done apps in JS, or frontenders who are updating their skills who've never done backend stuff?
- how do they currently learn new things - eg. do they like to learn by pair programming, do they like self-paced online courses, etc?
- how much time do you have to work with - eg. could you set up a regular workshop time for people to learn, or will you be relying on them doing lunchtime sessions and out-of-hours homework?
In terms of actual subject matter...
If you can find an existing course or set of tutorials that you can walk the team through, go with that. It saves you a lot of time and doesn't diminish the team's learning.
If you are doing it yourself from scratch...
Start with the basics: go through the new patterns in ES6 before moving into frameworks, tooling etc. If the devs are comfortable with jQuery you might be able to start with a session on going from jQuery to vanilla, as a way to help them build on familiar patterns.
When you do go to the frameworks, again try to build up from the basics. Get them doing basic React view code, then add JSX, then start adding build tooling around that; or perhaps that's when your team would prefer to move into the data/state handling stuff.
What you get people to make during this process depends on their mindset. For example you could have them recreate something you've already built, the upside is familiarity; but the downside can be that they try to recreate old methodologies in new tech that doesn't suit it. Or you could have people create classic programming challenges like fizzbuzz and To Do lists; so long as they haven't done that so many times they're bored by it. You need to judge what will work for your team.
One final note - remember you are adding a lot of value by helping the team upskill. Don't get stuck on the idea they're "letting you" do this :)