Why, after a year with Adobe EchoSign, I’m taking my business elsewhere • Hacker News Board

Re: Why, after a year with Adobe EchoSign, I’m taking my business elsewhere

#51

Post by mreiland » Sat, May 02, 2015, 7:01 AM UTC

mark-r wrote: post #43

mreiland wrote: post #42

Earlier quoted context omitted.

Are you implying it's a matter of getting your customers to use their brain? I freelance and therefore I can be a jackass without direct monetary repercussions, perhaps that's why I don't view it that way. Because I struggle to think of a lot of situations where I've been unable to replicate an issue a Client has reported where it hasn't turned into a miscommunication/misunderstanding of some sort.

No, not at all! If you've been in the business long enough, you learn that people have different preferred ways of working. Some will use menus, some will use icons. Some will use keyboard shortcuts. Some will use drag-and-drop. If the bug description doesn't specify how they performed an action, and you assume your preferred way while they used another, you can easily be unable to replicate their problem. I don't re…

I misunderstood you, I thought you were implying customers needed to use their brain, but looking closer you did say keyboard and mouse and not keyboard and chair :)

I personally see it all the time, but I interact directly with my customers and it's always possible I'm terrible at communication. They'll say things like "X doesn't work on page Y", and It'll end up being a problem with a single link they clicked on because the data for it is such that it causes a problem (that sort of thing).

They don't know that's the issue either, you have to work with them on it.

Re: Why, after a year with Adobe EchoSign, I’m taking my business elsewhere

#52

Post by m_mueller » Sat, May 02, 2015, 8:38 AM UTC

chx wrote: post #5

Jemaclus wrote: post #2

One of the biggest pieces of advice I have for junior devs (and software engineers in general) is actually quite simple: Remove the phrase "it works for me" from your vocabulary. The rationale is equally simple: I wouldn't take the time out of my day to send a bug report if it "worked for me." The problem could be any number of things: buggy code, incorrect instructions, browser incompatibilities, race conditions. Wh…

> Was the user mistaken? 99999 out of 100000 yes. Sorry but most bug reports, even from QA departments are noise at best, nuisance at worst. And as I posted here before: I am close 40, have 15 years experience as a professional in this industry, I have seen it all and yes it gets harder for you to break through to me because I will presume you have no clue what you are doing because so many before you didn't. Sorry i…

> 99999 out of 100000 yes

If there's one thing I can't stand then it's people spewing fantasy numbers out of their ass without anything to back them up in order to give their argument some conjured up weight. You may well be right that a majority of bug reports are unhelpful, but please, if you need to use numbers, use ones you can back up with something.

Re: Why, after a year with Adobe EchoSign, I’m taking my business elsewhere

#53

Post by tomjen3 » Sat, May 02, 2015, 11:27 AM UTC

Jemaclus wrote: post #2

One of the biggest pieces of advice I have for junior devs (and software engineers in general) is actually quite simple: Remove the phrase "it works for me" from your vocabulary. The rationale is equally simple: I wouldn't take the time out of my day to send a bug report if it "worked for me." The problem could be any number of things: buggy code, incorrect instructions, browser incompatibilities, race conditions. Wh…

That is nice in theory, in practice many, many users are stupid (for the lack of a better word) and the bugs they report are exactly how the program is supposed to run, or caused by things that we cannot reasonably deal with, typically client computers that are too underpowered and have too much adware installed.

Re: Why, after a year with Adobe EchoSign, I’m taking my business elsewhere

#54

Post by Jemaclus » Sat, May 02, 2015, 5:22 PM UTC

mak4athp wrote: post #14

Jemaclus wrote: post #2

One of the biggest pieces of advice I have for junior devs (and software engineers in general) is actually quite simple: Remove the phrase "it works for me" from your vocabulary. The rationale is equally simple: I wouldn't take the time out of my day to send a bug report if it "worked for me." The problem could be any number of things: buggy code, incorrect instructions, browser incompatibilities, race conditions. Wh…

If an organization is having developers triage vague bug reports directly from end users, they're already in trouble. Not only are developers a very expensive resource, they're generally not good at doing what you describe here. Nor are they usually well set up for it as their systems/devices are often tainted with development and debugging tools. We can't make end users deliver bug reports that are detailed and repr…

I think you're taking my post a little bit literally. The "customer" doesn't always have to be the end-either. If a QA member comes to me and says they found a bug, I also should not just go back to them and say "It works for me" and then not proceed any further. (Although, in defense of the literal interpretation of "customer", for small startups, devs often double as customer support for engineering-related issues.)

Re: Why, after a year with Adobe EchoSign, I’m taking my business elsewhere

#55

Post by Jemaclus » Sat, May 02, 2015, 5:27 PM UTC

mak4athp wrote: post #15

chx wrote: post #5

Earlier quoted context omitted.

> Was the user mistaken? 99999 out of 100000 yes. Sorry but most bug reports, even from QA departments are noise at best, nuisance at worst. And as I posted here before: I am close 40, have 15 years experience as a professional in this industry, I have seen it all and yes it gets harder for you to break through to me because I will presume you have no clue what you are doing because so many before you didn't. Sorry i…

Deciphering bad bug reports is absolutely a waste of your time as a developer, but that doesn't imply that the user is mistaken. In nearly all cases, the user is correct in sensing a bug but incorrect or inarticulate in their description of it. It's almost always a good idea to understand what's behind the report. It's just that somebody in a different role should be doing most of that work.

Small startups are often just a handful of people, and devs can and do pull double-duty as QA and development, and sometimes customer support for engineering issues! Freelancers also don't have customer support teams. For larger orgs, however, you're right. And also, like I said in another comment, the "customer" doesn't have to be your customer -- your "customer" could be the QA guy who says he found a bug, or your boss, or another engineer. Whoever tells you they found a bug, you should not dismiss their report with "well, it works for me."

Re: Why, after a year with Adobe EchoSign, I’m taking my business elsewhere

#56

Post by mak4athp » Sat, May 02, 2015, 6:35 PM UTC

Jemaclus wrote: post #54

mak4athp wrote: post #14

Earlier quoted context omitted.

If an organization is having developers triage vague bug reports directly from end users, they're already in trouble. Not only are developers a very expensive resource, they're generally not good at doing what you describe here. Nor are they usually well set up for it as their systems/devices are often tainted with development and debugging tools. We can't make end users deliver bug reports that are detailed and repr…

I think you're taking my post a little bit literally. The "customer" doesn't always have to be the end-either. If a QA member comes to me and says they found a bug, I also should not just go back to them and say "It works for me" and then not proceed any further. (Although, in defense of the literal interpretation of "customer", for small startups, devs often double as customer support for engineering-related issues.…

There's a real difference between a Customer and a QA member, though. You can't demand leave the responsibility to make a good report on a customer because they're external to your organization. But you can do exactly that with the QA member because it's precisely their job to identify and describe defects.

You can indeed say "it works for me" to the QA member, and it's their responsibility to identify the environment or series of steps that reliably produce a failure. From there on out, you can no longer say "it works for me" because it doesn't: you finally know how to make it fail and now it's your job to figure out why.

And like I said, nascent startups with just a few founding engineers are a necessary exception. But the QA or Customer Support hire should come very early! Too many organizations stall on that, and they waste tons of opportunity and productivity by doing so.