Work is valued if and only if it is something that management (or whoever evaluates your performance) cares about, which does not necessarily have to be in any way related to how much real value it provides.
Have you fixed a bug or introduced a feature that helps every software developer in the company? That’s nice, good work! But, if management does not include these software developers or cares about their opinion sufficiently, then the sad reality is that as far as they are concerned, you have achieved close to nothing. Have you replaced an SQLite database with a sharded PostreSQL system with Memcached for catching query results? That is only a good thing strictly if it addresses a pain point in a way that management cares about. If the only thing that solves is a headache for your devops team, and the devops team doesn’t have the ear of management, then you’re out of luck again.
Did you spot an accidentally quadratic algorithm on the hot path of your service that hasn’t caused an issue yet only because the server happens to be restarted every week for unrelated reasons, and you’ve spent a few weeks reworking the aforementioned algorithm to be linear? Whether you’ve delivered real value is a bit subjective: how likely is it that this would have a caused an issue in the future? How big of an issue could this realistically have caused? You have to also take into account the expected lifetime of the software: if there’s a good chance that it’ll be scrapped or undergo a major rewrite in the near future, then accordingly the value is less. These are good questions to ask to determine “real value” delivered, but they are the wrong ones for judging if your work will actually be valued. The only correct question for that is: can you make management care that you have done this?
What management cares about is sometimes a good proxy for real value delivered. Have you optimized code that nobody needs to be any faster? That was not a good use of your time and management should rightfully not be impressed: little actual value was created. Same for adding features that nobody needed or asked for. When proposing to migrate from one technology / framework / platform to another, management will usually ask two questions: why do we need to do this (i.e. how much value will it add), and how long will it take (i.e. what will it cost)? This is a good thing. It is your job as a software developer (especially in a more senior or lead role) to accurately relay this information, and to present a strong case for doing work that you truly, genuinely believe should be done. It is a fact of life that sometimes you will fail because you haven’t managed to explain the issue in the right way for them to understand, or, looking at this in the opposite way because they have failed to understand.
But management consists of people (unless you are reading this from a future in which your boss is ChatGPT). Hopefully intelligent, wise, competent, and driven people with the right incentives… but people nonetheless. And people have biases and limitations. For example, the unfortunate reality tends to be that fixing problems before they arise is essentially invisible (known as the Preparedness Paradox), and therefore valued little or not at all; but letting it set fire to your production environment and then coming in to fix it is going to be very visible, appreciated, and valued (you may even get called a hero!). Of course, I certainly would not recommend taking this philosophy to the extreme: issues frequently popping up will usually lead to unhappy management and therefore bad reviews; but at the same time, preventing all fires at the cost of not delivering new features (or whatever it is that the Powers That Be care about you doing) is also likely going to have the same effect on your perceived performance.
Of course, a good manager or team lead will usually understand the value that your work provided even if it is indirect. But this is really really hard! It is fighting an uphill battle. Indirect value tends to be difficult to measure or quantify. It may even start being effective later, after some time has passed, and few people will take care to trace the cause back to your work months prior. You’ll have to work hard to sell the value you provided, and that in and of itself may get you in trouble, as it can be easy to mistake you for someone who does nothing useful but talks.
Whenever you create value indirectly, whether it will be recognized is – to a large extent – a question of trust, which in turn tends to be a function of how much your manager likes and respects you. Depending on your job and the environment you’re in, the ratio of direct to indirect value supplied by you and your work may make it anything between “exceptionally helpful” to “absolutely critical” for you to be liked and trusted by management in order for you to be appreciated and to have a long, successful career.
Edit 2023-12-16: added mention and link to the Preparedness Paradox at the suggestion of a colleague – thank you!