Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Developers are attached to tools because tools encode trust

stackoverflow.blog

Post reply on HN
Print view View original

71–80 of 148 posts

Re: Developers are attached to tools because tools encode trust

#71

Post by GuB-42 »

MiddleEndian wrote: post #38

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 just using vim as "the standard text editor" (sorry ed), I don't want to configure anything as it is usually a one shot job.

I never asked for that, at some time, it just happened. I guess as a major upgrade, but the thing is, something changed that I didn't want to change.

I understand the reason for this change, also https://xkcd.com/1172/ but I just wanted to say that even vim is not immune.

Some tools are immune though. Usually command line tools used in scripts. For example "apt-get" doesn't change, but "apt" does. "apt-get" is what you use when you want a stable interface (especially scripts), "apt" is for when you want something nicer.

Re: Developers are attached to tools because tools encode trust

#72

Post by BobbyTables2 »

ozim wrote: post #61
MiddleEndian wrote: post #38

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…

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 rushed development.

We’d get escalations on things that were fixed years ago.

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.

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

You know that famous “how shit happens” tale? I’m pretty sure each layer of management was telling the next how powerful the product was… few could abide by it.

Re: Developers are attached to tools because tools encode trust

#73

Post by accrual »

ToValueFunfetti wrote: post #63
musicale wrote: post #53

Earlier quoted context omitted.

> When Windows ME and Windows Vista came out, people hated them even more than they usually hated Windows, so they did not use them. Microsoft was forced to respond by making a not-quite-as-bad OS in Windows XP This timeline doesn't seem to make sense, as Windows XP came out in 2001, and Windows Vista in 2006-2007. Maybe you are referring to Service Pack 3 in 2008?

Reactions to Windows ME forced MS to respond with XP; reactions to Vista forced them to respond with 7. They're being stated in parallel rather than chronologically.

This isn't quite right, Windows Me was a stopgap between Windows 98 and Windows XP. Microsoft had no intention of keeping anyone on Me for long. There were already plans to get consumers onto an NT-based OS when Me launched, the initial version of this was codenamed Neptune.

> Microsoft discussed a plan to delay Neptune in favor of an interim OS known as "Asteroid", which would have been an update to Windows 2000 (Windows NT 5.0), and have a consumer-oriented version. At the WinHEC conference on April 7, 1999, Steve Ballmer announced an updated version of Windows 98 known as Windows Millennium, breaking a promise made by Microsoft CEO Bill Gates in 1998 that Windows 98 would be the final consumer-oriented version of Windows to use the MS-DOS architecture. [0]

So XP was not a reaction to Me's reception, it was already in the works as a replacement when Me came out.

[0] https://en.wikipedia.org/wiki/Development_of_Windows_XP

Re: Developers are attached to tools because tools encode trust

#74

Post by 1saadcodes »

I think the article is right that developers become attached to tools because of trust. Ironically though, that's also why many people drifted away from Stack Overflow. The answers were trustworthy, but over time the experience of asking questions felt less and less welcoming than searching for existing ones

Re: Developers are attached to tools because tools encode trust

#75

Post by AlotOfReading »

alexpotato wrote: post #60

There is a great article called "Manual Work is a Bug: Always be Automating" [0] that was written in the pre LLM era for technical operations teams. I would argue that it is just as relevant today as it was then. To summarize: - start making a list of the manual tasks you do - if those tasks involve running command line tools, add an item with the commands you run - if they are manual tasks, add those too - over time…

Like all advice, A.B.A. some pretty serious flaws if you apply it too universally. Automated solutions tend not to replacing manual work perfectly or completely. They do most of the same things, and the distinction tends to be forgotten. Maybe a human goes in and fixes things for a bit afterward, but that doesn't last. Eventually the accessible 90% is declared good enough and people forget that the rest is even possible.

The first case of large scale automation demonstrates this very well. Medieval manuscripts looked like this [0]. You can see the imperfections, but it's still a beautiful book. Gutenberg bibles omitted the scribe in favor of automated printing, but humans remained involved with the creative details in illumination and rubrication. The result is genuinely beautiful [1]. The works that were printed a century later rarely featured this kind of post-print human involvement [2]. This is still better than most of what's printed today, but it's a clear step down.

Now, there's a reasonable argument to be made that the quality differences don't matter for books and certainly don't outweigh the cost advantages. But imagine someone at your passport office has taken A.B.A. to heart and automated 90% of the job. Over time, the organization will stop handling all the edge cases and. But the edge cases didn't stop happening, they're just no longer visible. Beyond a certain scale (e.g. Google and other FAANGs), those inevitable failures manifest as seemingly capricious behavior that makes everyone hate your system and produces outcomes no human involved actually wants.

[0] https://i0.wp.com/blogs.princeton.edu/notabilia/wp-content/u...

[1] https://ff-65a4.kxcdn.com/assets/uploads/OriginalDocs_old/98...

[2] https://www.prepressure.com/images/Nieuwe-Tijdinghe-newspape...

Re: Developers are attached to tools because tools encode trust

#76

Post by TacticalCoder »

groundzeros2015 wrote: post #54

When I see “stack overflow blog” the brand encodes distrust. I remember when they removed links to meta and replaced them with the corporate blog with low quality PR and political agitation.

> When I see “stack overflow blog” the brand encodes distrust.

Incredible, in a way, that you still see it as a brand. I honestly thought it was a 10 years old blog post somehow making it to frontpage (as some old blog posts sometimes do on HN).

Who still uses DeadOverflow-full-of-outdated-answers? (outdated and often just plain wrong too)

I haven't been there in like 15 years or something. Feels like ages.

Re: Developers are attached to tools because tools encode trust

#77

Post by win311fwg »

pianopatrick wrote: post #51

As a teacher I know for a fact some people just learn faster than others. So I think part of why developers get attached to tools is because learning takes time. Some people can pick up new tools in a day. I can't. I feel like new tools are created faster than I can learn them.

All tools require time to learn, but not all tools gain attachment, even when one has committed to learning the tool. From my observation, attachment is formed when one finds something about a tool that feels like a secret insight or advantage that is being overlooked by most others, thus establishing a tribe of those who have "seen the light", with the tool becoming the identity of the tribe.

Re: Developers are attached to tools because tools encode trust

#78

Post by saimiam »

hilariously wrote: post #69
ozim wrote: 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…

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?

Re: Developers are attached to tools because tools encode trust

#79

Post by fragmede »

GuB-42 wrote: post #71
MiddleEndian wrote: post #38

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…

On your laptop, in ~/.ssh/config:

    Host *
        PermitLocalCommand yes
        LocalCommand rsync -azL --checksum -e "ssh -p %p -o PermitLocalCommand=no"  "$HOME/.vimrc" "%r@%h:.vimrc"
This copies your ~/.vimrc if unmodified to every server you ssh to.

(For bonus points, you can make a program to copy ~/.ssh/config around as well so that your config gets copied to servers you ssh to from there.)

Re: Developers are attached to tools because tools encode trust

#80

Post by kelnos »

BobbyTables2 wrote: post #72
ozim wrote: 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…

> 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 a completely new, different product, which guarantees retraining (possibly a lot more), and probably would contain the same or different bugs they were fighting with when using your software.

And... they went with #2?? I get that people think the grass is always greener on the other side, but there's a reason why we have that saying!

Post reply on HN