

How to DOS a developer  - emarcotte
http://who-t.blogspot.com/2011/03/how-to-dos-developer.html

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

------
sambeau
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 had to talk to the mechanic, or the first time you took clothes to
be dry-cleaned. It feels belittling, doesn't it?

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

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

------
kgtm
"How to Disk Operating System a developer?"

Oh come on. It's DoS. Pretty please? Not respecting capitalization is
definitely a way to DoS a developer...

~~~
mahmud
Yeah, if you're gonna right a smug article about your profession, at least get
the lingo write.

~~~
kgtm
I see what you did there...

------
goodside
"Be verbose. As verbose you can be. If you can say something in one sentence
or three paragraphs (with three overlapping or identical examples), choose the
latter. Searching for signal in lots of noise is a favourite pasttime of many
developers."

Pot, kettle, black, etc.

~~~
arkitaip
I think he was making an example.

~~~
stcredzero
At one shop I worked at, the devs just started filtering the output of one
tester to the trash. Not that she didn't have something useful to say. It just
wasn't worth dealing with the other 99 posts that were noise.

------
mathnode
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!"

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

------
jrockway
This DOS is easy to fix. Just ignore the person.

I find the following things quite easy to do: not replying to random emails,
ignoring stuff on irc.

~~~
wladimir
Even better solution: ask to be paid for (non developer-to-developer) support.
The best way to prevent DOS is to have a price. Not that it makes interacting
with such jerks fun, but at least you get something in return.

------
shib71
If anyone wants to contribute to a FOSS project but aren't confident about
their coding chops: fleshing out bug reports and clearly defining their scope
will make a HUGE difference.

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

------
tybris
Oh they're so sensitive these "developers".

