Type:Rider and Flappy Bird

I wouldn’t have thought typography could be the subject of a video game, but Type:Rider does just that. The levels are a tour of Western history from the middle ages onward, each corresponding to a different typeface in the context of its era. The Gothic type’s levels take cues from medieval churches while the 1920′s Futura feels like a modern art museum. The player’s avatar is a colon, two rolling dots bound together by some magnetic-seeming attraction. Gameplay consists of navigating through terrain including each letter of the alphabet rendered in the that typeface. The letters are arranged to create interesting geometrical puzzles that make them memorable. The player also navigates through oversized versions of the printing technologies of the day, meanwhile collecting asterisks that unlock brief passages about the key figures and inventions of the time period.

There are a number of features that make Type:Rider stand out. It is highly polished, with beautiful visual environments and suitable thematic music. (Surprisingly the typesetting of the informative passages is often found wanting; perhaps the English translation wasn’t proofed by the original European developers?) The controls are relatively expressive, in that with a few taps the skilled player can move the colon in one of many possible ways. The game has value: it took a team of experienced designers and developers time and money to create it, and the user must expend time and money to enjoy it. But yet, the game has a deeper message. Yes, it’s about typography, but mere type is the means by which we transfer knowledge; typography is the beatification of knowledge. Typography rewards diligence, attention to detail, graphical density, and knowledge of prior work. Typography is the wings on which intellectualism is borne.

Contrast this with the maddeningly weak and imprecise wings of Flappy Bird. Wired does a good job recounting the saga of the infamous iOS game and its creator, Dong Nguyen. Anyone can pick up the game and play it immediately, but playing well is exceedingly difficult: mastery and skill-building are sacrificed on the alter of ease-of-use. Play happens in all-too-brief bouts, which provide instant gratification with no time commitment. No depth of knowledge, skill, or artistic message is ever accumulated.

Papert distinguishes between children programming computers and computers programming children, and this is certainly the latter. Flappy bird conditions one exact response, with no room for exploration or creativity. No justification is given as to why the world must be the way it so firmly is. More concretely, flappy bird is fake difficulty, riding on an artificially narrow method of control. It perniciously makes the smart phone, and the human, less smart.

Dong Nguyen made (and is likely still making) fifty thousand dollars a day off advertising shown to the game’s users. I highly doubt the users (largely teens) are spending anywhere close to that amount of money on the advertised products. Flappy bird generates money but not wealth; like doomed financial products it is built on value that simply isn’t there. Sooner or later, this bubble must burst.

But despite the attention directed towards Flappy bird, it is hardly unique. Only four of the top fifty grossing apps (as of when I checked) are not games (Pandora, Skype, and two dating apps). The rest are games, targeted at the under-20 crowd, driven by ads and in-app purchases (which include the removal of ads). The app store has become Western kids in a gigantic candy store, and this has pushed adults and their fine intellectual cuisine off to the margins. The market has spoken: mass-produced low-quality ad-ridden software for entitled children is what sells, adults and society be damned.

I will quote (again) from Jaron Lanier, You Are Not A Gadget: “Rooms full of MIT PhD engineers [are] not seeking cancer cures or sources of safe drinking water for the underdeveloped world but schemes to send little digital pictures of teddy bears and dragons between adult members of social networks. At the end of the road of the pursuit of technological sophistication appears to lie a playhouse in which human kind regresses to nursery school.”

Even Type:Rider is not immune. It has the requisite Facebook and Twitter integration, though they are less prominent. It is also available as a Facebook game. What is offers, then, is not a completely pure solitary experience but rather a compromise given the nature of the market.

It is said that technology changes quickly and people change slowly, but the reality is more complex. People have shown a remarkable ability to adapt to new technologies, without fundamentally altering how they think or what goals they have. Meanwhile, the face of technology changes, but many ideas remain timeless and fixed, old wine repackaged into new bottles. Furthermore standards and protocols by which devices communicate with each other, once set, become incredibly difficult to change. We are in danger of not changing with technology, and then creating technology that prevents us from changing.

Of Signs, Skyscrapers, and Software

I was looking for a book on data visualization. Having gone through Edward Tufte’s classics, I browsed the Tufts library catalog by “visualization”. The two keepers were only tangentially related, but I’ve learned that I sometimes attack problems too directly, so I checked out Signage and Wayfinding Design by Chris Calori and The Heights: Anatomy of a Skyscraper by Kate Ascher. Both have involve service through the built environment. That is, unlike the social justice programs that many of my classmates engage in that serve interpersonally, these books see service conducted through the proxy of a created object. This model appeals to me because the object can serve many more people than I could personally interact with. The object endures to serve in the future, as opposed to the many charitable acts that have vanishingly immediate returns. That is, service through objects is more efficient.

In the case of signage, it is intellectual service. Wayfinding provides empowering knowledge much the way that software can (should). Signage also serves a secondary placemaking role. Signs not only describe the built environment; they are part of it; they should embody emotions, preferring to lend character to its environment over abstract minimalism. Therefore, signs walk the same tightrope that infographics do, between information clarity and contextual aesthetics.

Chris Calori leaves no stone unturned as she documents the full process of signage production. On one hand, it is ruthlessly physical, with details such as mounting, dimensions, lighting, materials, and finishes to be specified prior to fabrication. Much of the waterfall-like process is principled on preventing the full construction of a faulty signage program, by using detailed plans, miniatures, prototypes, and renderings. On the other hand, signage is a great example of the divide between art and design. Art attempts to communicate non-obvious truths through subtety that takes time to absorb. Signage (and design) is just the opposite: communicate rather mundane information quickly and unambiguously. Calori defines the pyramid model of signage, which encompasses the information content, the graphics, and the hardware. Design subdivides into the abstract information, concerned with hierarchies and placement, and graphics, concerned with symbols, diagrams, and typefaces. The book thoroughly addresses each of these, as well as the regulatory and legal concerns one is likely to encounter along the way. It also includes thirty-two pages of color photographs of finished signage programs, which are not to be missed.

As for The Heights, the book itself is intellectual service. Printed in full color, it’s a surprisingly detailed-yet-accessible look at the engineering and planning behind tall buildings. Want to know about cranes, air handlers, curtain walls, elevator safety, green roofs, fire sprinklers, floor plates, pile drivers, and window washers? It’s all there, with helpful illustrations. Section titles are printed in a 3D extruded typeface that resembles a building (for once, a justified use case) and the table of contents is done delightfully as an elevator directory, reading from bottom to top. Wayfinding is not mentioned in the text, but its principles are applied to the presentation itself.

Of course, the very act of creating a well-designed skyscraper contributes tremendously to the built environment. Such a building can provide living and working space for thousands of people for a century. Design decisions can become crucially important or confining decades after they were made. Unlike Calori’s laser-focus, the skyscrapers involve thousands of people of diverse education and wealth backgrounds, from construction workers to financiers, tenants to janitors. Construction on this scale is an act with huge societal ramifications. Engineering is not neutral, politically, socially, or ethically.

But the authors are undaunted. They strive to make objects, whether signs or skyscrapers, that make life more enjoyable, more comprehensible, and more fair for all who come into contact with them. Through technical competence, goal-oriented design, hard work, and luck, objects large and small come to enrich our lives. What kind of object do you want to make?

Infographics and Data Graphics

I’d like to set the record straight about two types of graphical documents floating around the internet. Most people don’t make a distinction between infographics and data graphics. Here are some of each – open them in new tabs and see if you can tell them apart.

No peeking!

No, really, stop reading and do it. I can wait.

Okay, had a look and made your categorizations? As I see it, dog food, energy, and job titles are infographics, and Chicago buildings, movie earnings, and gay rights are data graphics. Why? Here are some distinctions to look for, which will make much more sense now that you’ve seen some examples. Naturally these are generalizations and some documents will be hard to classify, but not as often as you might think.

Infographics emphasize typography, aesthetic color choice, and gratuitous illustration.
Data graphics are pictorially muted and focused; color is used to convey data.

Infographics have many small paragraphs of text communicate the information.
Data graphics are largely wordless except for labels and an explanation of the visual encoding.

In infographics, numeric data is scant, sparse, and piecemeal.
In data graphics, numeric data is plentiful, dense, and multivariate.

Infographics have many components that relate different datasets; sectioning is used.
Data graphics have single detailed image, or less commonly multiple windows into the same data.

An infographic is meant to be read through sequentially.
A data graphic is meant to be scrutinized for several minutes.

In infographics, the visual encoding of numeric information is either concrete (e.g. world map, human body), common (e.g. bar or pie charts), or nonexistent (e.g. tables).
In data graphics, the visual encoding is abstract, bespoke, and must be learned.

Infographics tell a story and have a message.
Data graphics show patterns and anomalies; readers form their own conclusions.

You may have heard the related term visualization – a data graphic is a visualization on steroids. (An infographic is a visualization on coffee and artificial sweetener.) A single bar, line, or pie chart is most likely a visualization but not a data graphic, unless it takes several minutes to absorb. However, visualizations and infographics are both generated automatically, usually by code. It should be fairly easy to add new data to a visualization or data graphic; not so for infographics.

If you look at sites like visual.ly which collects visualizations of all stripes, you’ll see that infographics far outnumber data graphics. Selection bias is partially at fault. Data graphics require large amounts of data that companies likely want to keep private. Infographics are far better suited to marketing and social campaigns, so they tend to be more visible. Some datasets are better suited to infographics than data graphics. However, even accounting for those facts, I think we have too many infographics and too few data graphics. This is a shame, because the two have fundamentally different worldviews.

An infographic is meant to persuade or inspire action. Infographics drive an argument or relate a story in a way that happens to use data, rather than allowing the user to infer more subtle and multifaceted meanings. A well-designed data graphic can be an encounter with the sublime. It is visceral, non-verbal, profound; a harmony of knowledge and wonder.

Infographics already have all the answers, and serve only to communicate them to the reader. A data graphic has no obvious answers, and in fact no obvious questions. It may seem that infographics convey knowledge, and data graphics convey only the scale of our ignorance, but in fact the opposite is true. An infographic offers shallow justifications and phony authority; it presents that facts as they are. (“Facts” as they “are”.) A data graphic does not foster any conclusion upon its reader, but at one level of remove, provides its readers with tools to draw conclusions. Pedagogically, infographics embrace the fundamentally flawed idea that learning is simply copying knowledge from one mind to another. Data graphics accept that learning is a process, which moves from mystery to complexity to familiarity to intuition. Epistemologically, infographics ask that knowledge be accepted on little to no evidence, while data graphics encourage using evidence to synthesize knowledge, with no prior conception of what this knowledge will be. It is akin to memorizing a fact about the world, or accepting the validity of the scientific method.

However, many of the design features that impart data graphics with these superior qualities can be exported back to infographics, with compelling results. Let’s take this example about ivory poaching. First off, it takes itself seriously: there’s no ostentatious typography and the colors are muted and harmonious. Second, subject matter is not a single unified dataset but multiple datasets that describe a unified subject matter. They are supplemented with non-numeric diagrams and illustrations, embracing their eclectic nature. Unlike most infographics, this specimen makes excellent use of layout to achieve density of information. Related pieces are placed in close proximity rather than relying on sections; the reader is free to explore in any order. This is what an infographic should be, or perhaps it’s worthy of a different and more dignified name, information graphic. It may even approach what Tufte calls “beautiful evidence”.

It’s also possible to implement a data graphic poorly. Usually this comes down to a poor choice of visual encoding, although criticism is somewhat subjective. Take this example of hurricanes since 1960. The circular arrangement is best used for months or other cyclical data. Time proceeds unintuitively counterclockwise. The strength of hurricanes is not depicted, only the number of them (presumably – the radial axis is not labeled!). The stacked bars make it difficult to compare hurricanes from particular regions. If one wants to compare the total number of hurricanes, one is again stymied by the polar layout. Finally, the legend is placed at the bottom, where it will be read last. Data graphics need to explain their encoding first; even better is to explain the encoding on the diagram itself rather than in a separate legend. For example, if the data were rendered as a line chart (in Cartesian coordinates), labels could be placed alongside the lines themselves. (Here is a proper data graphic on hurricane history.)

An infographic typically starts with a message to tell, but designers intent on honesty must allow the data to support their message. This is a leap of faith, that their message will survive first contact with the data. The ivory poaching information graphic never says that poaching is bad and should be stopped, in such simple words. Rather it guides us to that conclusion without us even realizing it. Detecting bias in such a document becomes much more difficult, but it also becomes much more persuasive (for sufficiently educated and skeptical readers). Similarly, poor data graphics obscure the data, either intentionally because they don’t support the predecided message, or unintentionally because of poor visual encoding. In information visualization, as in any field, we must be open to the hard process of understanding the truth, rather than blithely accepting what someone else wants us to believe.

I know which type of document I want to spend my life making. Psst, I’m graduating with a CS degree and looking for a job.

Brief Thoughts On Scratch

Previously, I’ve lambasted the children’s programming language Scratch for its cockpit’s worth of controls.  This encourages its users to try anything and see what works, rather than plan, predict, and understand exactly what each piece of code is doing. It’s instant gratification … and a tight feedback loop.

Scratch is not a tool to learn programming or metacognition; Scratch is a tool to create artistic displays that could not otherwise be created (by children). Scratch thus allows children to explore ideas not related to mathematics or programming. They have creative freedom, much like art class. And what elementary schooler produces anything particularly good, objectively speaking, in art class? So don’t judge the Scratch projects too harshly.

Scratch is a social platform, except that the socialization happens in real life. Get a few kids in a room using it, and they’ll share both creations and code,  motivate each other, and change goals on the fly. This differs from more mature programming, where one has a specific goal in mind. The other key difference is that most languages discourage straight up experimentation; one have to know what one is doing in order to do it. Scratch reverses this: a kid can learn what a command does through using it. This is because all the commands are displayed, ready to be used.

Not only displayed, but also labelled, unlike the Khan Academy programming language that drops down four numbers with no context. It’s a way to slyly introduce relative and absolute motion – move up by, move to – in a way that lets kids work out the rules. No, they won’t work out all the rules, but I think they’ll come to fewer incorrect conclusions (misconceptions) in a reactive medium than with marks on paper. They will figure it out later, much later.

Scratch is a way to put Lego bricks into the bucket. The kid will reassemble them into many different knowledge structures over the years before creating something strong and beautiful – an educated mind. It’s during that process, that struggle, that they can learn to program with planning and expressiveness, rather than tacking on bricks ad-hoc. It’s a stage everyone goes through, and Scratch can help a child make the most of it. But don’t confuse acquiring bricks with figuring out how to assemble them.

This isn’t to say that Scratch as it exists is perfect; far from it. We need to keep rethinking what tools are best to give to our children (and adults, for that matter). But I’m backing off my previous stance that guided minimalism is the answer. (Or is my new “wait and let them figure it out” view too fatalist?)

Critical Complexity

Here’s a task for you: draw a circle radius three around the origin.

What system do you use? Well, you could use an intuitive system like Piaget’s turtle. Walk out three, turn ninety degrees, and then walk forward while turning inward. By identifying as a specific agent, you take advantage of having a brain that evolved to control a body. If it doesn’t seem intuitive, that’s because you’ve been trained to use other systems. Your familiarity is trumping what comes naturally, at least to children.

You’re probably thinking in Cartesian coordinates. You may even recall that x^2 + y^2 = 3^2 will give you the circle I asked for. But that’s only because you memorized it. Why this formula? It’s not obvious that it should be a circle. It doesn’t feel very circular, unless you fully understand the abstraction beneath it (in this case, the Pythagorean theorem) and how it applies to the situation.

Turtle geometry intuitively fits the human, but it’s limited and naive. Cartesian geometry accurately fits your monitor or graph paper, the technology, but it’s an awkward way to express circles. So let’s do something different. In polar coordinates, all we have to say is r=3 and we’re done. It’s not a compromise between the human and the technology, it’s an abstraction – doing something more elegant and concise than either native form. Human and technology alike  stretch to accommodate the new representation. Abstractions aren’t fuzzy and amorphous. Abstractions are crisp, and stacked on top of each other, like new shirts in a store.

We’ve invented notation that, for this problem, compresses the task as much as possible. The radius is specified; the fact that it’s a circle centered around the origin are implicit in the conventional meaning of r and the lack of other information. It’s been maximally compressed (related technical term: Kolmogorov complexity).

Compression is one of the best tools we have for fighting complexity. By definition, compression hides the meaningless while showing the meaningful. It’s a continuous spectrum, on which sits a point I’ll call critical complexity. Critical complexity is the threshold above which a significant abstraction infrastructure is necessary. But that definition doesn’t mean much to you — yet.

Think of knowledge as terrain. To get somewhere, we build roads, which in our metaphor are abstraction. Roads connect to each other, and take us to new places. It was trivial to abstract Cartesian coordinates into polar by means of conversions. This is like building a road, with one end connecting to the existing street grid and another ending somewhere new. It’s trivial to represent a circle in polar coordinates. This is what we do at the newly accessible location. We’ve broken a non-trivial problem into two trivial pieces – although it wasn’t a particularly hard problem, as otherwise we wouldn’t have been able to do that.

Delivering these words to your machine is a hard problem. You’re probably using a webbrowser, which is written in software code, which is running on digital electronics, which are derived from analog electronics obeying Maxwell’s equations, and so on. But the great thing about abstractions is that you only need to understand the topmost one. You can work in polar coordinates without converting back to Cartesian, and you can use a computer without obtaining multiple engineering degrees first. You can build your own network of roads about how to operate a computer, disconnected from your road network about physics.

Or perhaps not disconnected, but connected by a tunnel through the mountain of what you don’t understand. A tunnel is a way to bypass ignorance to learn about other things based on knowledge you don’t have, but don’t need. Of course, someone knows those things – they’ve laboriously built roads over the mountain so that you can cruise under it. These people, known as scientists and engineers, slice hard problems into many layers of smaller ones. A hard problem may have so many layers that, even if each is trivial on its own, they are non-trivial collectively. That said, some problems are easier than they look because our own sensemaking abstractions blind us.

If you want to write an analog clock in JavaScript, your best bet is to configure someone else’s framework. That is, you say you want a gray clockface and a red second hand, and the framework magically does it. The user, hardly a designer, is reduced to muttering incantations at a black box hoping the spell will work as expected. Inside the box is some 200 lines or more, most of it spent on things not at all related to the high-level description of an analog clock. The resulting clock is a cul-de-sac at the end of a tunnel, overlooking a precipice.

By contrast, the nascent Elm language provides a demo of the analog clock. Its eight lines of code effectively define the Kolmogorov complexity: each operation is significant. Almost every word or number defines part of the dynamic drawing in some way. To the programmer, the result is liberating. If you want to change the color of the clockface, you don’t have to ask the permission of a framework designer, you just do it. The abstractions implicit in Elm have pushed analog clocks under the critical complexity, which is the point above which you need to build a tunnel.

There’s still a tunnel involved, though: the compiler written in Haskell that converts Elm to JavaScript. But this tunnel is already behind us when we set out to make an analog clock. Moreover, this tunnel leads to open terrain where we can build many roads and reach many places, rather than the single destination offered by the framework. What’s important isn’t the avoidance of tunnels, but of tunnels to nowhere. Each abstraction should have a purpose, which is to open up new terrain where abstractions are not needed, because getting around is trivial.

However, the notion of what’s trivial is subjective. It’s not always clear what’s a road and what’s a tunnel. Familiarity certainly makes any abstraction seem simpler. Though we gain a better grasp on an abstraction by becoming familiar with it, we also lose sight of the underlying objective nature of abstractions: some are more intuitive or more powerful than others. Familiarity can be born both by understanding where an idea comes from and how it relates to others, and by practicing using the idea on its own. I suspect that better than either one is both together. With familiarity comes automaticity, where we can quickly answer questions by relying on intuition, because we’ve seen them or something similar before. But depending on the abstraction, familiarity can mean never discarding naïveté (turtle), contorting into awkward mental poses (Cartesian) – or achieving something truly elegant and powerful.

It’s tempting to decry weak or crippling abstractions, but they too serve a purpose. Like the fancy algorithms that are slow when n is small, fancy abstractions are unnecessary for simple problems. Yes, one should practice using them on simple problems as to have familiarity when moving into hard ones. But before that, one needs to see for oneself the morass weak or inappropriately-chosen abstractions create. Powerful abstractions, I am increasingly convinced, cannot be be constructed on virgin mental terrain. For each individual, they must emerge from the ashes of an inferior system that provides both experience and motivation to build something stronger.

As We May Have Thought

Vannevar Bush wanted to build machines that made people smarter. His 1945 paper, As We May Think, described analog computers that captured and stored information, the earliest vision of today’s internet. All of Bush’s hopes for chemical photography have been surpasses by today’s digital cameras, and digital storage media are more compact than the most hopeful predictions of microfilm. He also predicts dictation, and though today’s software does a passable but not perfect job, it has not reached the level of ubiquity Bush predicts. He is also wrong about the form factor of cameras, predicting a walnut-sized lens mounted like a miner’s lamp. The result is similar to Google Glass, and no other product:

One can now picture a future investigator in his laboratory. His hands are free, and he is not anchored. As he moves about and observes, he photographs and comments. Time is automatically recorded to tie the two records together.

As for selecting information from the ensuing gigantic database, Bush posits the “Memex”, a desk with displays built into it. The memex is personal, allowing users to connect pieces of information together into trails for later examination. The memex is personal and built on connections, much like the mind.

The late Douglas Engelbart expanded on the purely hypothetical Memex with NLS, short for oNLine System. In “the mother of all demos”, he showed how users traverse and manipulate trees of data, with rich transclusion of content. Unlike the Memex, real-time sharing is possible by way of video chat. Like the memex, NLS was primary text, and the user-facing component was the size of a desk.

And yet … Bush and Englebart’s systems are not psychologically or sociologically realistic. Though Bush was writing in 1945, his vision seemed Victorian: a facade of proper intellectualism with no grounding in the less dapper side of human nature. One can hardly imagine multimedia beyond classical music and Old Master paintings emanating from the memex.  Bush used the effectiveness of Turkish bows in the crusades as an example of what one could research on a Memex. He missed the target. The Memex and NLS were designed for a race of hyper-rational superhumans that do not exist.

The fictitious enlightened user would emphasize restraint, but today’s technology can, for all intents and purposes, do anything. The ability to do anything is less productive and more dangerous than it sounds. Intellectually, such a system encourages slapdash and incomplete thought. It does not force you to abandon weaker ways of thinking; it gives you no guidance towards what will work, what will work well, and what will not work at all. Sociologically, the availability of information on a scale beyond what Bush could have dreamed hasn’t made us an enlightened society. Having correct information about (for example) evolution readily available online has not made a dent in the number of people who read Genesis literally. And it gets worse.

Moore’s law may be the worst thing to happen to information technology. With computing so cheap and so ubiquitous, with the ability to do anything, we have overshot the island of scarcity inhabited by Bush and Engelbart and into the land of social media, entertainment, and vice. The universal systems for the betterment of humanity have fallen to fragmented competitors in an open market. The emphasis on mobile these last six years has led to apps of reduced capability, used in bursts, on small screens with weak interaction paradigms. This is what happens when there’s more computing power in your pocket than Neil Armstrong took to the moon: we stop going to the moon.

Recreational computation is here to stay, but we may yet partially reclaim the medium. Clay Shirky is found of pointing out that erotic novels appeared centuries before scientific journals. Analogously, we should not be deterred by the initial explosion of inanity accompanying the birth of a new, more open medium.

I can only hazard a guess as to how this can be done for recreational computing: teach the internet to forget. (h/t AJ Keen, Digital Vertigo) One’s entire life should not be online (contrary to Facebook’s Timeline – it’s always hard to change ideas when corporations are profiting on them). A good social website would limit the ways in which content can be produced and shared, in an attempt to promote quality over quantity. Snapchat is a promising experiment in this regard. There’s been talk of having links decay and die over time, but this sees like a patch on not having proper transclusion in the first place.

As for programming, though, the future is constrained, even ascetic. If Python embodies the ability to do anything, then the future is Haskell, the most widely-used [citation needed] functional programming language.

Functional programming is a more abstract way of programming than most traditional languages, which use the imperative paradigm. If I had to describe the difference between imperative programming and functional programming to a layperson, it would be this: imperative programming is like prose, and functional programming is like poetry. In imperative programming, it’s easy to tack on one more thing. Imperative code likes to grow. Functional code demands revision, and absolute clarity of ideas that must be reforged for another feature to be added. In functional languages, there are fewer tools available, so one needs to be familiar with most of them in order to be proficient. Needless to say, imperative languages predominate outside of the ivory tower. Which is a shame, because imperative languages blithely let you think anything.

The problem with thinking anything is similar to doing anything: there’s no structure. But if we can’t think anything than some good ideas may remain unthought. There is a tension between thinking only good ideas and thinking any idea. In theory at least, this is the relationship between industry and academia. While companies want to produce a product quickly,  academia has developed programming paradigms that are harder to use in the short term but create more manageable code over time. These are all various ways of imposing constraints, of moving away from the ability to do anything. Maybe then we’ll get something done.

Powerful Ways of Thinking

My principle, v0.1

Powerful Ways of Thinking:

Emphasize the meaningful and hide the meaningless

See the world as
comprehensible, not mysterious
malleable, not fixed

Use abstraction to make the complex simple, but never deceptively or impenetrably so, and never make the simple complex

Define notation that balances elegant orthogonality with practical readability

Are defined not by dogma but by goals and methodologies that lead to knowledge

Conform to neither the workings of the machine nor the naiveté of the human

Must be discovered, taught, and practiced; they are not intuitive

Permit objective comparisons and contrasts on which arguments may be based

Build diverse and meritocratic communities that grow the best creations and prune the worst

Provide large rewards in the long-term, often at the cost of short-term loss

Are a vision of what should be, not of what already exists

Define their own limits; they do not pretend to be universally or perpetually valid

Technologies and institutions must selectively promote powerful ways of thinking.


Get every new post delivered to your Inbox.

Join 29 other followers