I'd want this worded in the most communicative way possible, but something along the lines of:
Consider use cases of people in different circumstances than you....
This relates to accessibility, but in general is about having empathy for the whole ecosystem of possible end users... Like, anyone who could benefit from this software should be able to, and take the time to consider them.
One of the most salient features of our Tech Hiring culture is that there is so much bullshit. Everyone knows this. Each of us contributes his share. But we tend to take the situation for granted.
It can't be quite that simple because "talk to users" doesn't always scale or can't be the responsibility of everyone... More, like, "learn about users". Getting a sense, for example, of who might be bandwidth constrained vs who might never have to think about that. Talking to users could be part of the learning experience but isn't always achievable.
One of the most salient features of our Tech Hiring culture is that there is so much bullshit. Everyone knows this. Each of us contributes his share. But we tend to take the situation for granted.
watching a blind noncoder use a built-in/free screen reader on a slow connection work at adding an MX record changed the way I code forever. It was the most painful user experience I have ever witnessed. 40 minutes into it the new record still had not been added and the NS had almost been wiped out twice - would have been if I had not been watching.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I'd want this worded in the most communicative way possible, but something along the lines of:
This relates to accessibility, but in general is about having empathy for the whole ecosystem of possible end users... Like, anyone who could benefit from this software should be able to, and take the time to consider them.
Talk with your users?
It can't be quite that simple because "talk to users" doesn't always scale or can't be the responsibility of everyone... More, like, "learn about users". Getting a sense, for example, of who might be bandwidth constrained vs who might never have to think about that. Talking to users could be part of the learning experience but isn't always achievable.
Right, it's one mean to an end. Maybe I can paraphrase Stephen Covey
=> Seek first to understand your users, then to be understood
watching a blind noncoder use a built-in/free screen reader on a slow connection work at adding an MX record changed the way I code forever. It was the most painful user experience I have ever witnessed. 40 minutes into it the new record still had not been added and the NS had almost been wiped out twice - would have been if I had not been watching.