I think what the parent may have been complaining about is essentially myopia in interpreting things - ‘well, this technically checks the box of what they ask for’ while willingly avoiding thinking about the larger context of what is being attempted or trying to understand requirements that don’t make much sense.
Don’t get me wrong - it has it’s place, and if everyone always tried to understand everything, there are a lot of organizations and situations it would be crushing - but it’s also very frustrating in many situations for those who want high quality products.
> I think what the parent may have been complaining about is essentially myopia in interpreting things - ‘well, this technically checks the box of what they ask for’ while willingly avoiding thinking about the larger context of what is being attempted or trying to understand requirements that don’t make much sense.
I think what your post’s parent was pointing out is that in lots of environments, such myopia is just an engineers job definition, for which they will be punished if they stray. Interpreting end-user needs is someone else's job.
I'm not asking that develop to go against the requirements. But it's often possible to satisfy requirements without satisfying the user, even though it's actually possible to do both.
that's because they are doing software "for other humans" - aka, their manager and PM, who gave them the requirements.
So the problem is not the software engineer, but the person who creates those requirements to be fulfilled.