Why Is Printing So Bad?

Oh! I have thoughts about this one!

On my model, it's a matter of basically anything that turns Bits into Its being kinda cursed, especially if whatever process lacks human actuation or even oversight and isn't done to truly exacting standards. Printing is an example of this; 3D printing and general CNC is another; graphic design (and the depths of what a color is) is a third. I'm thinking of the kind of thing you might find on r/shittyrobots as well; a minimal non-example might be polypeptide/oligonucleotide preparation, though I'm not totally clear on the workflow there or how much human labor is involved.

My gears-level model here is most starkly illustrated by 3d printing - something about the physical object creation might change, or be underspecified, or rely on shoddily-made connectors of some kind, and in any case, the actual machine that does the actuating isn't set up to check for failures during workflow or indeed do much more than the simple actuation and an initial calibration step. On top of that, the thing goes from being data which is everywhere and wherever you want it, to being a specific thing in a specific place; often you don't even get to have the affordance of knowing in advance which place it is. Possibly even the yakshaving you notice is a matter of some kind of associated ugh field.

[-]johnswentworth15h117

I definitely agree with everything that turns Bits to Its being kinda cursed. I think the natural phenomenon boundary is more general.

Here are some other examples of things which feel terrible in a qualitatively-similar way to printing:

Dealing with the Department of Motor Vehicles or similar bureaucracies.
Working on a mature and messy/poorly designed codebase.
Making a finicky machine work (regardless of whether any Bits are involved).

One piece of what makes these feel similar is recursion - I go on a subquest to solve one subproblem, and that triggers a subsubquest to solve a subsubproblem, etc. One thing I notice about the examples is that the problems maybe typically have to do with assumptions at interfaces - e.g. the printer being out of paper isn't really about "Bits to Its", it's about a finicky machine having been designed with some assumptions about its working environment and those assumptions not always being satisfied.

[-]TsviBT15h73

Partial themes:

Anyone who knows enough to even begin to think about doing anything about it, knows enough to not have the problem.
Making it just work is actually a hard problem. Codebases naturally get messy when big, and are born with ontology skew to the eventual ontology. Machines have to be operated with a conscious touch, and therefore the human has to interface with them.
Legacy systems, especially multiple. E.g. your poor printer is supposed to interface with a huge range of computing systems / your poor computing system is supposed to interface with a huge range of printers.
Sure someone could put a ton of effort into making the last mile smoother, but who's incentivized to do that? The printer does the hard part of printing, what more do you want.

[-]Lorxus15h30

Hm. So it's some larger problem of which the Curse of It From Bit is a subcluster, then? If I've understood you right, this is also something I've spent time thinking about ~~by way of finding them with my face~~. Something like... some unfeeling machine/system/structure that fails to live up to its own spec, or which has a bad spec or no spec at all, and which makes that state of affairs your problem, you silly goose who wants to actually do things, you. There's the flavor of that thing from Zen and the Art of Motorcycle Maintenance where there's this tiny trivial-feeling problem that humiliates you with a combination of feeling trivially small while nonetheless demanding close attention and deep understanding by way of being a critical blocker to solving whatever problem, I think? I think that the yakshaving bit is downstream of the spec failure piece - it seems like a common failure mode of degraded systems/designs.

[-]Dweomite12h82

I have a tentative model for this category of phenomenon that goes something like:

Reality has a surprising amount of detail. Everyday things that you use all the time and appear simple to you are actually composed of many sub-parts and sub-sub-parts all working together.
The default state of any sub-sub-part is to not be in alignment with your purpose. There are many more ways for a part to be badly-aligned than for it to be well-aligned, so in order for it to be aligned, there has to be (at some point) some powerful process that selectively makes it be aligned.
Even if a part was aligned, the general nature of entropy means there are many petty, trivial reasons that it could stop being aligned with little fanfare. (Though the mean-time-to-misalignment can vary dramatically depending on which part we're talking about.)
So, it shouldn't be surprising when find that a complex system is broken in seven different ways for trivial and banal reasons. That's the default outcome if you just put a system in a box and leave it there for a while.

OK, but if that's the default state, then how do I explain the systems that aren't like that?

Suppose we have a system that is initially working perfectly until, one day, one tiny thing goes wrong with the system.
If people use the system frequently and care about the results, then someone will promptly notice that there is one tiny thing wrong.
If the person who discovers this expects to continue using the system in the future, they have an incentive to fix the problem.
If there is only one problem, and it is tiny, then the cost to diagnose the fix the problem is probably small.
So, very often, the person will just go ahead and fix it, immediately and at their own expense, just to make the problem go away.
No one keeps careful track of this--not even the person performing the fix. So this low-level ongoing maintenance fades into the background and gets forgotten, creating the illusion of a system that just continues working on its own.
1. This is especially true for multi-user systems where no individual user does a large percentage of the maintenance

I don't think this invisible-maintenance situation describes the majority of systems, but I think it does describe the majority of user-system interactions, because the systems that get this sort of maintenance tend to be the ones that are heavily used. This creates the illusion that this is normal.

Some of the ways this can fail include:

Users cannot tell that the system has developed a small problem
- Maybe the system's performance is too inconsistent for a small problem to be apparent
- Maybe the operator is not qualified to judge the quality of the output
- Maybe the system is used so infrequently that there's time for several problems develop between uses
For an individual user, the cost (to that user) of fixing a problem is higher than the selfish benefits to that particular user of the problem being fixed
- Maybe no single user expects to use the system very many times in the future
- Maybe users lack the expertise or the authority to perform the fix (and there is no standard channel for maintenance requests that is sufficiently cheap and reliable)
- Maybe the system is just inherently expensive to repair or to debug (relative to the value the system provides to a single user)

[-]johnswentworth12h40

Hmmm... I like the continuous maintenance model here, but I don't buy it as the main explanation for all the systems which aren't printer-like. As a counterexample: consider a table. Or a chair, or a whiteboard marker or toothbrush (which need to be replaced sometimes but don't have the deep-recursive-problems nature), or the chrome web browser (which works pretty consistently, and when it doesn't work a restart or reinstall basically-always works without any further recursive problem solving, even on my linux box). These don't require much continuous maintenance from the user(s).

It feels like there's something here about simplicity - e.g. tables, chairs, and whiteboard markers may have a surprising amount of detail if you look close, but they're still substantively simple in a way that printers are not. My current best articulation is roughly that printers have a more complex/narrower set of preconditions on their environment in order to work, whereas tables and chairs and the chrome web browser have a much simpler/more robust set of preconditions on their environment. The surprising detail of a table is mostly "internal" in some sense; it's in the design itself, not in the preconditions/assumptions made by the designer.

... but I'm not at all sure that that's the right way to think about it.

[-]Dweomite12h50

I would agree that, while reality-in-general has a surprising amount of detail, some systems still have substantially more detail than others, and this model applies more strongly to systems with more detail. I think of computer-based systems as being in a relatively-high-detail class.

I also think there are things you can choose to do when building a system to make it more durable, and so another way that systems vary is in how much up-front cost the creator paid to insulate the system against entropy. I think furniture has traditionally fallen into a high-durability category, as an item that consumers expect to be very long-lived...although I think modernity has eroded this tradition somewhat.

[-]leogao15h65

idk, i don't print stuff that often, but printing mostly just works for me. it's not always smooth sailing, but it's not any less smooth sailing than anything else i deal with when running ML experiments

[-]habryka10h62

I mean, I think running ML experiments is like the other most cursed thing that I feel like I have to interface with on a regular basis.

[-]Thane Ruthenis6h40

I've been recently irritated at something that feels vaguely similar with regards to research loops. Walking through this example...

I note that most of those problems have little to do with the printing technology, and mostly about poor organization around that technology.

Friction sources

Choosing which printer to use isn't trivial for someone who doesn't already know it.
Counter-intuitive print dialogue which doesn't make it clear how to locate a specific printer/add a new one to someone who doesn't already know.
The printer's physical location isn't clear from where you control it.
The printer is not in the same room as where you control it. This means that if you have to iterate on printing due to (potentially minor) errors, each iteration is unnecessarily extended by having to walk back and forth.
No fine-grained feedback on what the printer does from where you control it (that it only printed two of your pages and then ran out, that page 1 printed blank).
Paper is not in the same room as the printer.
Locations of things aren't trivially clear to someone who doesn't happen to know them.
- The printer's initial location.
- The printer's new location.
- Room 1A1's location.
- The location of the paper for the printer.
- The new location of the paper.
Poor organization of printer output (that it just dumps everyone's print-outs in the same stack; not sure if that was a problem, but sorting that out can add friction too).
Different printer behaviors depending on the software you print from, and what page you print, even though all entity types (documents, pages, function mapping from document-pages to physical pages) should be the same.

What common threads can we see?:

Systems are not optimized to make it easy to interface with by someone who is using them the first time; someone with zero local tacit knowledge.
- Printer/room/paper locations, printer choice, print dialogue.
- Arguably (9) fits too: probably the different behaviors were due to some peculiarity of the printing algorithms in different software that someone very familiar with that software would know about.
No affordances for easily recovering from common failure modes/errors/hiccups, or even for quickly learning about them.
- Paper in a different room from the printer, printer in a different room from where you control it, no feedback on printer behavior from where you control it.

I see a few directions we can take it.

Direction #1: No affordances for one-time users.
- People who set up/modify systems are usually people who work with those systems a lot. They have tons of tacit knowledge about where things are, how to use them, how to avoid and recover from failures, etc. Modeling the mental state of someone who doesn't have your tacit knowledge is notoriously hard, and even when it isn't ("a random person wouldn't know where I moved the paper"), there are no established societal norms/organizational standards regarding making things frictionlessly easy for first-time users.
- Even when there are manuals/instructions/etc., they usually assume that you're going to be thoroughly figuring out how to work with that system, as if you aimed to become a frequent user, rather than doing a specific thing once and never interacting with it again.
- The problem is that "a person interacts with a system once and then never again" is a very common occurrence. For some systems (e. g., specific bureaucratic procedures), this is potentially the bulk of user experience; and on the flipside, "interacting with a system for the first time and never again" is a significant fraction of any given person's life experience.
Direction #2: Systemic accumulation of small friction sources.
- All of those individual sources of friction were annoying, but ultimately not that time-consuming (figuring out things' locations, how to install/locate a printer, replacing paper, re-printing things).
- What made the whole experience miserable is that there were tons of those sources of minor friction which came into effect simultaneously.
- Thus, it's easy to see why the person responsible for creating each bit of friction didn't think of it as a big deal, or why we don't have societal/organizational standards regarding not creating such minor friction. (Consider that making a big deal of complaining about any given bit of friction in isolation would make you look like a loon/a "Karen".)
- But the problem is that tons of systems you interact with end up with these small bits of friction cropping up, so your ability to move forward is constantly mired down by that stuff.
Direction #3: No affordances for quickly recovering from small failures.
- Some sort of default assumptions that things will go as intended, with no minor errors, hiccups, need to fix problems/iterate, etc.
- And as long as things-going-wrong doesn't create a big incident (e. g., someone dying with that as the clear leading cause), nobody is particularly incentivized to think about that and prevent that.
- So there are no affordances for easily recovering from them.
- But this pattern reoccurs everywhere, so a large fraction of the human experience involves dealing with them.

In what other situations does this show up? An obvious example are various bureaucratic procedures, which require some research to make sense of, and where a small typo/mistake in your documents might lead to having to schedule another appointment next hour/day/month. That is: a procedure you'd plausibly interact with only one/a few times in your life is managed by people who interact with it constantly, and the bits of friction you run into are not obviously catastrophic, so those people are not forced to make things easy for first/imperfect/inexperienced users.

Note that the full thing is not necessarily easy to fix, much like e. g. technical debt isn't^[1]. The work to keep systems easy-to-interface-with is, as usual, a battle against entropy. Overall, I feel this problem is just another manifestation of that one.

Things could certainly be made much better, though, by both:

Establishing high-level organizational standards/policies (e. g., keeping printer paper in the printing room).
Creating low-level societal norms (if you moved paper somewhere, leave a post-it about that).

^{^}
And indeed, technical debt is another instance, where, for programmers maintaining a codebase, it's no-one's first priority to make it easy to understand/modify/interface-with for a one-time user.
Potentially the "inconsistent printer behavior" is downstream of that, by the way. Perhaps there's no obvious correct/convergent way to interact with low-level printer software, so each app's designers had to take their own approach, so there are inconsistent behaviors across apps.

[-]the gears to ascension10h40

some examples of things that may be like this, human generated list, varying confidence and specificity:

nvidia drivers (reduced in severity now)
drivers in general?
interfaces between software in general?
laws and regulations, sometimes
social group conformance expectations, sometimes
biology, especially immunology, especially drug design that has to bypass immune system
prompt design for ais?
robotic controller algorithms, especially for walking, especially for all-terrain walking
robot software drivers (see: drivers)

some things that seem not like this:

pure math (usually?)
- okay at least definitely not arithmetic
fundamental physics? I mean there is the whole relativity vs quantum thing and that feels at all related but noncentral
writing software near the beginning?
playing most sports, as a human? tenuous
drawing with a pencil
using youtube, reddit, possibly any given widely deployed consumer software

the generator that feels live to me here is like, things where entropy* accumulates in interfaces or is generated in interfaces in the system somehow. many of them involve human-generated complexity, but that seems optional; seems like you can get this in pure math between conflicting formal systems, where you need a theorem connecting things even though pre-theoretic intuitively they're "obviously" the same thing (of course that "obvious" is sometimes wrong).

* except maybe not literally entropy, but rather like, boundedly-rational unpredictability. I guess by some definitions that's entropy - the definition would involve microstates not predicted by a macro model, and in this case the macro model would be the simple view of a system.

[-]Aprillion2h10

My workflow in last 2 jobs, if I already printed something in last 3 months:

print the document

After a change of laptop / floor / other size instead of the usual A4 / fiddling with booklets / ...:

go to the printer
follow instructions on the printer (usually just filling the IP address on a Mac, but I once tried testing a web app I was developing how it prints from virtual Windows when testing.. permissions were fun)
print it
realize some Unicode characters in some heading fonts in a PDF from Firefox preview didn't work
(or something)
download the stupid PDF and print it again
fill the paper from the cabinet next to the printer
remove chewed-down page, confirm everything is fixed, let the printer finish and re-print whatever is a mess
1. or set higher DPI if needed for images and re-print
2. or sign the document, scan to email, and shred the paper (because they didn't like my electronic signature and asked me to do it for expense report or something where I have to sign-in anyway)
(not very often) debug our web app for a couple of days to convert position:absolute gantt chart into actual html table that can be paginated with repeated headers and footers
1. and find the least worst CSS for page orientation and margins and default zoom and logo resolutions for most common DPI that looks reasonable in at least some browsers
2. figure out which backgrounds make sense to force-preserve (icons) and which to remove by default (whole-page background)
3. preserve order of text when printing to PDF and completely remove hidden text so that search still works in various PDF readers (reasonably-ish)

[-]Aprillion2h10

Almost forgot - being in a hurry almost certainly triggers the second path through the workflow.. no idea what's the mechanism for that tho, probably availability bias.

LESSWRONG
LW

LESSWRONG
LW

37

Why Is Printing So Bad?

37

37