[constantcrying]

It definitely is true that a design which could easily be created by hand is harder to create on a computer. The things where computers shine are actually managimg the complexity of a large and complicated systems.

What I think the article leaves unspoken (but implied) is the "curse of tools", if you give a person tools he is likely to use them, even if they might not be applicable. Meaning that someone might decide to create a complex solution to a problem, simply because the tools he has been given allow him to do so. I think it is always very important to keep in mind what has been achieved with the very limited tools of the past and the immense ingenuity of the people who worked within those limits.

[dimask]

> The things where computers shine are actually managimg the complexity of a large and complicated systems.

I would argue that where computers shine, firstmost, is automating repeated tasks. Even if a task is fairly simple in complexity and doing it by hand takes less time, if you have to repeat the same task over and over it may be beneficial to use computer tools that allow some automation, even if in the first couple of runs this is gonna take more time. In this sense, something being easier to do by hand (once) does not necessarily imply that it is better to do it by hand.

But I do agree that an increase in complexity comes as a curse of tools. People with less tech-understanding may be more easy to get what some benefits of such tools are, but the problems that increased complexity brings takes longer to catch them.

[docfort]

Complexity is the outcome of misunderstanding. The misunderstanding can come from lots of areas.

It could be from a requirements perspective: “I understand what I can build easily, but not what you want.”

It could be from an engineering perspective: “I understand what you want, but I don’t understand how to build that cohesively.”

It could be from a scientific perspective: “No one knows what tools we need to investigate this.”

I saw mentioned in other comments that CAD software doesn’t allow for sketching. As someone who was originally trained in drafting the old way, and who has used modern CAD systems to produce models for fantastically large physical simulations, I largely agree that sketching is lost. But the sketching that I can do on paper is just not at the same level of complexity as I can kinda do on my computer.

But the complexity of using the new tool obscures the fact that my model is much more complicated than I could otherwise manage using old tools. And that’s because I’m still learning. In fact, I have to “deploy” while I’m still in learning mode about a problem, unlike before, where I had to understand the problem in order to use the tools to draft the thing.

Being able to do something with a half-formed idea sounds like sketching, but when non-experts rely upon it, it’s pretty fragile. Because it wasn’t done.

Building a memex (something the author disparages multiple times) is super hard because we still don’t understand how to represent ideas separately from language, our original mental sketching tool. But people built Altavista and Google and LLMs anyway. And yeah, they’re super complex.

How does TCP/IP work over wireless connections? Poorly and with a lot of complexity. Why? Because the concept of a connection is ill-defined when communication relies on ephemeral signaling.

But despite the complexity, it is useful and fun to use only half-baked ideas. Just like it’s fun to use language to describe stuff I don’t understand, but merely experience. Graduation. Being a parent to a sick child. Losing a loved one.

[pas]

The problem is that we are flooded with low-quality tools.

In general it is almost universally true of software nowadays. (Because change/progress leapfrogged any kind of teleological end-to-end design OR it's simply unmaintained, for example see any US government IT system. Or the ubiquitous extremely fragile corporate synthetic snowflake software that only runs on Windows XP SP1 + that 3 particular patches with that exact vc6.dll copied over from an old CD.)

A good quality information processing tool is designed for the process that it's meant to augment, ideally considering the original problem, and ultimately improving the process itself.

(Just digitizing a form likely leads to worse outcomes. Because those forms were designed for pen and paper. Screens and keyboard navigation requires different flows.

And the usual process is even worse, which consist of reinventing the wheel without context, as in speedrunning through all the problems of corporate politics and procurement, delivering some half-assed milestone-driven monstrosity, and forcing it on employees.

Of course, due to the aforementioned universal internal incompetence-fest and quarter-driven development budgets are bad, required time and effort is underestimated, learning curves are ignored, software gets set in stone too soon, and thus efficiency remains well below the expected, planned, possible, and hoped for.)

[littlestymaar]

I think the main reason why we're flooded with low quality tool is due to the fact that with software you just copy-paste your prototype to production: unlike real world system where you build a prototype to show stuff and then have to industrialize it to get to production, for software this expensive (and crucial for quality) step is skipped entirely, and we are all stuck using prototypes…

This and seeing “code written” as the asset, instead of an artifact of “engineers increasing their mastery of the topic”, which is the true asset. But it's very closely related to the first point.

[pas]

Yep, the elimination of in-house expertise was ridiculously short-sighted (which is an extremely charitable and euphemistic version of breach of fiduciary duties).

[datadrivenangel]

Ideally you computerize away the process as much as possible.

A common failure mode of digital transformation processes is taking the old people process and computerizing it without revisiting the underlying process.

[pas]

Other important thing is that paper was able to handle "all the exceptions", notes on margins, corrections, other paper clipped to it, whatever. Sure it was ugly, but it was in-band.

If there's no way to do this in a new system, then it means there will be a parallel semi-official informal shadow of it scattered around in out-of-band channels (emails, phone, paper!), and that leads to more complexity, which kills efficiency.

[Nevermark]

Never underestimate the personal satisfaction of spending a day, or a week, installing, playing or configuring one's tools!

In the past, we customized our workflow while in the flow. Now, to approximate that freedom, we have to futz around up front, with the limited control levers they give us. In a slow feedback loop with any actual work, to get our tools to help us in the way we want.

Which for complex tools and work, can rapidly become its own end.

[api]

The curse of tools applies in computing too. A virtue of languages like Go is that they reduce incidental and gratuitous complexity through the simplicity of the language. A complex language with a powerful type system like Rust or C++ will tempt programmers to use every facet of the language and create baroque overly complex code.

[chiggsy]

Sounds like an argument for C, honestly. After all, that complexity is either in the language, or solved on a case by case basis. Every patch adds complexity, because it reflects changes in the business environment that presents the problem the code is solving.

[api]

C is okay except safety. Look at the CVE lists and they are still full of memory errors and it’s 2024.

The problem isn’t that good programmers can’t write good C code, though anyone can make a mistake. The problem is what happens as code ages, is worked on by other people, gets PRs merged, and so on. Bugs creep in and in an unsafe language nothing catches them.

C also makes string processing hellish, but that could be fixed with libraries and isn’t necessarily the fault of the language.