Creativity

Adding simplicity

Posted on by John

Simplicity is costly. You have to give up something to achieve it. You can’t just add it on top. William Bridges illustrates this in his book The Way of Transition where he describes his moving out to the country.

… I had been infatuated with Thoreau’s Walden and its story of living a basic life, close to nature. The heart of that undertaking, he had written, was to simplify your life. … In retrospect, I can see that although I thought that this was what I was doing, I was really just trying to add simplicity to my life. In addition to all the old things I had been doing … Of course, my life grew more and more complicated in the process.

A simplification has to remove or replace something else. You can’t just add on simplicity.

There may be an exception to this. Sometimes you can add a few missing pieces to make something more symmetric. In that case, the additions simplify the whole. (Mendeleev did something like this when he drew his periodic table.) Even then, I suppose you could say you’re removing the asymmetry. In any case, achieving simplicity usually requires more subtraction than addition.

Related posts

The world has changed. Do work that matters.

Posted on by John

The latest episode of the Startup Success Podcast features Seth Godin talking about his new book Linchpin.

Bob Walsh: What’s next for Seth Godin?

Seth Godin: This. This is my life’s work. This is what I didn’t realize I was working on for the last ten years but I am. There’s no new book in the works. There’s just this mission to help people see how the world just changed really violently and to encourage them to do work that matters.

Seth Godin has always been passionate about his projects, but this one is different. His clarity and intensity are remarkable.

Related posts

Random improvisation subjects

Posted on by John

Destination ImagiNation is a non-profit organization that encourages student creativity. This is my family’s first year to participate in DI and it has been a lot of fun. One of the things that impresses me most about DI is that they have strict rules limiting adult input.

This weekend I was an appraiser at a DI competition for an improvisation challenge. Teams could prepare for the overall format of the challenge, but some elements of the challenge were randomly selected on the day of the competition. This year the improvisations centered around endangered things. Teams were given a list of 10 endangered things ahead of time, but they wouldn’t know which thing would be theirs until just before they had to perform. Some of the things on the list were endangered animals, such as the giant panda. There were also other things in danger of disappearing, such as the VHS tape. The students also had to use a randomly chosen stock character and had to include a character with a randomly chosen “unimpressive superpower.”

There were 13 teams in the elementary division. What would you expect from 13 teams randomly selecting 10 endangered things? Obviously some endangered thing has to be chosen at least twice. Would you expect every item on the list to be chosen at least once? How often do you expect the most common item would be chosen?

In our case, three teams were assigned “glaciers” and five were assigned “the landline telephone.” The other items were assigned once or not at all. (No one was assigned “the Yiddish language”. Too bad. I really wanted to see what the students would do with that one.)

Is there reason to suspect that the assignments were not random? How likely is it that in a competition of 13 teams that five or more teams would be given the same subject? How likely is it that every subject would be used at least once? See an explanation here. Make a guess before looking at my answer.

Here’s some Python code you could use to simulate the selection of endangered things.

from random import random

num_reps     = 100000 # number of simulation repetitions
num_subjects = 10     # number of endangered things
num_teams    = 13     # number of teams competing

def maxperday():
    tally = [0] * num_subjects
    for i in range(num_teams):
        subject = int(random()*num_subjects)
        tally[subject] += 1
    return max(tally)

total = 0
for rep in range(num_reps):
    if maxperday() >= 5:
        total += 1
print float(total)/num_reps

Doing good work with bad tools

Posted on by John

Charlie Parker playing plastic Grafton saxophone

Charlie Parker was one of the greatest jazz musicians. But unlike most artists, he had a cavalier attitude toward his equipment. He would pawn his saxophone for drug money and show up for a concert without an instrument. He assumed that he could always borrow a saxophone at the last minute. He even used a plastic saxophone for one concert. Parker could take a cheap piece of plastic and make it sound good.

Good equipment helps. I’ve played cheap saxophones and professional quality saxophones, and I much prefer the latter. But a good sax didn’t make me sound like Charlie Parker, nor did a cheap sax make Charlie Parker sound like me. A poor craftsman blames his tools.

For centuries people have searched for the secret of Stradivarius violins. What did Antonio Stradivari do to create his legendary instruments? Was there something special about the wood he used? Something special about the varnish? A new theory says that there was nothing unusual about the materials he used and that he simply did excellent work.

It’s hard to think of a worse programming environment than DOS batch files. But I worked with someone who was able to do amazing things with batch files.

Hugh MacLeod calls it “hiding behind pillars” when you think you must have the best tools before you can work. He summarizes hiding behind pillars this way:

The more talen­ted some­body is, the less they need the props. Mee­ting a per­son who wrote a mas­ter­piece on the back of a deli menu would not sur­prise me. Mee­ting a per­son who wrote a mas­ter­piece with a sil­ver Car­tier foun­tain pen on an anti­que wri­ting table in an airy SoHo loft would SERIOUSLY sur­prise me.

Related posts

Less isn’t more. Just enough is more.

Posted on by John

From Ten Things I Have Learned by Milton Glaser:

Being a child of modernism I have heard this mantra all my life. Less is more. One morning upon awakening I realised that it was total nonsense … If you look at a Persian rug, you cannot say that less is more because you realise that every part of that rug, every change of colour, every shift in form is absolutely essential for its aesthetic success. You cannot prove to me that a solid blue rug is in any way superior. … However, I have an alternative to the proposition that I believe is more appropriate. ‘Just enough is more.’

Related posts

Creativity and faith

Posted on by John

From Eugene Peterson:

Creativity is difficult. When you are being creative, you’re living by faith. You don’t know what’s next because the created, by definition, is what’s never been before. So you’re living at the edge of something in which you’re not very confident. You might fail: in fact, you almost certainly will fail a good part of the time. All the creative persons I know throw away most of the stuff they do.

Related posts

Too much time on their hands?

Posted on by John

Dan Wineman shared a profound insight on Twitter:

You say “looks like somebody has too much time on their hands” but all I hear is “I’m sad because I don’t know what creativity feels like.”

In place of “creativity” Wineman might have as easily said “persistence.” I found Wineman’s quote in a post by Dan Meyer responding to criticism of his research projects.

I’ve said that someone has too much time on their hands, but not since I read Meyer’s post. I see now that the phrase is often a sour grapes response to creativity. I don’t want to do that anymore.

When we see that someone has spent a thousand hours on a project that we think was a frivolous, it’s easy to say “what a waste of time.” We think how much good could have been done with that same amount of effort. But what was the realistic alternative? If that same person had spent a thousand hours in front of their television instead, no one would ever know and no one would ever criticize them. Instead, they created something.

Opening black boxes

Posted on by John

black box

Rookie programmers don’t know how to reuse code. They write too much original code because they either don’t know about libraries or they don’t know how to use them. And if they do reuse someone else’s code, they copy and paste it, creating maintenance problems.

The next step in professional development is learning to reuse code. Encapsulation! Black boxes! Buy, don’t build! etc.

But this emphasis on reuse and black boxes can go too far. We can be intimidated by these black boxes and afraid to open them. We can come to believe the black boxes were created by superior beings. We can spend more time inferring the behavior of the black boxes than it would take to open them up or rewrite them. Then we pile leaky abstraction on top of leaky abstraction when we treat our own code as black boxes.

Joe Armstrong said in Coders at Work

Over the years I’ve kind of made a generic mistake … to not open the black box. … It’s worthwhile seeing if the direct route is quicker than the packaged route.

Several of the programmers who were interviewed in the book made similar remarks. They contribute part of their success to being unafraid of black boxes. They gained experience and confidence by taking things apart to see how they work.

Donald Knuth once said in an interview

I also must confess to a strong bias against the fashion for reusable code. To me, “re-editable code” is much, much better than an untouchable black box or toolkit. I could go on and on about this. … you’ll never convince me that reusable code isn’t mostly a menace.

Knuth returns to this theme in Coders at Work.

There’s this overemphasis on reusable software where you never get to open up the box … It’s nice to have these black boxes but, almost always, if you can look inside the box you can improve it …

Well, Knuth can almost always improve any code he finds. Less talented programmers need to be more humble. But too often programmers who are talented enough to make improvements are reluctant to do so. As Yeats said in his poem The Second Coming,

The best lack all conviction, while the worst are full of passionate intensity.

In any discussion of opening black boxes, someone will bring up the analogy of cars: Not everyone needs to know how a car works inside. I would agree that drivers no longer need to understand how a car works, but automotive engineers do. The problem isn’t users who don’t understand how software works, it’s software developers who don’t understand how software works.

Of course software libraries are extremely valuable. Knuth goes too far when he says reusable code is usually a menace. But I see a disturbing lack of curiosity among programmers. They are far too willing to use code they don’t understand.

Related post: Reusable code versus re-editable code