Yesterday, you saw the first 30-minute segment. Today, you arrive at the multiplex, and are informed that the three 30-minute segments (1, 2, 3) are starting shortly on screens A, B, and C. However, you are not told the mapping of segment to screen. You are asked to select a screen, and choose screen B. You are then informed about the status of either screen A or screen C: that status may be that it will play segment 1 (from your perspective: a duplicate) or that it will play segment 3 (from your perspective: out of order). Finally, you are asked whether you will be watching screen B, or the other, unrevealed screen. (If you don't actually watch your final choice, you're banned from the multiplex forever.)

Is this harder (e.g., not solvable at all) compared to the Monty Hall problem, because segment 1 is merely an annoyance, but segment 3 is a spoiler (permanently impacting your enjoyment of the movie)?

What's the history of this first project I've been assigned to?

Who are the most important customers, or types of customers?

What's the risk tolerance (unless you've been told Move Fast Break Things)?

Things you usually can't ask directly, but need to learn quickly:

Is this a meritocracy? If not, what other factors matter?

What types of actions are perceived as throwing a co-worker under the bus?

Is most of my job to figure out what my job is (i.e., exploring how I can contribute most effectively)?

Cleaning up /var/tmp on a timer is relevant to this academic environment (desktop-based research computing):

1. Each Debian machine is used by only one graduate student, but students do not have root access.

2. Today, /var/tmp is the only persistent local directory where the student has write access ($HOME is on a network filesystem backed up by the university).

3. Within the student population, there is strong institutional memory that /var/tmp isn't backed up by the university and isn't extremely robust (e.g., RAID), but also that nothing there is automatically deleted.

4. Students use /var/tmp for hundreds of Gb of data from simulations that take days or weeks. $HOME is too small and too slow for this.

5. In practice, less than 1% of students lose data through disk failure, accidents, etc.

6. A much larger fraction of students will lose data when sysadmins, who didn't get the memo about the /var/tmp change and thus haven't addressed the ingrained institutional memory, deploy new Debian machines.

7. Some of the students who lose data won't graduate on time.

Avoids writing everything twice: you don't need to name the data fields both in the base URL and in the query string

If there are several parameters, writing everything twice may make the URL longer than one physical line in a text editor

The ? and & characters need to be quoted in most shells

The _ characters are sometimes hard to read if the entire URL is underlined

Names with api_json don't make it clear whether the request body must be sent as JSON, the response will be JSON, or both