Does Not Work
importblogkit.com
importblogkit.com
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.
Having said that, with a team that's spent less time around each other, you might not have that level of consensus.
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."
Certain projects (e.g.: almost anything from the Java world) can be pretty overwhelming at first.
When people come to me and say that, I ask "in what way doesn't it work?" and figure out how to help them.
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.
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.
And frankly, I think he's right.
But sometimes the medium is the message.
- tiny little meaningless creature on a stone somewhere in universe
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
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.
Back when I was TA'ing a course in college, about half of the students on average in office hours would start their conversations with me by saying "I just have one small question." I'm not sure what was worse, when they didn't just have one question (or it wasn't small) or when the question was so small they could have gotten an answer by the time they finished assuring me that they weren't going to take up much of my time.
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.
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.
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.
I once built a wysiwyg editor that utilized drag and drop for dynamic page content. Native browser drag and drop is an utter mess.
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.
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.
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.)
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.
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.
Also, there are people change the status to 'busy' when they are not actually available, extended lunches and what-not. And there are more people who forget to reset their status to 'available'. So setting status to 'busy' is no guarantee that you will not get a ping. Or a phone-call.
I have seen the embarrassment on people's faces when in a meeting and their IM app starts beeping like a time-bomb after someone has cut the wrong-wire.
The sender sending a short 1 liner and waiting for acknowledgement before proceeding would prevent this. (results in a single beep if the receiver is busy)
Its also avoided if the sender simply sends their entire query as a single message. (again results in a single beep if the receiver is busy and doesn't reply)
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"
I often am interrupted by coworkers simply telling me "it doesn't work". Despite repeatably asking to be given more context from the get go, I am still regularly facing the "it doesn't work. dot. end of sentence.".
My answer often ends up being a clearly annoyed "Yes and so...??" hinting my interlocutor that I'm expecting more, and quickly. This is unfortunate since my annoyance can now be felt by the coworker in question, and potentially other people in the room.
This interaction happens as much in spoken conversation as it does in chats.
To add insult to injury, often times the reason why "it doesn't work" is contained in an error message that wasn't carefully (if at all) read.
I recently had to get up and go to the desk of one of my coworker telling me "it doesn't work". They were trying to connect to our MySQL server using a common macOS GUI client. Upon arriving at their desk I immediately knew what the problem was. I was baffled and frustrated that someone supposedly competent made me get up for this: "Unable to connect to host 172.20.0.100 because access was denied.
Double-check your username and password and ensure that access from your current location is permitted.
MySQL said: Access denied for user 'admin'@'172.20.0.1' (using password: YES)". I had to ask my coworker to read the message out loud, only then did he realize his mistake (it doesn't work, because the password is wrong...).
Although this example is extreme, my day to day life is made of many, less extreme, instances of this kind of interaction that are wasting my time. A benign as it can seem, this contributes a lot to my stress and frustration.
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.
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.
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).
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)
/s