Live data from Hacker News

How to DOS a developer

who-t.blogspot.com

21–30 of 36 posts

Re: How to DOS a developer

#21
post #8

This is an example of my least-favourite type of HN story: "Devs are clever; users are stupid". While it is not untrue it misses the underlying problem: Devs are generally bad communicators and have an unrealistic assumption about the language and technical understanding of their users which they translate into "users are stupid". To get a feel for how this feels consider the last time you took a car to be fixed and…

> Devs are generally bad communicators That's a myth IMHO, there is no evidence that this is true. Besides, I don't think the author claims that "users are stupid", but that they often don't take the time and diligence to make their case as clear as possible, because they lack awareness that the open-source devs are doing them a favor. Apart from that, I do fear that writing this article probably won't help solving t…

That's a myth IMHO, there is no evidence that this is true.

I have observed a few devs who are not so good at understanding a different point of view while they are also fairly attention getting. I think this is where the idea comes from. Also, it's pretty hard for a non-dev to understand a dev's POV, which adds to the communications problems.

Re: How to DOS a developer

#22
post #9

It's similiar to my dating tactic: "Want to go for a drink with me?" "Want to go for a drink with me?" "Want to go for a drink with me?" "Want to go for a drink with me?" "Want to go for a drink with me?" "Want to go for a drink with me?" "FINE YES!"

Do you find yourself making telephone calls that are disconnected numbers or are answered by someone unexpected?

Re: How to DOS a developer

#23
When I read about this I always think about Joel Spolsky's observation about 15-minute distractions that affect programmers. When you start thinking about your day in those terms, telling the people talking to you to get bent (in nicer terms) starts to be justified.

Here's the simple algebra. Let's say (as the evidence seems to suggest) that if we interrupt a programmer, even for a minute, we're really blowing away 15 minutes of productivity. For this example, lets put two programmers, Jeff and Mutt, in open cubicles next to each other in a standard Dilbert veal-fattening farm. Mutt can't remember the name of the Unicode version of the strcpy function. He could look it up, which takes 30 seconds, or he could ask Jeff, which takes 15 seconds. Since he's sitting right next to Jeff, he asks Jeff. Jeff gets distracted and loses 15 minutes of productivity (to save Mutt 15 seconds).

http://www.joelonsoftware.com/articles/fog0000000068.html

The entire discussion about the zone is enlightening. If you haven't read it, do so; it'll make you think during your day.

Re: How to DOS a developer

#24
post #8

This is an example of my least-favourite type of HN story: "Devs are clever; users are stupid". While it is not untrue it misses the underlying problem: Devs are generally bad communicators and have an unrealistic assumption about the language and technical understanding of their users which they translate into "users are stupid". To get a feel for how this feels consider the last time you took a car to be fixed and…

If your program is free (as usually with open source), you have a lot of 'customers', which all feel they are entitled to support.

Pulling the information you need from users to fix a problem can be quite some work.

This decreases the time available for development. That's all. Hence "DoS".

I don't see any belittling in that.

Re: How to DOS a developer

#25

Earlier quoted context omitted.

> Devs are generally bad communicators That's a myth IMHO, there is no evidence that this is true. Besides, I don't think the author claims that "users are stupid", but that they often don't take the time and diligence to make their case as clear as possible, because they lack awareness that the open-source devs are doing them a favor. Apart from that, I do fear that writing this article probably won't help solving t…

That's a myth IMHO, there is no evidence that this is true. I have observed a few devs who are not so good at understanding a different point of view while they are also fairly attention getting. I think this is where the idea comes from. Also, it's pretty hard for a non-dev to understand a dev's POV, which adds to the communications problems.

All is true. But please, nobody comes from doctors saying they're bad communicators. They say that they are educated. Some people accept that they don't understand and just heed the advice or ignore it altogether or something in between, while others try to learn enough about medicine to understand what the topic is.

But everybody is an expert on software - since their mother told them so. I'm sick of being patronized by people who refuse to pick up the tiniest bits of the craft saying "no, no, no - that's not my job" - while they are clearly working in a field they haven't the slightest clue about.

Software has to be the only field where ignorance is used as a badge of honour: "I don't need to know anything about how it's done, I'm a project manager."

I'm an excellent communicator, I can figure out how to talk to anyone about anything (I'm a hustler by nature), but when people start talking down to me on a topic I dedicated half of my life to. I make them remember.

Re: How to DOS a developer

#26
post #20
post #8

This is an example of my least-favourite type of HN story: "Devs are clever; users are stupid". While it is not untrue it misses the underlying problem: Devs are generally bad communicators and have an unrealistic assumption about the language and technical understanding of their users which they translate into "users are stupid". To get a feel for how this feels consider the last time you took a car to be fixed and…

That is not the point, and Hutterer never said "devs are clever", much less "users are stupid". Those are your words. Read the article again. I found it amusing, as it has been happening to me lately.

Just because those words didn't appear in the article doesn't mean that they're not an accurate description of the author's tone.

Re: How to DOS a developer

#27
post #8

This is an example of my least-favourite type of HN story: "Devs are clever; users are stupid". While it is not untrue it misses the underlying problem: Devs are generally bad communicators and have an unrealistic assumption about the language and technical understanding of their users which they translate into "users are stupid". To get a feel for how this feels consider the last time you took a car to be fixed and…

Ahh yes, the "it is always the developers' fault" mentality. It couldn't be that sometimes the developers have bad communication habits, but sometimes the users really are acting like assholes, could it?

Let me guess: you have never actually worked in the field, or if you have, it was some trivial job like CSR-1.

Re: How to DOS a developer

#28
post #9

It's similiar to my dating tactic: "Want to go for a drink with me?" "Want to go for a drink with me?" "Want to go for a drink with me?" "Want to go for a drink with me?" "Want to go for a drink with me?" "Want to go for a drink with me?" "FINE YES!"

You should reverse-engineer your dates: "You really don't wanna go a date with me." Unfortunately it works. Problems will arise when your date will realize she really shouldn't have gone on a date with you.

Re: How to DOS a developer

#29
post #8

This is an example of my least-favourite type of HN story: "Devs are clever; users are stupid". While it is not untrue it misses the underlying problem: Devs are generally bad communicators and have an unrealistic assumption about the language and technical understanding of their users which they translate into "users are stupid". To get a feel for how this feels consider the last time you took a car to be fixed and…

This is specific to FOSS project right? So "some Devs are clever; some devs are stupid" is more correct.

Joking aside, the (user) devs should provide as many information as possible per question since back-and-forth communication cause friction which resulted in their problem got resolved slower.

Also the (user) devs should self-reflect, isn't it annoying to receive bug report without adequate information?

Re: How to DOS a developer

#30
I think this illustrates why FOSS hasn't taken, and probably won't take the "mainstream" by storm.

Users communicating directly with developers is a nice idea that sounds good at first, but unfortunately it can't really work when

a) there are many orders of magnitude more users than developers

b) users are not technologically advanced enough to provide the developers with useful (and preferably only useful) information about the bugs

This means that developers are effectively DoS:ed to death when trying to directly support a piece of software with lots of non-tech-geek users. What could solve the problem would be a group of people between developers and users which could translate normal language to and from tech-speak, and evaluate the importance of different bugs. I guess this can be automated to some extent with bug-tracking software, but I don't think it's enough when the software in question has lots and lots of users.

Post reply on HN