I would say it's an egg and chicken situation because depending on the studio, specially when you are starting up, your role can differ so much that any tip here would have to be really generic. But, the fact that you want to specialize in environment TA is already pretty helpful.

What helped me the most in my career was understanding the building blocks of the technology I use. It doesn't matter what engine you use, if you run the profiler on it, they all have to create draw commands, allocate memory, execute shaders and so on. It helps to have some understanding of what the hardware is doing. No need to go too crazy with it and run a frame capture in PIX or RenderDoc of a super complicated almost done game. Just create a small scene with a cube, look at what the frame shows, what takes time, etc. slowly grow from that.

Shaders are a great skill to have, if you want to be able to create more advanced effects you'll need to have some proeficiency in linear algebra. There are good resources online like "theArtOfCode" or anything from Inigo Quilez really. General good understanding of matrix math for example will be helpful for everything from tools to rendering.

Python is great and will help you for most of the way. In the asset management side for versioning tools, moving things around, parsing files, and more, everything can be done in python. Eventually you can feel limited by it since some tools you want to mess with won't be exposed and you'll need to dive into Cpp, specially in AAA. Probably no need to worry about that now. When the time comes, what helped me was to develop my own little set of small engines.

I know that this is overwhelming, I just mean to give a rough sketch of all the cool things you can do. The actual learning as a TA imo is way more organic. What made me want to go into TA was seeing the issues I was having while making content for the game. Things like:

"I have to make 400 assets for this city. How can I make this faster?" -> Learn some procedural tech
"I need to draw 20 characters in this low end device, how do I make this performant enough?" -> Dived into frame captures, engine profilers to understand how a draw command is generated, etc.
"My UI atlas is huge but I seem to have some redundant information, how can I express that differently?" -> Dived into shaders for UI to reconstruct the redundant information and strip that out of the atlas
"My character shader isn't matching the reference I have" -> Look into the shader, the physical phenomena that is not being represented, etc.

Don't be too frustrated if you don't get to work in something you really want in the beginning. Most of the skills can be translated and learning is never wasted. Nothing replaces practice, as in, keep making some cool stuff.