You know how a lot of engineering comes down to making good choices about trade offs? Could be speed vs memory, could be which language or API to use, could be

You know how a lot of engineering comes down to making good choices about trade offs? Could be speed vs memory, could be which language or API to use, could be keeping it simple vs anticipating likely future needs. Same thing goes for working with an organization or codebase that has sub-optimal aspects. You think about and pick which, among many axes, is the most impactful thing to push on and you just do it. If the software is huge and poorly documented, write the docs you want to see for the parts you work on. If it’s a big tangled mess, pick somewhere to start unwinding and just find a way to make some sort of progress. If you do this, and you have a healthy org, it will become a natural reference point for others about how to do things well. If you are instead saying that you feel no hope that work will be valued or recognized, you need to decide either to do it anyway (because you are someone who’s going to think and do the right thing, ie, lead) given the imperfect reality we live in, or you can decide to find a healthier org to work in. By healthy, I just mean more functional and well organized, and thriving in a field of sufficient resources — similar to what you’d think of in a healthy biological organism. So you might feel constrained by the existing language, build systems, release process, etc compared to working fully autonomously, on the other hand you can accept them as they are, gently advocate for ways they could be improved, but spend most of you energy on the things you can directly affect. It’s like gradient descent — push every axis towards improvement but push hardest on things you can improve the most. If you do this over time and don’t silo away too much, you will naturally gain more influence over time (again assuming a reasonably healthy org).