Live data from Hacker News

Developers are attached to tools because tools encode trust

stackoverflow.blog

91–100 of 148 posts

Re: Developers are attached to tools because tools encode trust

#91

This article is a bit rambly so I'll just focus on some things from the beginning: >If your kitchen knife kept changing shape, weight, and edge, you’d have to relearn it every time; that’s a hard tool to build trust in. This concept was betrayed far before agentic tools, with a much earlier concept: Automatic updates. To use one product as an example: When Windows ME and Windows Vista came out, people hated them even…

> its UI doesn't change unless I tell it to change

Vim and emacs aren't unique in this. In fact quite a few non-commercial FOSS projects don't make significant changes to the UI. I think there are (at least) a couple of reasons for that. First, there isn't usually pressure to constantly attract new users, so there isn't as much pressure to change the UI to make it easier or simpler for new users, or follow UI trends. Secondly, the projects often don't have dedicated UI/UX designers who want to try out new ideas or make their mark, etc.

However, these aren't strictly good things, you can end up with an unintuitive UI with a steep learning curve that is hard to learn.

Re: Developers are attached to tools because tools encode trust

#92

Earlier quoted context omitted.

Crazy amount of effort when you can just use a different harness and a better and cheaper model.

"Cheaper" compared to API prices, right? I've run the numbers and the frontier subscriptions are still the best option. 100% usage every week is a truly absurd amount of value. Unfortunately the subscriptions can't be used outside the official harnesses.

Both API and subscription prices are cheaper with all other models and providers compared to Anthropic.

GPT is also better than Claude from my personal experience. GLM 5.2 is equal and Kimi K3 is better.

But I mostly use Deepseek and pay api prices.

Re: Developers are attached to tools because tools encode trust

#93
post #71

This article is a bit rambly so I'll just focus on some things from the beginning: >If your kitchen knife kept changing shape, weight, and edge, you’d have to relearn it every time; that’s a hard tool to build trust in. This concept was betrayed far before agentic tools, with a much earlier concept: Automatic updates. To use one product as an example: When Windows ME and Windows Vista came out, people hated them even…

> Vim is one major exception to the automatic update problem. Except for one thing that pissed me off a great deal. I am not a true vim user, though I use it from time to time, because it is everywhere and it works through ssh. At some point they introduced "visual mode", and it turns on when you start using the mouse, it broke the way I used the mouse copy-paste in vim. I know I can do "set mouse-=a", but when I am…

I think visual mode has existed as long as vim existed, and vi was what didn't have it.

When I first started at my company, we did all work on shared VMs, and the system vimrc had that "mouse" setting enabled. Something an employee had done decades ago to be helpful, really confused me until I realized what was going on. I'm thinking your distro, not vim, is what flipped the setting.

Re: Developers are attached to tools because tools encode trust

#94
post #80

Earlier quoted context omitted.

I’ve seen this too and it’s darkly humorous. We published 1-2 releases of our component each month. Eventually another (internal) team would pick it up along with others, test, and release the combined set maybe 1-2 times a year. Customers being extremely risk adverse never wanted to update, due to risk of changes combined with the interruption, even though we were fixing serious bugs left and right from the earlier…

> Customers...never wanted to update, due to risk of changes [...] We’d get escalations on things that were fixed years ago [...] as upstart competitors stole [our] market share. This is so weird to me, though. Your customers had two choices: 1. Stay with your software and upgrade to the latest version, where the bugs they were hitting were fixed, and risk some amount of retraining due to UI/UX changes. 2. Switch to…

You are assuming the changes would all be positive, minus some UI hassle. I have seen plenty of products where vital workflows were scrapped entirely or made significantly more clunky.

Modern software is quicksand. Maybe an update improves things, but users have all experienced working software made worse.

Re: Developers are attached to tools because tools encode trust

#95
post #81

Earlier quoted context omitted.

This is exactly what I said to the last company (which is basically shutting down now lol) management - "infinite customizeability" means "zero percent understandability" for a typical suite of software. I literally was told not to narrow down the features too much or the product would be too constrained... well then wtf does it actually _do_ for anyone?

I don't think infinite customizeability is a problem. Poor default configurations are the problem when you build in the ability to customize. The idea is that the user should be able to be productive more or less immediately after installing the software, and then incrementally customize it as they discover they have different needs than the defaults give them. A lot of developers/companies forget the first part, and…

What mythical software is this? The only infinitely customizable software I can think of is emacs, and that takes an enormous amount of effort to become proficient.

Re: Developers are attached to tools because tools encode trust

#96
post #61

This article is a bit rambly so I'll just focus on some things from the beginning: >If your kitchen knife kept changing shape, weight, and edge, you’d have to relearn it every time; that’s a hard tool to build trust in. This concept was betrayed far before agentic tools, with a much earlier concept: Automatic updates. To use one product as an example: When Windows ME and Windows Vista came out, people hated them even…

That's not just developers as you noted. It is "velocity fallacy" — product people want "all the features ASAP or right away". Until users with their managers come with pitchforks and torches. I worked on such internal project where we as developers were able to deliver new features and new version every 2 weeks (which is not a pinnacle of the game of course) and were thinking if we can move to daily delivery. Becaus…

[flagged]

Re: Developers are attached to tools because tools encode trust

#98

This article is a bit rambly so I'll just focus on some things from the beginning: >If your kitchen knife kept changing shape, weight, and edge, you’d have to relearn it every time; that’s a hard tool to build trust in. This concept was betrayed far before agentic tools, with a much earlier concept: Automatic updates. To use one product as an example: When Windows ME and Windows Vista came out, people hated them even…

Your view of what constitutes a tool is overly broad. An OS is not a tool. A hand plane is a tool. It’s sharp and does one thing. The stuff an OS does might enable tools, and it may contain many tools, but it is not itself a tool.

Re: Developers are attached to tools because tools encode trust

#100
post #98

This article is a bit rambly so I'll just focus on some things from the beginning: >If your kitchen knife kept changing shape, weight, and edge, you’d have to relearn it every time; that’s a hard tool to build trust in. This concept was betrayed far before agentic tools, with a much earlier concept: Automatic updates. To use one product as an example: When Windows ME and Windows Vista came out, people hated them even…

Your view of what constitutes a tool is overly broad. An OS is not a tool. A hand plane is a tool. It’s sharp and does one thing. The stuff an OS does might enable tools, and it may contain many tools, but it is not itself a tool.

A food processor is a kitchen tool even though it does many things.

A computer is also a tool that does many things and the OS is arguably the important part of how a user wields that tool.

Post reply on HN