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.
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.