Comment by idle_zealot | Hacker News Reader

Comment by idle_zealot | Hacker News Reader

The observation that so many people incidentally dependent on software to do their jobs, and that said software is often broken, unreliable, or actively hostile really stikes a cord in me. Humans have always had a tendency to develop a deep understanding of their tools, and even to refine them to better suit their needs. But when the tool is software they are left totally at the mercy of whatever opaque GUI the distributor has cooked up. They have no opportunity to familiarize themselves with the tools they depend on or to sand down unpleasant irritations. It's anti-human, and results in a learned helplessness about technology. Certainly engineers have a role to play in improving their tools to prevent quality backsliding, but to really have transformative change for your everyday worker the systems they use need to be open to modification, and basic education needs to cover at least the starting point for how to go about refining their tools for comfortable day-to-day use. Engineering teams can't anticipate the every need and preference of ever non-software-developer in the world, regardless of how much great Rust code they write.

> Humans have always had a tendency to develop a deep understanding of their tools, and even to refine them to better suit their needs.

Many people in North America use a microwave every day. Does that mean they have or want a deep understanding of magnetrons? Likely not. Of course, this is because microwaves generally just work as expected. But I can't imagine a scenario where microwave home repair would be a thing that people would be okay with if they were unreliable.

On the other hand, the buttons on my microwave don't move around six times a year. It doesn't interrupt my cooking to show me ads, either...

Yet

If my job or hobbies required me to make frequent use of a microwave oven, to the point that its clunky interface became an issue for me, I imagine I would develop an operational understanding of magnetrons. That is, what they are good at heating, the shape of their heating effect, how best to place and prepare items for heating, and what parameters can be set to control their behavior, though I may lack a detailed knowledge of the physics involved. At this point it would be reasonable for me to want to configure my microwave, alter default settings, or add button behaviors to speed up my frequent use. I don't expect everyone to become proficient with every tool they interact with in any capacity. I do expect them to be able to grow proficient with tools that they use frequently and that matter to them on a professional or personal level.

I used to think to this too, but I'm coming around to the idea that it was a useful idea only in the period when software was special, and used by a small number of people, and not extremely ordinary, and ubiquitous.

There's a different kind of high stakes involved when your software is used by (say) scientists in the defense industry to when your software is used by hundreds of thousands of fast food workers at mcdonalds. In the latter case, proficiency is useful but modifiability is not. So then the discussion needs to move to more human factors like discoverability, optimization of the fast path through the users' most frequent operations, and speed.

There's a corresponding objection to the idea of fast-food software, though, which is that the world doesn't have to be one-size-fits-all, and in fact we may be near or past a peak era for that approach to software: while everyone still wants and uses manufactured goods, the value chains are increasingly able to incorporate some kind of customization element and deliver services to meet precise definitions.

We know that it's more important to get right answers than fast answers, but the question of whether rightness needs to be shrinkwrapped is inconclusive and subject to the "bundling vs unbundling" innovation dynamic: there are a lot of scenarios where local agency is prioritized, e.g., US ground forces rely on being able to coordinate comms and intel well to achieve objectives within broad parameters, in a bottom-up fashion. That kind of approach does mean there's heavy standardization of specific techniques and technologies, but it's done to enable flexibility in other respects.

If I use a piece of software, I tend to learn the shortcuts, and set things up to make my life easier. I don't start reprogramming excel though.

That, to me, is the point being made.

Fwiw my microwave has about 20 buttons, I only know how to change power, time and start.

The problem though is the vastly different scale. Even small software components have thousands or tens of thousands of lines of code. Millions of lines of code is not uncommon for many commonly used tools.

Imagine a mechanical thing with a million interconnection gears. Would anyone really expect to understand it and be able to replace gears to make it fit their work flow better?

Even for developers of that software, it is often inscrutable, and it is often hard to estimate how a change in one feature might impact other features.

And that's an important aspect that engineers need to take into account: serviceability. We already kinda do this for our own sake, we do need to onboard developers and change functionality over time after all. But there's an art to designing a complex system that is nonetheless scrutible and modifiable. There have been experiments in designing such decoupled and live-modifiable systems, like smalltalk images and lisp machines, but the closest thing we have to that in broad use is the web browser, with its inspection window and console. Of course, webpages are usually deployed as compiled blobs of script these days, but without an isane amount of effort one could build a webapp that was well-suited to modification. Then the user agent would just need some way to save user modifications and apply them consistently. Basically like low-friction userscripts or extensions.

Reply on news.ycombinator.com