Man this company just doesn't get it
-
This post did not contain any content.
-
This post did not contain any content.
Only if your screenshot is of the desktop. If it's a screenshot of a game or app, it will try to put it in its own folder
-
This post did not contain any content.
who takes screenshots using the nvidia app? your PC has a built-in screenshot tool
-
This post did not contain any content.
They would fix it but they can't hear our complaints over the sound of their money printers...
-
Only if your screenshot is of the desktop. If it's a screenshot of a game or app, it will try to put it in its own folder
Thats not the main issue.
The issue is that screenshots DON'T BELONG in the
videosfolder and should go into thepictures/imagesfolder. -
Thats not the main issue.
The issue is that screenshots DON'T BELONG in the
videosfolder and should go into thepictures/imagesfolder.I know and agree. Just adding a tidbit about desktop folder vs other folders
-
They would fix it but they can't hear our complaints over the sound of their money printers...
What's that??? China wants a new budget ai chip????
BRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRR
-
Thats not the main issue.
The issue is that screenshots DON'T BELONG in the
videosfolder and should go into thepictures/imagesfolder.wrote on last edited by [email protected]An “images” subdirectory of the “pictures” folder? That’s almost as bad as the OP example! I could see
pictures/screenshotsthough. -
This post did not contain any content.
%AppData%\Roaming\654163413219648163\User\default\data\imagedata\images\NVIDIA Corp.\Desktop
-
An “images” subdirectory of the “pictures” folder? That’s almost as bad as the OP example! I could see
pictures/screenshotsthough.wrote on last edited by [email protected]I wasn't sure anymore what the windows folder name for pictures/images is (which is why the / isnt part of the path in my example :)).
-
This post did not contain any content.
This is my headcanon when I see a simple but long lasting bug like this at a large company.
To you or I, it seems simple. Clearly things are not working as intended and the fix is trivial. Raise a bug in the tracking system if you really have to, then just fix it, right?
Here's the thing. That code was written completely according to the specification. The path there was clearly there in the requirements. So what? So...that means it's not a bug, it's a feature change. And if it's not a bug, that means we can't officially use our allocated (but always shrinking) bugfix time to work on it.
If we want to fix it, we need to put in a feature change request. That means we have to articulate the value to the business in changing this feature and explain why we think the original specification is wrong. We can't get confirmation from the spec author because they are no longer with the company. That means we have to prove that it was written incorrectly.
If...and that's a big if, we can articulate that there's business value in doing this and that the original specification was likely incorrect, then we get to the really fun part. Prioritisation.
You see, the team that built that feature doesn't exist anymore. Once the bulk of the features were done, they got disbanded and the engineers moved to other teams. Technically there should be a single team responsible for every feature so it gets maintained, but in practice it doesn't really work that way. The people on the official team that's responsible haven't touched any of that code. They're not too keen on starting either because they have their own priorities.
So after all that, the task sits in the backlog of that team, neglected. Eventually in some distanct sprint planning session it will be flagged as an old ticket. You, who raised it, would have left the company and nobody in the meeting has context about why the task was created. Isn't that miscategorised, shouldn't it be a bug? Why is it with our team, is it even worth doing? Then it will be pruned from the backlog. The sad task that was fought for so valiantly, only to die sadly in the cutting room floor of a backlog grooming session.
Then one day, the bug will annoy a newcomer so much, they'll just sneak the change in under another ticket and the bug will finally be fixed. Months before the product gets scrapped for a worse replacement. What are the specifications of the replacement software based on? That's right, the original specs of the old system to ensure backwards compatibility.
-
who takes screenshots using the nvidia app? your PC has a built-in screenshot tool
I do it via my gpu driver because I don't want it touched by windows (it probably compresses it)
-
I do it via my gpu driver because I don't want it touched by windows (it probably compresses it)
i have a solution, and afterwards Microsoft cant touch your PC at all.
-
%AppData%\Roaming\654163413219648163\User\default\data\imagedata\images\NVIDIA Corp.\Desktop
Now this
This is chef's kiss
-
An “images” subdirectory of the “pictures” folder? That’s almost as bad as the OP example! I could see
pictures/screenshotsthough.Why not user/documents/nvidia/gfexperience/[app name]/? It records both screenshots and videos, and it makes sense it puts everything from one gaming session together. Making a subdirectory in Documents kinda erases the confusion.
But I can see why they did that. GFE was first and foremost created for
dataminingdirect capture from one's videocard and in-game graphics optimization. Then, it happens, many started to use it for screenshotting because it sometimes get installed on PCs in place of driver and, unlike windows' screenshot tool and scissors tool just saves a file immediately. When I needed to make a lot of them, I defaulted to it too. -
This is my headcanon when I see a simple but long lasting bug like this at a large company.
To you or I, it seems simple. Clearly things are not working as intended and the fix is trivial. Raise a bug in the tracking system if you really have to, then just fix it, right?
Here's the thing. That code was written completely according to the specification. The path there was clearly there in the requirements. So what? So...that means it's not a bug, it's a feature change. And if it's not a bug, that means we can't officially use our allocated (but always shrinking) bugfix time to work on it.
If we want to fix it, we need to put in a feature change request. That means we have to articulate the value to the business in changing this feature and explain why we think the original specification is wrong. We can't get confirmation from the spec author because they are no longer with the company. That means we have to prove that it was written incorrectly.
If...and that's a big if, we can articulate that there's business value in doing this and that the original specification was likely incorrect, then we get to the really fun part. Prioritisation.
You see, the team that built that feature doesn't exist anymore. Once the bulk of the features were done, they got disbanded and the engineers moved to other teams. Technically there should be a single team responsible for every feature so it gets maintained, but in practice it doesn't really work that way. The people on the official team that's responsible haven't touched any of that code. They're not too keen on starting either because they have their own priorities.
So after all that, the task sits in the backlog of that team, neglected. Eventually in some distanct sprint planning session it will be flagged as an old ticket. You, who raised it, would have left the company and nobody in the meeting has context about why the task was created. Isn't that miscategorised, shouldn't it be a bug? Why is it with our team, is it even worth doing? Then it will be pruned from the backlog. The sad task that was fought for so valiantly, only to die sadly in the cutting room floor of a backlog grooming session.
Then one day, the bug will annoy a newcomer so much, they'll just sneak the change in under another ticket and the bug will finally be fixed. Months before the product gets scrapped for a worse replacement. What are the specifications of the replacement software based on? That's right, the original specs of the old system to ensure backwards compatibility.
I feel this comment in my soul.
-
i have a solution, and afterwards Microsoft cant touch your PC at all.
wrote on last edited by [email protected]Already done lol. Been dual booting for a while now
-
This is my headcanon when I see a simple but long lasting bug like this at a large company.
To you or I, it seems simple. Clearly things are not working as intended and the fix is trivial. Raise a bug in the tracking system if you really have to, then just fix it, right?
Here's the thing. That code was written completely according to the specification. The path there was clearly there in the requirements. So what? So...that means it's not a bug, it's a feature change. And if it's not a bug, that means we can't officially use our allocated (but always shrinking) bugfix time to work on it.
If we want to fix it, we need to put in a feature change request. That means we have to articulate the value to the business in changing this feature and explain why we think the original specification is wrong. We can't get confirmation from the spec author because they are no longer with the company. That means we have to prove that it was written incorrectly.
If...and that's a big if, we can articulate that there's business value in doing this and that the original specification was likely incorrect, then we get to the really fun part. Prioritisation.
You see, the team that built that feature doesn't exist anymore. Once the bulk of the features were done, they got disbanded and the engineers moved to other teams. Technically there should be a single team responsible for every feature so it gets maintained, but in practice it doesn't really work that way. The people on the official team that's responsible haven't touched any of that code. They're not too keen on starting either because they have their own priorities.
So after all that, the task sits in the backlog of that team, neglected. Eventually in some distanct sprint planning session it will be flagged as an old ticket. You, who raised it, would have left the company and nobody in the meeting has context about why the task was created. Isn't that miscategorised, shouldn't it be a bug? Why is it with our team, is it even worth doing? Then it will be pruned from the backlog. The sad task that was fought for so valiantly, only to die sadly in the cutting room floor of a backlog grooming session.
Then one day, the bug will annoy a newcomer so much, they'll just sneak the change in under another ticket and the bug will finally be fixed. Months before the product gets scrapped for a worse replacement. What are the specifications of the replacement software based on? That's right, the original specs of the old system to ensure backwards compatibility.
That may be true in some truly well organized (usually "legacy big corpo" companies).
Where I've worked it's more like:
- Requirements only cover user-facing features, if that. (Not so) senior engineers are left to bridge the gap between UI mockups and literally everything else.
- Implementation issue is accidentally introduced
- Priority on the bug is lower than new features so no-one has any way to justify working on it
- One day a dev might be personally annoyed enough by the issue that they fix the part as part of some tangentially related work. Else it stays like that forever.
That is a basic side-effect of Agile development. If you have implementation details figured out to such an extent before writing the code, you are not doing agile, you are doing waterfall. Which has a time and a place, but that time and place is typically banking or medical or wherever you're okay with spending several times the time and money to get maximum reliability (which is a different metric than quality!).
I bet NVIDIA has driver crashes to figure out, and I know which of those issues I'd want them to focus on first if I used their windows driver.
-
This is my headcanon when I see a simple but long lasting bug like this at a large company.
To you or I, it seems simple. Clearly things are not working as intended and the fix is trivial. Raise a bug in the tracking system if you really have to, then just fix it, right?
Here's the thing. That code was written completely according to the specification. The path there was clearly there in the requirements. So what? So...that means it's not a bug, it's a feature change. And if it's not a bug, that means we can't officially use our allocated (but always shrinking) bugfix time to work on it.
If we want to fix it, we need to put in a feature change request. That means we have to articulate the value to the business in changing this feature and explain why we think the original specification is wrong. We can't get confirmation from the spec author because they are no longer with the company. That means we have to prove that it was written incorrectly.
If...and that's a big if, we can articulate that there's business value in doing this and that the original specification was likely incorrect, then we get to the really fun part. Prioritisation.
You see, the team that built that feature doesn't exist anymore. Once the bulk of the features were done, they got disbanded and the engineers moved to other teams. Technically there should be a single team responsible for every feature so it gets maintained, but in practice it doesn't really work that way. The people on the official team that's responsible haven't touched any of that code. They're not too keen on starting either because they have their own priorities.
So after all that, the task sits in the backlog of that team, neglected. Eventually in some distanct sprint planning session it will be flagged as an old ticket. You, who raised it, would have left the company and nobody in the meeting has context about why the task was created. Isn't that miscategorised, shouldn't it be a bug? Why is it with our team, is it even worth doing? Then it will be pruned from the backlog. The sad task that was fought for so valiantly, only to die sadly in the cutting room floor of a backlog grooming session.
Then one day, the bug will annoy a newcomer so much, they'll just sneak the change in under another ticket and the bug will finally be fixed. Months before the product gets scrapped for a worse replacement. What are the specifications of the replacement software based on? That's right, the original specs of the old system to ensure backwards compatibility.
New copypasta just dropped! Jokes aside, I felt this comment.
-
This is my headcanon when I see a simple but long lasting bug like this at a large company.
To you or I, it seems simple. Clearly things are not working as intended and the fix is trivial. Raise a bug in the tracking system if you really have to, then just fix it, right?
Here's the thing. That code was written completely according to the specification. The path there was clearly there in the requirements. So what? So...that means it's not a bug, it's a feature change. And if it's not a bug, that means we can't officially use our allocated (but always shrinking) bugfix time to work on it.
If we want to fix it, we need to put in a feature change request. That means we have to articulate the value to the business in changing this feature and explain why we think the original specification is wrong. We can't get confirmation from the spec author because they are no longer with the company. That means we have to prove that it was written incorrectly.
If...and that's a big if, we can articulate that there's business value in doing this and that the original specification was likely incorrect, then we get to the really fun part. Prioritisation.
You see, the team that built that feature doesn't exist anymore. Once the bulk of the features were done, they got disbanded and the engineers moved to other teams. Technically there should be a single team responsible for every feature so it gets maintained, but in practice it doesn't really work that way. The people on the official team that's responsible haven't touched any of that code. They're not too keen on starting either because they have their own priorities.
So after all that, the task sits in the backlog of that team, neglected. Eventually in some distanct sprint planning session it will be flagged as an old ticket. You, who raised it, would have left the company and nobody in the meeting has context about why the task was created. Isn't that miscategorised, shouldn't it be a bug? Why is it with our team, is it even worth doing? Then it will be pruned from the backlog. The sad task that was fought for so valiantly, only to die sadly in the cutting room floor of a backlog grooming session.
Then one day, the bug will annoy a newcomer so much, they'll just sneak the change in under another ticket and the bug will finally be fixed. Months before the product gets scrapped for a worse replacement. What are the specifications of the replacement software based on? That's right, the original specs of the old system to ensure backwards compatibility.
Oooff, right in my sprint allocation.
