Most active commenters
  • duxup(5)
  • hobs(3)

←back to thread

Free software scares normal people

(danieldelaney.net)
917 points cryptophreak | 13 comments | 30 Oct 25 15:07 UTC | HN request time: 0.021s | source | bottom
Show context
squeedles ◴[30 Oct 25 16:12 UTC] No.45761639[source]▶
Good article, but the reasoning is wrong. It isn't easy to make a simple interface in the same way that Pascal apologized for writing a long letter because he didn't have time to write a shorter one.

Implementing the UI for one exact use case is not much trouble, but figuring out what that use case is difficult. And defending that use case from the line of people who want "that + this little extra thing", or the "I just need ..." is difficult. It takes a single strong-willed defender, or some sort of onerous management structure, to prevent the interface from quickly devolving back into the million options or schizming into other projects.

Simply put, it is a desirable state, but an unstable one.

replies(22): >>45761688 #>>45761787 #>>45761946 #>>45762556 #>>45763000 #>>45763132 #>>45763419 #>>45763515 #>>45764215 #>>45765589 #>>45766183 #>>45766281 #>>45768514 #>>45769691 #>>45771196 #>>45771307 #>>45771846 #>>45772026 #>>45773411 #>>45773951 #>>45776266 #>>45779651 #
duxup ◴[30 Oct 25 18:09 UTC] No.45763132[source]▶
It always amazes me how even just regular every day users will come to me with something like this:

Overly simplified example:

"Can you make this button do X?" where the existing button in so many ways is only distantly connected to X. And then they get stuck on the idea that THAT button has to be where the thing happens, and they stick with it even if you explain that the usual function of that button is Y.

I simplified it saying button, but this applies to processes and other things. I think users sometimes think picking a common thing, button or process that sort of does what they want is the right entry point to discuss changes and maybe they think that somehow saves time / developer effort. Where in reality, just a new button is in fact an easier and less risky place to start.

I didn't say that very well, but I wonder if that plays a part in the endless adding of complexity to UI where users grasp onto a given button, function, or process and "just" want to alter it a little ... and it never ends until it all breaks down.

replies(7): >>45763322 #>>45763345 #>>45764270 #>>45764775 #>>45765654 #>>45766997 #>>45771204 #
1. graybeardhacker ◴[30 Oct 25 20:12 UTC] No.45764775[source]▶
I always tell clients (or users): "If you bring your car to the mechanic because it's making a noise and tell them to replace the belt, they will replace the belt and you car will still make the noise. Ask them to fix the noise."

In other words, if you need expert help, trust the expert. Ask for what you need, not how to do it.

replies(2): >>45765143 #>>45766520 #
2. nerdponx ◴[30 Oct 25 20:49 UTC] No.45765143[source]▶
If you tell the mechanic "my car is making a noise, fix the belt please" and then they just fix the belt, that's on the mechanic as well.
replies(2): >>45765633 #>>45766177 #
3. duxup ◴[30 Oct 25 21:32 UTC] No.45765633[source]▶
I would hope the mechanic would engage with the customer in more back and forth.

But sometimes power structures don't allow for it. I worked tech support in a number of companies. At some companies we were empowered to investigate and solve problems... sometimes that took work, and work from the customer. It had much better outcomes for the customer, but fixes were not quick. Customers / companies with good technical staff in management understood that dynamic.

Other companies were "just fix it" and tech support were just annoying drones and the company and customer's and management treated tech support as annoying drones. They got a lot more "you got exactly what you asked for" treatment ... because management and even customers will take the self defeating quick and easy path sometimes.

4. estimator7292 ◴[30 Oct 25 22:32 UTC] No.45766177[source]▶
It's a hypothetical to communicate an entirely different point. The mechanic is't real or important.
5. rkunal ◴[30 Oct 25 23:14 UTC] No.45766520[source]▶
It is a common misconception that the "expert" knows the best. Expert can be a trainee, or may be motivated to make more for its organisation or have yet to encounter your problem.

On the other hand, if you are using your car for a decade and feel it needs a new belt - then get a new belt. Worst case scenario- you will lose some money but learn a bit more about an item you use everyday.

Experts don't have your instincts as a user.

replies(2): >>45766995 #>>45767302 #
6. bigglywiggler ◴[31 Oct 25 00:18 UTC] No.45766995[source]▶
I am a qualified mechanic. I no longer work in the field but I did for many years. Typically, when people 'trust their instincts as a user' they are fantastically wrong. Off by a mile. They have little to no idea how a car works besides youtube videos and forum posts which are full of inaccuracies or outright nonsense and they don't want to pay for diagnosis.

So when they would come in asking for a specific part to be replaced with no context I used to tell them that we wouldn't do that until we did a diagnosis. This is because if we did do as they asked and, like in most cases, it turned out that they were wrong they would then become indignant and ask why we didn't do diagnosis for free to tell them that they were wrong.

Diagnosis takes time and, therefore, costs money. If the user was capable of it then they would also be capable enough to carry out the repair. If they're capable of carrying out the diagnosis and the repair then they wouldn't be coming to me. This has proved to be true over many years for everyone from kids with their first car to accountants and even electrical engineers working on complex systems for large corporations as their occupation. That last one is particularly surprising considering that an engineer should know the bounds of their knowledge and understand how maintenance, diagnosis and repair work on a conceptual level.

Don't trust your instincts in areas where you have no understanding. Either learn and gain the understanding or accept that paying an expert is part of owning something that requires maintenance and repair.

7. hobs ◴[31 Oct 25 01:08 UTC] No.45767302[source]▶
If you don't trust the expert then why are you asking them to fix your stuff? It's a weird idea that you'd want an idiot to do what you say because you know better.
replies(2): >>45768531 #>>45771318 #
8. aidenn0 ◴[31 Oct 25 04:47 UTC] No.45768531{3}[source]▶
In this case, it's at least partly because the expert has access to a lift...
9. duxup ◴[31 Oct 25 12:32 UTC] No.45771318{3}[source]▶
If they're asking the mechanic to do X and they understand the mechanic is just doing X and NOT venturing to fix your problem. I guess that is fine.

I agree though it sets up a weird dynamic where folks might come back to the expert and complain a problem isn't fixed, but that's not what they asked for / they broke the typical expert and customer dynamic.

replies(1): >>45771528 #
10. hobs ◴[31 Oct 25 13:02 UTC] No.45771528{4}[source]▶
In my experience the best thing is to then convince the expert you are right, using your own expertise.

If your mechanic is too stupid to recognize the problem after you explain it then you don't have a mechanic, the set of hands you are directing is basically unskilled labor.

replies(1): >>45771673 #
11. duxup ◴[31 Oct 25 13:18 UTC] No.45771673{5}[source]▶
How do you know you're right if you haven't fixed it?

That seems like a way to just be a stuck in the mud and wrong the whole time.

replies(1): >>45772431 #
12. hobs ◴[31 Oct 25 14:37 UTC] No.45772431{6}[source]▶
exclude the impossible and what is left however improbable must be the truth
replies(1): >>45774028 #
13. duxup ◴[31 Oct 25 16:43 UTC] No.45774028{7}[source]▶
If we're still talking about an amateur doing it, isn't their understanding of the possibilities petty limited?