Writing a template for issues that remove friction to write good, detailed, issues. This is important as everyone notices how helpful this is and productivity increases as when one in the team or the whole team is in flow or on a sprint, you can slay a huge number of issues because everything there is to know about the issue is there.
Writing deployment recipes. Automating the build process. Reducing the steps from committing new code to code running.
Writing the tests. Refactoring. Factoring code out. Simplifying. Building tools and utils.
Writing the documentation, for code and for the product (markdown, latex for a slick pdf version).
Acquiring as much knowledge as possible on every aspect, and sharing it with others. Read books / chapters relevant to an aspect and summarize key points with a reference.
Helping with logging. Writing clear error messages or wrapping cryptic error messages from third party code in nice error messages after a root cause analysis. Find weird edge cases and quirks. Relentlessly poke holes in the product.
Exceptional commit messages with root cause analysis and rationale behind the diff: commit messages should teach us something and help with Chesterton's fence.
Write the product pitch.
Audit the security of the code, with automated tools if there is no security aspect for the product. At least remove blatant security holes.
Add CI tests/pipeline.
Work on the product's interface / ux. If there's a graphical component, nicer icons, more refined styling, a better font.
Have people use the product without helping them and note all their struggles. Fix that. (if the product is a library, have a programmer try to use it and note everything. Observe their reactions, etc. I've had people who never programmed try to use a library armed with a technical doc. I knew it was okay when they could run the examples and said "it made sense".) If it's a product for people, have people who'll end up using the product use it and watch them like a hawk.
Take notes in meetings about the product and share them. Note every little detail that bothers anyone and make sure it survives the meeting by creating the proper issues. Assign everything to yourself.
Help make your code extensible and try to keep the core as small as possible. If a new developer joins the team and is tasked to develop a feature, most of their work should be on developing the feature, not digesting the code. The feeling you get when a new developer comes to the project and can develop a feature as fast as they can think and code as opposed to as fast as they can understand the code is just amazing.
Constantly try to find a better abstraction and better data structures so the code makes sense and people can guess the next step / line of code before they read it.
Understand the value of the product, business value of the product to help make better engineering trade-offs and avoid wasted effort.
Learning to write well. Technical writing. Explaining concisely. Making points, exposing trade-offs, and recommending an approach.
Build it then pitch it. For example: there's a difference between talking about an approach, and implementing an approach and pitching it. Team/CTO might like it and it gets merged instead of an endless debate.
Be prepared to hear no and kill the branch while keeping the nice gems of code written somewhere for later use after polishing. These gems will be merged at a later time when you find another use for them, or the assumptions that killed the idea/code change.
Own the product.