I started working as a Jr Dev at 32. Looking at other Jr Devs that entered the company around the same time I have had the fastest rise. Visibility is huge, this is true for any job. However visibility is a double edged sword, because you can fail spectacularly as well.

Here is my perspective, take it as an opinion.

I personally dislike people that talk the talk, but don't walk the walk. So if you want to wow your managers with lies and falsehoods this does not apply to you. (and you are part of the problem).

My approach is based on a few pillars. Work smart, be willing to fail, get uncomfortable, force yourself to be extroverted, always be learning, give something back.

Sometimes hard work is invisible. Anyone that had to spend countless hours on an end of life application fixing endless bugs with no one you can talk to is hard and thankless work. Work smart means fixing the right things, what has a big impact. You can do that anywhere, but doing it for a bleeding edge group or a problem solver group in your company makes the same amount of work appear better.

For agile teams, another part of working smart is choosing the right stories. Some stories are easy but invisible, others are harder but visible, choose the one that have a visible effect, usually they are higher stake, but it's part of the process.

Be willing to fail, goes hand in hand with smart work. If you try to avoid mistakes too much, you will get stuck trying to be perfect which means your output will drop. Also if you are working in high impact teams occasionally things will go really wrong. It might not even be your fault. That's fine.

A lot of people mess failure up. They fail and try to cover it up. This might work for management, but other devs know. Guess what, they will remember that, not out of menace, but it will become part of their opinion of you. They'll know that if things go south you will lie about it, or throw someone else under the bus. In my humble opinion the best way to deal with failure that's your fault is be in the forefront of the fix. A simple "I should have noticed this issue, but I did not. I am already working on a fix, and have talked to X team on mitigation strategy" is all you need. Most sane organizations recognize that mistakes happen, I mean this is why QA exists to begin with. If your response to a defect is to blame the PM for not having clear direction, or the QA for not catching it...guess what, you just made a PM and QA not trust you.

Discomfort is part of doing new things. The familiar feels safe. If you made a blue widget, then it's easier to make a red one, and if you make 10 widgets it's a walk in the park. However making a widget today, a bicycle tomorrow, a house next month will feel uncomfortable, however you will learn a lot. A counter point to this is don't be a generalist, try to master your tools a little bit. In other words don't always go for the new tech all the time, you want to be acquiring skills not dabbling.

Force yourself to be extroverted. Most developers tend to be introverts, I love machines, I find them fascinating, and probably it's a lot easier for me to deal with input/outputs that follow patterns than the chaos of human reactions. However it's really really hard to be visible if you are an introvert and talk to no one. There are some very talented devs that can be fully introverted and are recognized. You have to be really spectacular to be able to do that. It's much easier to be extroverted. If you are actually an introvert you most likely have noticed that extroverts tend to get a lot of undeserved cred.

For me it's a necessary skill. I am not suggesting you talk about the weather and have benign talk that no one cares about. I mean, say "hello", if someone mentioned they where going hiking this weekend, and it's Monday, ask them how it went. So perhaps it's more about being friendly. There is another aspect though, that without it you miss out on a lot. That's being willing to make presentations or sending emails to massive amounts of important people. You know, the introvert nightmare.

Think about it, if you write good code and no one knows you did it, how on earth are you going to be promoted / respected / mentor others...whatever your drivers are. It's not really possible.

Always be learning should be an obvious concept. If you are following my advice and you are working on cutting edge projects, being willing to fail, getting uncomfortable and even being more extroverted...you are learning.

Finally, give something back. Don't be the person that does things and never helps anyone else. Write that documentation. Mentor other devs, pair program with others that seem to be having a hard time. Ping the chat with a recent thing you discovered.

In the end, if your fellow devs like working with you, most likely your manager will sense it and that makes all the difference. Just make sure you are not full of crap and actually write some code.