1
Two years ago I built our first React app. It was a huge success, and the business saw the speed advantage of SPA architectures help boost sales. Slowly everyone was introduced to the basics of React components, lifecycles, etc. and things were going pretty good. We got more requests for the same functionality, so our app has been ported over to use React for many apps, and I introduced React Router. This year, we got to the point where Redux really started to make sense in order to maintain sanity between the different mini-apps that live in our main application.
I educated myself during work time on these tools and picked them after careful consideration of their complicated nature. It wasn't an easy choice, and I accepted almost all tickets pertaining to Redux when they arose. During every step of the process I did dev kickoffs and focus meetings about new features and functionality. I have spent countless hours hovering over shoulders, doing 1-on-1 lessons for individual team members. My superiors on the team at some point delegated all this responsibility on me.
I sympathize with he older members on the team, as I can tell they are tilted, questioning their obsoleteness and each production bug causing them stress. The organization is noticing all the errors though, and it's usually simple stuff that anyone who develops in React or JS would catch. The problem is though these folks are in the codebase, guessing and making assumptions, hacking to try and get things done. Our QA is very bad because of this, and often times I simply read commit messages and shake my head.
I have read a few stories recently about being the old developer and dealing with this change. What about when you're the one creating the change? How can you reduce the amount of anxiety felt by others when you introduce new technologies?