868
OneDrive disguising the "Buy now" button using the Cancel color scheme
(programming.dev)
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
this post was submitted on 15 Dec 2023
868 points (96.9% liked)
AssholeDesign
6776 readers
1 users here now
This is a community for designs specifically crafted to make the experience worse for the user. This can be due to greed, apathy, laziness or just downright scumbaggery.
founded 1 year ago
MODERATORS
Why include software engineers in this? In the large companies I've worked for, the people with the title "software engineer" have absolutely nothing to do with the actual design of something like this; we just get handed a spec and are expected to implement it as is. In smaller companies I always did one-person projects where I handled every aspect of the development process including UX and UI, but my title was not "software engineer". Are you expecting the engineers to refuse to implement a "feature" like this on principle or something?
The title's meaning and weight can vary. So can the responsibilities and impact of an individual engineer's decisions. But there is a longstanding tradition of engineers as gatekeepers for quality and the ethical application of their skills.
For instance, licensed engineers in Canada have a duty to the following code of ethics. To quote the header:
That's why in Canada virtually everyone is a "Software Developer". Same job across in the state you'll be called an "engineer".
Yes. Or at least question it.
Just like I'd expect a civil engineer to question the plans for that bridge they're building if it seems like it's not up to spec.
Or like I'd expect an electrical engineer to revise the plans for a circuit that poses an electrocution risk.
Why would software engineers be held to a different standard?
I'm a software dev. Given, the shit I work on right now is all internal. But I question the hell out of stupid decisions like this. I'm sure things get questioned on these public-facing apps all the time. But at the end of the day, the business gets what the business wants. Inevitably, we don't have the final say on it, even if/when we push back. And we definitely do.
We should be holding the execs and business leaders that are making these stupid decisions accountable.
Software Engineers are workers and as such hold all the power
I see you never worked in a developer team. My current boss once in 1995 opened a geocities page about someones poodle and favorite girl-band. After 3 minutes on that page he proudly declared "I now know everything there is to know about HTML and user interface design, and never have to see another website ever again!"
Since then, he is making designs, and the tiniest amout of criticism or improvements ("maybe we should have a placeholder telling users what format we expect here.", "Can we use a date-input instead of a textfield here?") is shot down with a 5 minute yelling how "the users just have to learn this" and "we always have done it this way!" or "if the user is too stupid, he should read the manual" (which is incomplete and still features windows XP+IE6 screenshots). There is an option in the bug tracking system which says "user error/user training required", but if you read it it's really all huge usabillity issues because people cannot figure it out, and the system has no helpfull error messages...
We did something similar with our APIs. It broke every conventions and expectations of the product and the language, and of course didn't follow any logical good practices. Man did the boss love to tell me users had to read the doc anyway so we might just as well do whatever. Then later on when issues arose and I suggested making better APIs I was hit by some dull remark about how we shouldn't violate the principle of least-surprise by going a different direction. Bitch are you kidding me? You broke that very principe in the first place by making grotesquely alien APIs.