The goal is to measure people's results. It might occasionally take a relatively-long time to find a seemingly-simple solution. But if an engineer /always/ takes a long time to find every solution, and upon inspection the problems were not actually difficult, then you most likely have a low-productivity engineer on your hands.
Somewhat, but not entirely so. Managers can and should read git logs and bug tickets and design docs, and understand the architecture enough to have a reasonable sense of what the work entails. And managers should be engineers themselves and know that sometimes simple-looking work is actually very tricky… but at the same time it’s very unlikely that /every/ task looks like this.
That's not a good answer. We're not talking about thinking, we're talking about things with a cognitive component. Writing software has such a component and it's possible to tell if any software has been written (it's even sometimes possible to tell if it works or not).
The company as a whole makes a profit, how do you know what it would have been if feature X wasn't implemented? And ten people had a role in deciding to implement it, four in implementing it.
How can I possibly put a number on my contribution?
Yup, it's a more or less worthless conversation, but one that many knowledge workers end up in.
I remember once being a similar conversation regarding a training program I was working on, and the customer was trying to assess the value of the training not on the improved performance of the employees, but on some measurable "knowledge unit" that had been transferred to the student (regardless of their ability to retain it).
If you think your contributions to the economics of a business are impossible to understand, then you are in a dangerous position (your admittedly bad experience notwithstanding).
You can at least start from the top: the overall thing you are working on, how much did that make? Are features you worked on a contributing reasons for a sale/how much extra did they bring? Are you directly linked to some sales because you provided something specific? If you are doing internal software, could be cost reductions associated with that or also additional business.
Your number won't be exact, but it doesn't have to be and double counting among the other people isn't always bad.
I make frontends for our products (that we sell to governments), but they're not what drives sales. Customers by our product got features of the backend, they assume there is some frontend. If I do good work users are happy, but they don't make the buying decisions either.
That I work on the front ends was only partly my choice, we all move around depending on where we need people at that time, and other people decide what needs to be implemented.
If we were to fire all developers, we would probably lose hardly any sales the first year. But over time, licenses would go down more and more. So part of this year's profit is due to the work of people who left us years ago.
I don't see any point in claiming some specific part of our profit. People would laugh at me, probably.
You don't need claim, but you can at least associate with it. Even tracking happy users is a measure of sorts. It isn't an exact science and it doesn't need to be. And, yes, that isn't always fair to those gone from the company.
What if, as is usually the case, it created nothing until a whole team built the rest of the product that fits with my piece? What is the value provided by the front-end of a web app separately from the back-end?
The goal is to measure people's results. It might occasionally take a relatively-long time to find a seemingly-simple solution. But if an engineer /always/ takes a long time to find every solution, and upon inspection the problems were not actually difficult, then you most likely have a low-productivity engineer on your hands.