> They stop when the requirements are met, instead of when the user will be happy.

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.

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.

It’s the ‘not my job’ syndrome, essentially.

> 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 think we just violently agreed, and even repeated the same last line?

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.

Some organizations are structured such that it is difficult for an engineer to do anything else. An engineer doesn't always have access to the end user, unfortunately.