61–67 of 67 posts
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)
Earlier quoted context omitted.
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 mastu…
> 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.
But sometimes the medium is the message.
Earlier quoted context omitted.
Browser WYSIWYG editors are full of dragons. I'd give you that exception.
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.
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.
> 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,…
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?
Nick, there's something broken on your website. /s
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).
Earlier quoted context omitted.
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.
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."