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.
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.
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.
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.
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."
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.
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.
> "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.
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.
I find that for me, "Hey are you busy?" is enough to drag me out of my focus. At that point you may as well ask me about the time complexity of red-black tree inserts. That way I get the request over with and back to what I was doing.
> One pet peeve is people who ask "can I ask you a question?"
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.
I could see myself getting annoyed if it's a student I have never seen before. I absolutely adore and love it when the same students come to office hours every time. For some reason, it makes me very content and happy, and it's just such a pleasure to see eager students utilizing resources like that. Those students, I am much more casual with, and couldn't care less if they talk to me on that meta "can I ask you a question?" level.
I didn't really mind it that much, I mostly found it amusing that students were so worried about taking up too much time that they'd end up taking more. And you're right, if it was one of the regulars, I definitely didn't mind, and I'd sometimes tease them mildly about it.
I experienced the "can I ask you a question?" when I did that in office hours. My usual response is "Yes, what did you think I was here for?" After two or three times they just learned to ask the questions directly.
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.
> 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.
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... :)
Yeah, although it was kind of a throwaway comment/joke, I still agree that that was a poor example given the context. Most of the same techniques for clearly identifying a problem apply identically to vehicles. IE, does it not start? Are you getting a check engine light? Is it not performing the way you expect?
> 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.
reporting that a particular button "does nothing" is a great bug report (from a user. from a colleague it's a little disappointing). It tells you the three important things you need for a bug report : what did you do, what did you expect, and what actually happened?. The problem with "doesn't work" is that it could mean anything, from "does nothing" to, to use the example in the article, "it launches missiles".
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.
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.
Sounds like you need a managed runtime. Wait... You already have one, it's just a bigger problem than solution. Hrm... Have you considered making a real IDE?
> 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.
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.
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.)
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.
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?
> 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.
...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"
i think the point was to avoid incessant beeping due to multiple short sentences.
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)
In my opinion, that's a bug in most chat apps. Multiple messages in succession from the same sender should only beep once. But I realize most people use restrictive apps, so they have to adapt to them rather than the other way around.
Because I am available for certain questions. I am available for
"quick" questions which only I would know the answer to, and for critical questions. I want to defer "easy" questions which the questioner can easily find the answer to, but is lazy or incompetent.
In my role, I will get questions from downright simple "how do I reset my password", or was a certain move-to-production done; to some really critical ones, or, where others move on my go-ahead. The move-to-production query means different things based on who is asking. One person asks only because a end-user or their manager wants to know the status. Another person is asking that as a start of "we are seeing something strange in production" on a related functionality. So, I ignore the first person when actually busy, and attend to the second person right away always.
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 still don't understand why you'd prefer a "hello" message in that context. If you're able to take quick questions but are working on something else, isn't it better to get the question in the initial message so you can decide if it's quick or deferable with minimal back and forth?
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.
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.
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.
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.
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).
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)
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.
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.