Live data from Hacker News

Developers are attached to tools because tools encode trust

stackoverflow.blog

121–130 of 148 posts

Re: Developers are attached to tools because tools encode trust

#121

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?

OTOH, there's spreadsheets. The abstraction is just so great that users can and do use them for anything. The problem seems to be that there's not many such great abstractions to be found.

But parent is still correct on "zero percent understandability".

I have seen dozens upon dozens of Excel sheets which "just worked" until they didn't and then of course person who could fix that left company 10 years ago.

Besides I also know dozens of people whose life would be easier if they would learn a bit more of Excel like pivot table is there for them.

Re: Developers are attached to tools because tools encode trust

#122
post #7

Im typing this in GVim thanks to Tridactyl using my new mechanical keyboard running a ZMK firmware I just built via Github actions (or directly via ZMK Studio). This is ridiculously complex to just type a few paragraphs. Nobody in their right mind would invest this amount of yak shaving... and yet I do so because I bet, rather confidently, that in few years, heck few decades, all those tools will be different (or may…

> typing this in GVim thanks to Tridactyl

Thanks for the heads-up that such a thing is possible. I will definitely be investigating it.

Re: Developers are attached to tools because tools encode trust

#123
post #2

I have to admit, I asked ChatGPT to do a TLDR summary because I found the writing meandered quite a bit. I think the overall point is sound: > "Developers become attached to tools like Vim, Emacs, or an IDE because years of experience make those tools predictable extensions of their thinking. The attachment is less about features and more about accumulated trust, muscle memory, and a workflow built around known bound…

> I'll get the equivalent 40 hours of work done in 8 hours.... Then I'll start using the application... and I'll start to see that it's broken all over the place in very surprising ways

I would say that this means that it only appeared that you got 40 hours of work done.

> I'm sure someone is going to be like "BRUH AUTOMATED TESTS" or "BRUH MODEL CHOICE". I have a LOT of automated tests, and I don't like fussing with models so I pretty much use Opus on high reasoning for most things (or the equivalent from other providers).

Bruh, manual tests. It shouldn't be an entire day until you "start using the application more directly". It's rare that you really know what you want until you try something that isn't what you want, and figure out what's wrong with it. LLMs aren't privy to your thought patterns, so they can't help with that.

Re: Developers are attached to tools because tools encode trust

#124
post #78

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?

Just up thread from your comment, someone commented in a positive way on the infinite customisability of vi. So which is preferable - customisability or very limited feature set?

Question is: what are you building?

There is no general answer that will answer which is preferable.

It is easy for people to come up with features they want or a customisation and they don't care for the cost of actually maintaining that feature or customisation.

I work on building SaaS platform, we had multiple customers for whom we build custom features and they paid for development of those features. Not fun part is after 2-3 years those customers are gone (for example employees at customer rotated and they switched to something totally different) — but now we are left with dead feature no one is paying for supporting, some are easy to remove, some are not.

Re: Developers are attached to tools because tools encode trust

#125

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…

A big driver of automatic updates in the late 00s and early 10s were people who never updated their OS or browser and were getting compromised left and right. As I recall, one of the earliest widespread users automatic updates was Google with Chrome, which they did because otherwise there was no way to respond to severe 0days and such before huge swathes of users got hit. So I think there's a place for automatic upda…

Yeah people never wanted to update Windows since they had been burned in previous upgrades and their current setup just worked. Not only were upgrades difficult to do and took a long time, many times the new version was just worse or requires relearning lots of things. For what, asked the normal user?! But MSFT tied IE browser updates to OS updates just to make things so much worse for those people since now their choice was to either upgrade and have to deal with the distress of your UI changing, or be vulnerable to widely known exploits in your outdated browser.

My late dad preferred to not upgrade at any cost to the end!

Re: Developers are attached to tools because tools encode trust

#126

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…

As a data point: I'm using Claude Pro inside Emacs right now. I can copy/paste better than when I use it inside the terminal. I never installed a custom IDE since maybe 2012 (my last Java project) so I can't really compare the experiences but I don't have anything to complain to the agentic pairing of Claude and Emacs.

Re: Developers are attached to tools because tools encode trust

#127

Earlier quoted context omitted.

"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.

Trying to force myself to find ways to extract full value out of such a subscription sounds very unpleasant.

It's the literal software development gacha, habit forming, timed intermittent reward schedules and all. Making insane progress on my side projects though.

If I have too much usage I'll simply find something for the AI to do. Guided router update. Router hardening. Laptop hardening. Penetration test my router now that I somehow got into the cyber program. Local models research. PC build research. Smartphone research. Financial investments research. Business research. Medical research. Laptop firmware reverse engineering. Old video game reverse engineering. Pick a random open source project and let's explore the code base. Analyze all of my ten thousand HN posts and tell me interesting facts.

If I can't think of anything I default to picking a random git repository and launching a massive parallel code review session. That's guaranteed to kill any remaining usage in exchange for useful output. Then I can go enjoy my weekend guilt free. Unless they reset the usage.

Re: Developers are attached to tools because tools encode trust

#128
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…

"Trust thermocline". This happens when people no longer trust that improvements are going to come from #1.

Someone whose partner is about to leave them loudly proclaims "I've changed!". Should they believe them? Often the answer turns out to be "no".

It's quite difficult to actually build back trust in these situations.

Re: Developers are attached to tools because tools encode trust

#129
post #61

Earlier quoted context omitted.

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…

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…

I'm not sure that I fully understood but:

> Probably should have spent another 3-5 years getting the first release in better shape instead of spending 3-5 years flinging flaming turds to the paying customers.

I wonder if the company would have had the money to pay salaries for 3 years, unless for those "paying customers" that obviously started paying much earlier than that.

And

> The executives slowly released they inexplicably lost half the business compared to the previous generation as upstart competitors stole their market share.

s/released/realized/ ? Exactly one of my worries. Maybe they could have created those competitors themselves. Two brands, one for the original product and one for a product with a somewhat different layout and all the improvements that they did not dare to add the the original product. But then you need a third brand, a fourth one, etc.

Re: Developers are attached to tools because tools encode trust

#130
post #7

Im typing this in GVim thanks to Tridactyl using my new mechanical keyboard running a ZMK firmware I just built via Github actions (or directly via ZMK Studio). This is ridiculously complex to just type a few paragraphs. Nobody in their right mind would invest this amount of yak shaving... and yet I do so because I bet, rather confidently, that in few years, heck few decades, all those tools will be different (or may…

> typing this in GVim thanks to Tridactyl Thanks for the heads-up that such a thing is possible. I will definitely be investigating it.

With pleasure, ^i in a textarea or even input element brings your text in GVim then saving brings you back. Really handy feature to bring regexes or text navigation to any Webpage.
Post reply on HN