
Does Not Work - jjuhl
http://importblogkit.com/2015/07/does-not-work/
======
ketralnis
This drives me crazy. I've worked with people that describe fully working,
well designed systems as "brittle" or "broken" or "don't ever use that"
because they found one edge case or bug in them. And they don't elaborate, so
when they sound so confident it discourages more junior engineers from using
those systems so they build their own which results in them building
_actually_ brittle, broken systems.

For a couple I've had to learn to blatantly ignore their recommendations. It's
is a real shame because if they've found bugs or edge cases then they probably
actually do have experience with it. If it were possible to get more than "it
sucks", they'd actually be great sources of experience and information but
instead their wolf-crying has relegated them to just being noise.

------
strken
I've found that "this doesn't work" usually means "I've spent the past three
hours on this and I want someone else to take a fresh look at it before I go
insane" with my co-workers. In the case where someone doesn't provide more
information because their brain is on fire and they're starting to get
stressed out about the problem, it's easier to just help them and trust
they'll do the same for you.

Having said that, with a team that's spent less time around each other, you
might not have that level of consensus.

~~~
coldtea
I've found that even QA people casually write "X feature doesn't work" in bug
reports, when they could give 10x more information, like: "the page stalls and
shows the spinner continuously", "the button is grayed out and I can't click
it", "the output is garbage letters", "the result is not the expected value",
etc.

~~~
ouid
They probably assume that the person whose job is to maintain the code can
more efficiently investigate the nature of the problem, provided they give
instructions on how to reproduce it.

~~~
nhgrif
How do we know whether or not we're properly reproducing whatever they're
seeing if we don't know what we're seeing?

I've seen scenarios where a set of reproduction steps actually showed two
things wrong. QA was sending it back for one of the things, but they didn't
say what was wrong, only that something was wrong and here's how to reproduce
it. The developer saw the other problem, and fixed it. The result when shipped
back to QA?

"You didn't fix the problem, but I opened a new defect now for the other thing
you broke."

------
conradev
> When programmers come to me and simply say “this code does not work,” I send
> them away. Their problem is not solvable by me or anyone.

When people come to me and say that, I ask "in what way doesn't it work?" and
figure out how to help them.

~~~
caconym_
Yeah.

I feel like if you really are working with people who are total caricatures of
cargo-culting code monkeys, and you see yourself as a Guru holding court and
suffering the wailing of ignorant petitioners only so long as they are able to
dig deep within themselves and _attempt_ to rise to Your level for the
duration of the conversation, you have only yourself to blame. Blogs posted
from high horseback are just masturbation (who knows, maybe you secretly
_like_ being surrounded by people who don't make you feel challenged).

In more reasonable language... if you have put yourself in the position of
being the most senior or most effective employee on your team by a very wide
margin, you are going to have this sort of experience. You can either try to
help the more junior/less effective folks improve themselves, or go find
something else, or just put up with it.

~~~
daveguy
> You can either try to help the more junior/less effective folks improve
> themselves, or

An article on the best ways to convey the answer to the question "in what way
does it not work" seems a good start.

Yes the tone is obnoxious, but the advice is good.

~~~
omginternets
I read his comment as pointing-out/caricaturing the obnoxiousness of the blog
post.

And frankly, I think he's right.

------
mastre_
Cuts both ways tho. There are developers (some good, most not) who are
notorious about not testing their code. "I don't know dude, it doesn't seem to
work -- did you test it?" is fair game in these cases, especially once a
pattern has been established. As in, why don't you look into it and figure out
why it doesn't work instead of asking me to do it for you? As in, letme-not-
googlethatforyou. Of course, depending on severity, action should be taken
right away to address this bad habit.

Re: "no hello", I'm not fully with it. Some developers enjoy a more human-like
interaction which doesn't play into the unfriendly programmer/BOFH stereotype.
Lack of testing will cost the company a lot more time and have more damaging
effects than people saying hi to each other (which could be argued to be worth
the little extra time it takes to play out):

    
    
      1. Dev commits untested code
      2. QA has to catch it
      3. QA has to fill bug report
      4. Dev not known for testing has to read bug report
      5. Dev not known for testing has to fix bug
      6. Dev not known for testing has to test reported bug
      7. Dev not known for testing has to commit fix
      8. QA has to look at again, and either approve/close or send back to step 3.
         - versus -
      1. Dev commits tested code
      2. QA tests change
      3. QA approves change
    

One pet peeve is people who ask "can I ask you a question?" \- this doesn't
have the same positive benefit as "hey, how's it going? how was your wknd?",
it doesn't seem to serve any purpose. I typically ask people, nicely, to just
ask the question directly next time and I'll answer when I'm able, if can't
right away. Especially in a chat-type environment in a
geographically/timezone-diverse team.

~~~
fenomas
> "can I ask you a question?" .. doesn't seem to serve any purpose

I think of it as a request for a context switch. If you're mentally occupied -
writing a tricky recursive function, say - and somebody walks up and says,
"Hey, what's the time complexity of inserts into a red-black tree", it's
likely that just parsing the question will kick you out of your current
context so you lose track of what you're doing.

~~~
ehnto
That is how it works for our team. Normally if someone skips that step it's
more urgent and I temd to answer (they have already asked and distracted me so
why not). I don't really mind pleasantries, they remind me I am working with
humans.

------
caddala
Here the discussion between two programmers is being compared to a car being
taken to a workshop (mostly to a person whom u dont interact with on a daily
basis)

When a programmer says to another programmer it "does not work", there is
usually some history between these programmers where they have some level of
understanding between them. This article kinda ignores that aspect.

I had never heard someone complain that it "does not work" when there is a
compilation error. That is just what a non-programmer or a beginner would say
who is trying to get attention for help. This example doesnt fit with the
point the article is trying to make.

When someone says it "does not work", it is usually followed by a long pause,
where the programmer is still wondering why it is not working. The other
programmer usually gets that and they patiently wait to hear the details or
ask questions because they had been there themselves.

It all boils down to what level the two programmers had worked together before
and having an idea of when someone would use such a phrase without giving any
explanation. Usually the other programmer already has a context of what might
not be working).

If your scenario does not fit with my explanations, all I can say is that, the
other people is stuck and needs some input or someone to challenge his
thinking to debug it better. If someone says that, all you have to do is reply
back saying "what do you mean?" and you will get flooded with information.

------
skeoh
> The phrase “does not work” should be reserved for when you’re taking your
> car to the mechanic and you don’t have a clue what’s wrong with it.

I might suggest that the phrase "does not work" is as irritating to mechanics
as it is to programmers. "Don't have a clue what's wrong with it" is clearly
not the case if you are taking a car to a mechanic in the first place -- you
surely have _some_ idea of what's wrong with it.

Certainly applies to other professions as well. As a rule of thumb, please
help others help you.

~~~
pedrocr
This reminds me of a programming discussion I saw a while ago where someone
came up with the "carpenters don't spend so much time being picky about their
hammers as we do our own tools" line. Which got a prompt reply by a carpenter
saying they indeed have very personal opinions about hammers and a whole
subthread on which hammers are best for which applications. Programmers think
they're way too special... :)

------
Tade0
> If you are experiencing a problem of the nature of one of the first two in
> that list (does not compile or has a run-time exception), then somewhere,
> you’ve got an error message or an exception, and probably even a line
> number.

Thing is, in this particular project I'm in - most of the time - you don't.

Since our project is an in-browser text editor most of our bugs occur because
the browser did something unexpected, like suddenly changed the selection, or
inserted an element somewhere. In situations like these you usually don't get
an error message or anything - just weird behaviour.

Normally our users report this by writing that pressing a button or using a
shortcut "does nothing" \- and that's fine.

When you're dealing with leaky abstractions on a day-to-day basis you sort of
have to get used to bug descriptions like these.

~~~
bastawhiz
Browser WYSIWYG editors are full of dragons. I'd give you that exception.

~~~
ehnto
Which is amazing since it's a problem we have been trying to solve for more
than a decade. I figure we just can't solve it fast enough to keep up with
browser features and bitrot.

I once built a wysiwyg editor that utilized drag and drop for dynamic page
content. Native browser drag and drop is an utter mess.

~~~
Tade0
Native selection, even if you don't support legacy browsers is a bigger one.

The API itself is ok. It's all the tiny differences between browsers that turn
it into a dumpster fire.

And don't get me even started on pasting stuff from Word. Customers expect
this to work, because yeah, how hard can this be really? Regardless of how
many safeguards you put, eventually someone somewhere is going to create a
file that will generate a heap of errors.

We have over 150 test cases(600+ unit tests) and _still_ every week something
pops up.

------
pepijndevos
> If you’re telling a programmer that a particular piece of source code simply
> “does not work”, then you should no longer consider yourself a programmer.

I found this article unnecessarily rude. Sounds like someone got grumpy after
answering too many SO posts. I agree with what others have said: If someone
says that, either they are inexperienced and you can teach them some useful
debugging skills, or their brain is on fire and you could try to be more
helpful than sending them away.

~~~
King-Aaron
Agree, I could barely stomach the article myself. If I asked someone for help
and they told me to go away, it would make me quite irate. It's a "holier than
thou" mentality.

------
todd8
Many years ago, in an engineering class, each of us was given an in class
exercise of describing something to the rest of the class that only one of us
could see in a box. We had to use physical properties only, color,
arrangements of geometric shapes, etc.

It made me realize the value of careful observation (looking at an old
fashioned black telephone with a dial in my case) and then careful description
of what I was seeing in terms that would communicate it to the others.

It's funny how often someone tells me their computer or some software is
simply not working. I guess I'm no better; I usually reply "Have you tried
turning it off and then on again." (A favorite line from the British comedy,
The IT Crowd.)

------
indifferentalex
I think this applies to cofounders and employers/bosses as well, if you're the
programmer and they are non-technical, and they come to you and simply state
"someone tried to do this thing and it didn't work" without giving you
anything to debug with, view it as a huge red flag indicating that they do
not, and do not want to, understand or appreciate your work and your time.

I've had this happen to me and after asking politely multiple times, and
explaining the need for communicating in a detailed and useful manner (that I
demonstrated), I would end up just getting angry when it would continue to
happen.

------
chris_overseas
This is a huge pet peeve of mine. I know competent developers who interrupt me
and simply say "X doesn't work". For the most part I appreciate that they're
just using the phrase as a conversation starter and they do have more context
to share. But why not share it in the first place? I either have to wait for
them to elaborate, or ask for more information. Either way, the verbal dance
just prolongs the interruption for no obvious benefit. I think of it in the
same way as someone messaging me saying "hey" or "are you there?". Genuine
question: am I being unreasonable/irrational to be frustrated by this?

~~~
endgame
Nope, and there's [http://nohello.com](http://nohello.com) to point people in
the right direction.

~~~
PhasmaFelis
> _The same goes for "Hello -- Are you there?", "Hi Bob -- quick question.",
> "Do you have a sec ?", "yt?" and "ping". Just ask the question!_

Actually, I'd prefer that coworkers don't start blowing up my phone/PC with
chat alert beeps for an extended question until they've confirmed that I'm not
in a meeting/trying to concentrate/etc.

~~~
douche
Alternatively, if you're in one of those not-available states, most IM clients
have some kind of facility to publish that availability...

~~~
cvs268
...and often people still send me the "Are U busy?" message despite my status
being busy.

I've started using the "Do not disturb" option in my Office Communicator when
am in important meetings. Using that option on the communicator makes it
impossible for someone to send me a message. Any attempts explicitly fail on
the sender's end with an error stating the obvious - The receiver has set "Do
not Disturb"

------
wruza
Heh. A lot of time ago we programmed and created systems for regular business
— accounting, automated workplaces, etc. It was all simple, but of course we
occasionally introduced bugs here and there, and sometimes an entire module
was built in a wrong way (specification errors). I will tell the rest from my
pov, because it applied to everyone in general.

For the first hundred of error reports I tried hard to get any information
beyond "nothing works" — yeah, not just something doesn't work, _nothing_
does. Phone line diagnostics were hard and both sides quickly tired because of
lack of understanding. Me and my client had different sets of terminology,
thinking styles and stereotypes. But as the time goes by, my remote-debug
skill grows.

And I started to get feedback. It was still inaccurate and often rough, but
two things could easily be noticed: 1) there still are people who won't help;
2) people who help have their own ideas on what's happening depending on their
[relatively tiny] computer knowledge. That started an era of the great
misunderstanding. As we easily exchanged clients in our tight company, we did
entire blocks and modules in wrong ways, based on information from incompetent
client. We did work that no one needs. We prepared for something, and it was
not there. And then I finally got why (partly) 1)-group exists. They just went
through all that a long time ago.

The fact is, whether does your client tell you what's happening, or does not,
you have to go there and have all of your tools and instruments and anything
you have with you. You _do not_ listen on their interpretations. You just go
there and say "show me". And only then you have all the information on what is
actually happening and where and who is in charge.

After we realized that, we stopped asking for any feedback. Literally. The
only two things we needed to know about the problem were 1) is that a "show
stopper"? 2) who encountered it. First one makes your weekly plan. Second one
gives a hint about a module name and its developer.

We stopped exchanging info from clients, intentionally. If I need someone to
make things for me, I just call and tell him to go to the place and solve
anything they need, without details. If I get a call, I just say ok, I'll be
there in two hours. That was _an improvement_.

So, if your client tells you "it doesn't work", just be happy that he doesn't
spend your time and be sure that you have remote desktop app or remote access
system enabled at his side.

------
jackweirdy
I spent a summer job in tech support, as I'm sure many on HN have at some
point. "It doesn't work" is such a frustrating piece of information to hear.
Especially when the reporter doesn't even tell you what "it" is, let alone
what they think working looks like.

~~~
ehnto
My favourite story of this I will never stop telling: digital marketing head
emails a support request, subject reads "please fix". Email contents? A
screenshot of her desktop on the home page of the website.

Turns out she was referring to a typo in a tiny article description and it was
of course so glaringly obvious to her that it needed no context.

------
nhgrif
Hey people, author here.

I've seen a lot of comments about the tone of the article or how this isn't
the best approach to take with someone who literally exhibits this behavior.
And if you take the post literally and from the point of view of the person
being asked advice, you're pretty much right (unless of course we're talking
about this strategy as a literal response to Stack Overflow posts).

In truth, this is not my literal approach when people come to me exhibiting
this behavior. I'm actually quite a lot nicer in person (believe it or not).
Really, this article was written with the hope in mind that it would be read
and shared with people who aren't particularly good at exploring the WHY of
"does not work". In fact, almost all of my articles are geared toward entry
level developers.

Anyway, I'm glad most of you seemed to enjoy it, and pretty much all of you
agreed that the overall sentiment of the post is good advice, even if you
didn't like the tone (which is perfectly fair).

------
lamontcg
This is also fairly common in user issues as well:

Broke my shit. Does not work. Sad! Fake Code!

(no example of how to reproduce it, no debug logs, nothing actionable that can
be done about it, just unproductive frustrated yelling into a bugtracker, user
disappears and doesn't respond to requests for any of the above)

------
King-Aaron
This article comes across to me like someone with no social skills bitching
about people who have social skills.

------
LeicaLatte
Teaching a lesson is always unnecessary and is often conflated with teaching
itself. Some of the bad team leads I work with do this. Some people are simply
incapable of teaching and have to rationalize it by enforcing protocols about
how one programmer has to approach another. I have always found it inhuman.

------
collyw
Much as I dislike Stack Overflow's zealous moderators, they are pretty good at
closing down questions worded this way.

------
grillorafael
Thank you for this blog post

------
ycmbntrthrwaway
(2015)

------
SparkyMcUnicorn
Nick, there's something broken on your website.

/s

