Well, it does says a lot about users too. The typical user would have a hard time describing a software problem beyond 'I don't know, it is just not working anymore'.
That is a terrible attitude IMHO - why should they have to have to learn how to talk to developers? Your cynicism towards “typical users” probably harms you and your career.
I find that the vast majority of people are not stupid: they have learnt that trying to get things fixed is usually a waste of time. As a developer I truly understand this from when I’ve tried to get others to fix their software, and I am very good at describing problems.
Regularly I am the one that created the software problem, and if I were a better developer I would have avoided making the problem in the first place (or had ways to detect it, or easy ways for my clients to tell me).
> That is a terrible attitude IMHO - why should they have to have to learn how to talk to developers? Your cynicism towards “typical users” probably harms you and your career.
I think I'm sensing a bit of anger in your tone, looking how you move the subject on my person.
Sorry if I offended you in any way, it was not my intention to offend anyone.
Me and my career are ok so far, if that's of some relief to you.
We are surely not working in the same area then.
Mine is as a vendor of enterprise stuff, for Big Corps.
In my place, not relying in users' proactive and qualitative feedback is a pretty decent attitude in my eyes, it tends to deploying more reliable software, thus to invoices actually collected, which finally leads to having an actual paycheck.
I usually try to make a point of educating the users that, when it comes to software, there is no such thing as "it is not working". Software always works; it might work incorrectly, unexpectedly or confusingly, but the only way for software to "not work" is that the hardware never switches on at all.
