That clears things up. I'm glad that my concerns were a misinterpretation.

I myself have been in your shoes in terms of not being able to communicate hard-earned lessons to those less experienced. I don't have a remedy for that other than time. The problem is that if devs follow your advice at face value, they may not run into issues but they can't internalize what they never ran into. Only after they've learned enough can you communicate by analogy in a way that's meaningful. Another trap is that being an expert in one subject area is often dismissed in others which seems reasonable for those with singular depth of knowledge. I've encountered this with mobile dev where I had highly transferable desktop GUI experience to make mobile dev straight forward but until I demonstrated it others would have no clue. Also, the differences in languages tend to be mostly syntactic but some consider that you either know or don't know a language.

Another thing that has helped greatly in my situation is pair programming in a small startup. I had already done some mobile & web dev tutorials but pairing on production code fills in the details. It shows how much of what you already know is relevant. Eventually they also pick up better ways of doing things when you either build it a different way but best when you're fixing an issue that was done a poor way.

This pattern has repeated enough that I've come to terms with it--any time I'm at a new startup, I give it 6mo-1yr for the team and management to fully figure it out.

> That's what I mean by "missing opportunities to less experienced engineers" : I might have the upper hand when it comes to tech vision and making good long term architecture decisions, but this isn't nearly as immediately useful (or appealing to a business partner) as their ability to actually get dev shit done and code a product prototype over the week-end.

This is a key point, worth seeing from another perspective. Consider that delivering end-user visible features quickly is actually more valuable 'in the present' and long term architecture is for later. We've gone through 4 products/pivots in two years, having spent good architecture/engineering on any product but the last would have been a waste (and we did spend it on the second one). Thing is, we never know which product is the last one. The cadence that's been working out is that others develop new features on products and I pair with other devs sometimes building features but more often improving existing ones by extending them, refactoring them, or simply fixing bugs and making them more reliable/performant. Retros and the occasional Lunch & Learn to share with the extended team to round it out. The most important thing is that it's all done without pointing fingers (or right/wrong labels). Under the same circumstances I would likely behave similarly, so it's best to think of everyone being on a similar path, just at different points. Having written this I think the biggest change was in myself having more patience and seeing more experience/knowledge as just that to be shared and not any kind of superiority. [Less than perfect: I have been known to 'go rogue' on specific issues (not recently) though it's mostly worked out.]

Edit: Do play with a newer framework or two. I chose Vue.js and Flutter/Dart. And you can sidestep much back-end coding with GraphQL.