Whenever I am on a project, I try to write any tooling (code generators, utils, scripts, etc) in the tech that it uses. This forces you to broaden your horizons in the tooling. I even have a toolbox git repo that has a bunch of different tools written around this concept that I have often reused.
I would also recommend trying to 'think' in the language. Don't just try to push a solution into the language. Dig deep and see if there is something specific that makes the most sense to use.
Overall, I wouldn't try to push away your style entirely. I don't think you truly can. I would say the best bet is try to be a great engineer, with strong baseline principles which you then apply in the best way for each environment. Every decision is a tradeoff and many of the big schisms in tech come down to taste. Actively work to learn new ways of doing things. Work to understand other's code longer than you think you should.
Comments
Whenever I am on a project, I try to write any tooling (code generators, utils, scripts, etc) in the tech that it uses. This forces you to broaden your horizons in the tooling. I even have a toolbox git repo that has a bunch of different tools written around this concept that I have often reused.
I would also recommend trying to 'think' in the language. Don't just try to push a solution into the language. Dig deep and see if there is something specific that makes the most sense to use.
Overall, I wouldn't try to push away your style entirely. I don't think you truly can. I would say the best bet is try to be a great engineer, with strong baseline principles which you then apply in the best way for each environment. Every decision is a tradeoff and many of the big schisms in tech come down to taste. Actively work to learn new ways of doing things. Work to understand other's code longer than you think you should.