Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> Most bugs are just annoying, consequences are not catastrophic if your favorite tuner app forgets your settings, your word processor messes up the formatting, your pdf reader crashes.

So what? Users get upset when your crap doesn't work. Stop being flippant and pushing back. Pushing back is not your (our) job. Complaining how hard your job is not your job. Griping and moaning about irate users is also not your job. Delivering a product that does what is says it will do on the tin is actually your job. Believe it or not, you produce something people depend on!

Imagine your power steering goes out on left hand turns going north downhill. You take it into the mechanic and all you get is "That's just annoying, not catastrophic. You can recover with just some wasted time. It's exponentially more difficult to make the implementation actually bug free!"

Users quite rightly spot bullshit excuses. And we have none. Save the settings, fix the formatting, stop the crashing.



> Pushing back is not your (our) job

Please tell me more about my job internet stranger.

You’re making the same arguments without adding substance, just emotional rhetoric and unnecessary personalizing.

> Imagine your power steering goes out on left hand turns going north downhill.

Imagine that steering wheel stopped working depending on the highway you’re driving on (software & hardware platform). Why didn’t they test this on every single highway? Because that would be was combinatorially explosive.

I’m glad you’re making a physical world analogy. Comparable physical world projects have orders of magnitude less moving parts that need to interfit, and assembly gives immediate feedback whether they can fit. They also have orders of magnitude less inputs they are expected to operate on, which makes it easier to exhaustively test their function.

“Shut up and just make it work” might have been popularized by certain tech personas, but unless you have Steve Jobs levels of clout, pulling that stuff in most dev shops will quickly make you very unpopular whether you’re a IC, a manager or a product manager.


> Imagine that steering wheel stopped working depending on the highway you’re driving on (software & hardware platform). Why didn’t they test this on every single highway? Because that would be was combinatorially explosive....

Users guffaw at this point. They do not understand why your stuff is so complicated and broken. They think you suck at your job. Both you in the collective sense (you engineers) and you in the personal sense. They start plotting ways to stop using your stuff because you are so frustrating to deal with.

> They also have orders of magnitude less inputs they are expected to operate on, which makes it easier to exhaustively test their function.

I think you still do not understand my point. Users fundamentally do not care about it. Everything, to them, is a problem of your creation and they'd quite rightly regard your long-winded explanations with complete skepticism. To you it always feels likes it's someone else's fault, but to users it sounds like complete BS. No matter how right you are about it being someone else's fault. Someone else's fault is the very definition of a lame excuse from their perspective. They are still getting nowhere and you are even more useless to them because you still can't fix anything and just confuse them and waste their time.

It's a very user-hostile attitude and makes for terrible customer relations. That attitude is also counter productive and helps no one. No wonder people hate tech.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: