Menu Close

Tag: decision-making

This website was archived on July 20, 2019. It is frozen in time on that date.
Exolymph creator Sonya Mann's active website is Sonya, Supposedly.

Wanted: Efficacious Heuristics

A system is an arrangement of interlocking elements or moving parts that all affect each other, sometimes recursively. The world is full of them (and in fact each of those systems is itself an element of the larger system that comprises the whole universe).

Mathias Lafeldt wrote about how the human mind copes with this:

“Systems are invisible to our eyes. We try to understand them indirectly through mental models and then perform actions based on these models. […] Our built-in pattern detector is able to simplify complexity into manageable decision rules.”

Lafeldt’s explanation reminds me of the saying that the map is not the territory. Reality (which is a system) is the territory. Our mental models are maps that help us navigate that territory.

Artwork by Kyung-Min Chung.

Artwork by Kyung-Min Chung.

But no map is a 1:1 representation of reality — that would be a duplicate, or a simulation. Rather, our maps give us heuristics for interpreting the lay of the land, so to speak, and rules for how to react to what we encounter. Maps are produced by fallible humans, so they contain inaccuracies. Often they don’t handle edge cases well (or at all).

Nevertheless, I like mental models. They cut through all the epistemological bullshit. Instead of optimizing a mental model to be true, you optimize it to be useful. An effective mental model is one that helps you be, well, more effective.

This is why Occam’s Razor is so popular despite being incorrect much of the time. Some plans do go off without a hitch. But expecting the chaotic worst is a socioeconomically adaptive behavior, so we keep the idea around. [Edit: Hilariously, I mixed up Occam’s Razor and Murphy’s Law — thereby demonstrating Murphy’s Law.]

My personal favorite mental model is a simple one: “There are always tradeoffs.” One of the tradeoffs of using mental models at all is that you sacrifice understanding the full complexity of a situation. Mental models, like maps, hide the genuine texture of the ground. In return they give you efficiency.

Open-Source Squabbling

Nadia Eghbal wrote an interesting overview of the history of software development — the nuts and bolts of how the future is being iterated — with a focus on open-source programming. In the 1980s:

“Sequoia Capital funded Oracle to make database software. IBM hired Microsoft to write MS-DOS, an operating system for their PC.

Suddenly, the idea of free software seemed insane. Software was a commodity; if you could make millions of dollars charging for it, why wouldn’t you?

Writing free software became a political act of defiance, and a strong counterculture rose around it. If you wrote open source, you weren’t like Oracle or Microsoft. People who wrote free software believed in its potential as a platform, not a product.”

Now open-source software is a significant part of the status quo — every single computer-based company uses it, and the startup ecosystem would flounder without it — but the idealistic pull of OSS remains strong. People join because they want a communal project as much as they simply want to build something. However, trying to generate consensus is incredibly frustrating and the effort is often fruitless. Eventually, project maintainers must make and enforce decisions.

Currently there’s a big hubbub among contributors to the programming language Ruby about whether to adopt a code of conduct. It seems silly to me — the human race invented rules for a reason — but people are very distressed. The worry is that controversial developers will be attacked unfairly, that they’ll fall prey to petty “SJW” vendettas. On the other hand, proponents of codes of conduct point out that articulating anti-abuse norms is powerful.

Ideologically, I tend to side with codes of conduct, but I also believe in self-determination. If the majority of the Ruby community doesn’t want one, and open-source initiatives are specifically meant to be defined by participants… what’s the fair solution? Should a project maintainer decide one way or the other, as I indicated above?

© 2019 Exolymph. All rights reserved.

Theme by Anders Norén.