Your original example is very specific, but your follow up clarifies that the reality is that it is vague guesswork. I think you could claim contribution, but very hard to define that line x of code written last Friday resulted directly in y% of profits.

To me it signals you're probably exaggerating. You better be able to back up your reasoning behind your claim. Bold claims require bold explanations.

It’s not vague guesswork at all. If you can’t measure the success of your project, why are you doing it?

It’s okay, even expected, if the answer is probabilistic. What’s not okay is doing stuff for no reason.

Bonus points if you’re able to tell a story like: We did X to achieve Y, but it didn’t work because Z. So we tried ...

This goes back to the tying of a SQL query directly to profits. That would be an interesting story if it were true, but such a story is probably an extreme rarity.

We're talking about calculating the impact of your weekly or daily work directly to profit generation. There is a level of granularity and detail to your claim that is likely impossible to realistically calculate, so it would be very hard to accept such claims at face value.

"I made the query for X, an operation that is performed Y times per day, Z% faster resulting in N% increase in Xs performed daily. This meant we could (defer hiring additional headcount|do more <profit-generating/cost-limiting process dependent on X> per day)."

Many teams don't invest in the tooling required to measure this kind of impact, but it's possible to ballpark it.

That’s a good example. The math doesn’t need to be precise, and you don’t need to track it down to lines of code. “Part of team of X developers who delivered product Y that produced $Z in revenue.” is enough for anyone to very roughly ballpark-estimate impact.

This is counter to GPs initial point, where there is a specific claim of direct profit generation. The advice is now just getting watered down into vague ballpark estimates and tossing in a revenue number onto your resume. The advice might as well just be "work on successful projects", which is "thanks captain obvious" advice.

The success of the project as a whole is measured, of course.

But it's 20 people working on it, from design to sales to ops to customers relations to devs. How could you possibly pin 20% of the profit (not even the turnover, but the profit) on one guy?

Even if he improved the SQL queries and that immediately led to more sales, making the choice to work on that over other things was probably not his.

Nobody is asking to pin all that on exactly one person. That’s a silly overly engineery way of looking at it.

It’s a team effort. Being part of the team who did X is enough. You can then talk about your specific individual contribution when appropriate.

Just like everyone in an NBA team “wins the championship” and gets to put “winner” on their resume. Or how hockey players say “I won the Stanley cup”, even though they did it as a team.

This seems to be completely counter to your initial post tying weekly/daily work directly to profit to determine what is worth your effort and what to put on your resume. You even give SQL queries as an example, so I don't see how that's not trying to tie it down to the lines of code.

There's a big difference between:

1. I optimized SQL queries for Nameless Corp to increase profits 20%

2. I optimized SQL queries for Nameless Corp on a multi-million dollar project.

> The PM you worked with should be able to answer this question

Most software devs work on tiny fragments of large projects. Let's say I work in Microsoft on Bluetooth stack in Windows 10 - how do I translate that into increased Microsoft profits?

How does the PM know? Are they told or is it something they are required to ascertain?