The Future of Imagination

Venkatesh Rao had a great piece last week on imagination as a survival skill. Here is the gist:

I suspect failure-to-self-actualize will become the leading cause of death (or madness) in the developed world.

Rao defines “self-actualization” as

the imaginative embodiment of internal realities (what the daemon feels) in the form of a dent in the universe: a surprising and free external reality that actualizes a new possibility for all

and “imagination” as

the ability to create unpredictable new meaning while generating more freedom than you consume.

The post is very good, worth reading twice. However, there is one key shift that Rao overlooks. He focuses on imagination as an essential ability for the wealthy (the “one percent”), but it has even bigger implications for a future of 100 percent unemployment.

This change is coming, slowly but surely. It’s hard to imagine a future where “the robots take over” entirely, but we are already seeing a society where the poorest have more leisure time than the wealthiest. As Arnold Kling writes:

The prediction I would make is that we would see a lot more leisure. For those whose skill adaptation is adequate, that leisure will take the form of earlier retirement, later entry into the work force, or shorter hours. For those whose skill adaptation is inadequate, that leisure will show up as unemployment or reluctant withdrawal from the labor force.

I think that if you look only at males in isolation, you will see this in the data. That is, men are working much less than they used to. For some men, this leisure is very welcome, but for others it is not. In that sense, I think that we should look at the fears of the early 1960s not as quaint errors but instead as fairly well borne out.

The availability of inexpensive leisure (think cable TV and Youtube) has increased the reservation wage of low-wage workers. This has made unskilled individuals less willing to work for near-minimum wage jobs, as detailed in this New York Times article.

Self-actualization of highly skilled individuals as described by Rao has created so much freedom for those at the bottom of the income distribution that they now choose not to work. In their own words, though, the willingly unemployed do not seem to live fulfilling lives. Self-actualization is as important for them as it is for the wealthy, but they suffer from a failure of imagination.

Design Patterns for Cooking

Last week Alexey introduced the idea of cooking patterns:

A recipe is basically a fixed set of actions and ingredients, while cooking techniques are just the possible actions. If we invent cooking patterns – an abstraction on top of each ingredient / action pair – we could have more understanding of the dish we are preparing while keeping the flexibility in ingredient and technique choice.

Let’s take fritters as an example. Wikipedia says the following:

Fritter is a name applied to a wide variety of fried foods, usually consisting of a portion of batter or breading which has been filled with bits of meat, seafood, fruit, or other ingredients.

A pattern in its most obvious form. Notice the “wide variety”, a fixed ingredient (batter) and a list of possible variables (meat, seafood, vegetables, fruit) that could influence the fritters you end up making.

I find this idea very exciting, because I enjoy cooking and am also in the process of learning more about software design patterns.

Cooking patterns seem like an accessible way to introduce beginners to more abstract ideas about software, too. Algorithms are often described as “recipes,” and this is a nice way to build on that concept.

For leveling up your cooking skills, ChefSteps looks promising. Their resources include classes, projects, and an ingredients wiki. I have signed up for one class and plan to follow up on this recommendation after completing it.

If you are interested in cooking patterns, check out the Github repo or read the full article.

A Checklist for Using Open Source Software in Production

A great majority of the web is built on open source software. Approximately two-thirds of public servers on the internet run a *nix operating system, and over half of those are Linux. The most popular server-side programming languages also tend to be open source (including my favorite, Ruby). This post is about adding a new open source library to an existing code base. What questions should you ask before adding such a dependency to a production application?

The first set of questions are the most basic. A “no” to any of these should prompt you to look elsewhere.
  • Is the project written in a language you support? Is it in a language you support? If not, is it compatible (e.g. through stdin/stdout or by compiling to your language of choice)?
  • Is the project in a version of of the language you support? If it’s written in Python 3 and you only support Python 2, for example, using this library could lead to headaches.
  • Can you use the project in your framework of choice (e.g. Rails or Django)?
  • Are there conflicts with other libraries or packages you’re currently using? (This is probably the hardest question to answer, and you might not know until you try it.)
Assuming there are no immediate technical barriers, the next questions to ask are of the legal variety. Open source licenses come in many flavors. In the absence of a license, traditional copyright rules apply. Be especially careful if the project you are investigating uses the GPL license–even basing the code you write off of a GPL open source project can have serious legal ramifications. There’s a great guide to OSS licenses on Github. If you’re the author or maintainer of an open source project checkout
The next thing to consider is whether and how the project is tested. If there is not an automated test suite, consider starting one as your first contribution to the project and be very reluctant to add the project to your application. Other related questions include:
  • Are there unit tests?
  • Are there integration tests?
  • What is the test coverage like?
  • Do the tests run quickly?
  • Are the tests clearly written?
Finally, by using an open source project you are also joining a community of developers. None of these questions are necessarily show-stoppers but knowing the size of the community and the tone of its discourse can save you pain down the road.
  • Is the project actively maintained? When was the last commit?
  • Does the community have a civil, professional style of debate and discussion?
  • Is there only one developer/maintainer who knows everything? This doesn’t have to be a deal breaker. However, if there is a single gatekeeper you should make sure you understand the basics of the code and could fork the project if necessary.

This is by no means an exhaustive list but these questions can serve as a useful checklist before adding an open source as a dependency for your project.