A beautiful reflection on the story behind Apollo 8 and their capturing of the “earthrise” photograph—the first photo of Earth from space.

We didn't have any specific directions about the use of photography. We were all on the earth, so we all knew about the earth. They wanted photographs of something that was unusual [like] close-ups of the far side of the moon. The earth? It was strictly secondary.

More than the documentary details of the earth-rise photo, this is a musing on our existence in the cosmos.

What he's worrying about is the engineering problem of: how do we build working, reliable systems out of this distributed, computational material. What I’m worrying about...is the humanist problem of: what should we build, why are we building it, what will we do with it, and what is it going to do to us?

It’s so easy to get caught up in the engineering minutiae—How will we do this? Is it even possible? Those humanist questions Bret outlines are great questions to ask yourself before you build anything.

Had this talk sitting in my “To Watch” list for a long time. It’s full of little insights. I really like the speaker’s presentation of this quote from Marshal McLuhan:

All media are extensions of some human faculty, mental or physical. The wheel is an extension of the foot. The book is an extension of the eye. Clothing is an extension of the skin. Electric circuitry is an extension of the central nervous system. The extension of any one sense displaces the other senses and alters the way we think, the way we see the world, and ourselves. When these changes are made, men change.

An interesting look at the value proposition of PureScript.

What I found really interesting here were the function signatures because they afford you so much by merely glancing at them, especially when your code has side effects. Here’s the example the presenter uses:

-- Pure
      summariseDocument :: String -> String
      -- Needs network
      fetchDocument :: DocumentId -> Eff (ajax :: AJAX) String
      -- Needs a browser
      renderDocument :: String -> Eff (dom :: DOM) ()
      

This lets you keep track of what pieces of your code can run by themselves and which require other systems (servers, databases, etc) in order to run.

[PureScript] takes you to the future of large scale front-end code reliability. [Now I’ve written systems in PureScript] and every one of those systems in recent years has needed a little bit of JavaScript. Maybe five to ten percent of the codebase is JavaScript. All of my bugs, all of my runtime exceptions, all of my problems, come from that five to ten percent. The rest [of the codebase] is rock solid. I worry about logical errors but I don’t worry about the reliability of my code anymore on the front-end.

As far as what I hope the audience thinks of the sound, I would hope that they think the sound was all shot on the days they shot the movie and that it’s all there. — Richard King, Supervising Sound Editor & Sound Designer Interstellar

I found it interesting how the ultimate goal of the sound team was to have the audience not even notice their work. After all the extremes they went to — the airplane graveyard, the ice shoes, the sand blaster — they wanted their work to go unnoticed by the audience and instead have them simply assume it was all a product of the original film shoot.

I find such an interesting parallel to this in visual design: good, simple design is the obvious choice. So obvious, in fact, that people don’t even notice it. They just naturally assume “how could it be any other way?”

Reminds me of this quote, from the book The Inmates are Running the Asylum (which, if you haven’t read it, is great):

If, as a designer, you do something really, fundamentally, blockbuster correct, everybody looks at it and says, “Of course! What other way would there be?” This is true even if the client has been staring, empty-handed and idea0-free, at the problem for months or even years without a clue about solving it. It’s also true even if our solution generates millions of dollars for the company. most really breakthrough conceptual advances are opaque in foresight and transparent in hindsight. It is incredibly hard to see breakthroughs in design. you can be trained and prepared, spend hours studying the problem, and still not see the answer. Then someone else comes along and points out a key insight, and the vision clicks into place with tentacular obviousness of the wheel. If you shout the solution from the rooftops, others will say, “of course the wheel is round! What other shape could it possibly be?” This makes it frustratingly hard to show off good design work. — pg. 200

This is inline with what Alan Dye, Vice President of User Interface Design at Apple, said about Apple’s design goals:

Inevitable is the word we use a lot. We want the way you use our products to feel inevitable.

The goal is to make it seem as if the designers at Apple can’t even control the form and function of their products because the end goal is so natural and logical, i.e. inevitable.