“The most creative spaces are those which hurl us together. It is the human friction that makes the sparks.”

Jonah Lehrer in the New Yorker lays out how Brainstorming exercises don’t add up to what we think, and shows us that diversity leads to more innovative ideas in “Groupthink: The Brainstroming Myth”:

The fatal misconception behind brainstorming is that there is a particular script we should all follow in group interactions. The lesson of Building 20 is that when the composition of the group is right—enough people with different perspectives running into one another in unpredictable ways—the group dynamic will take care of itself. All these errant discussions add up. In fact, they may even be the most essential part of the creative process. Although such conversations will occasionally be unpleasant—not everyone is always in the mood for small talk or criticism—that doesn’t mean that they can be avoided. The most creative spaces are those which hurl us together. It is the human friction that makes the sparks.

Read the whole thing.

Rebuttal: Scott Berkun: “In Defense of Brainstorming”.

Steve Jobs: “computer science is a liberal art, it’s something everyone should know how to use, at least, and harness in their life”

“Quotes from Steve Jobs Lost Interview”:

“Learning to program teaches you how to think. Computer science is a liberal art.”

NPR.org: “Steve Jobs: ‘Computer Science Is A Liberal Art'”:

“In my perspective … science and computer science is a liberal art, it’s something everyone should know how to use, at least, and harness in their life. It’s not something that should be relegated to 5 percent of the population over in the corner. It’s something that everybody should be exposed to and everyone should have mastery of to some extent, and that’s how we viewed computation and these computation devices”

Related:

“Steve Jobs Lost Interview”

YouTube: WGBH: “Steve Jobs 1990 Lost Interview Part 1”:

Reddit.com: “Want: a non-technical description of CS”

Beginner’s Eyes: on storytelling and growth

John D. Cook, in a short, poetic post, describes how experts end up where they started, as beginners, and why, in his blog post “Coming full circle”. A few folks in his comments thread make the connection with Zen’s concept of “Shoshin”, the Beginner’s Mind, and it does, but I hear echoes of another journey just as strongly.

YouTube: “The Hero’s Journey / Monomyth”

Programming, Math, and Computational Thinking: on education

Actually, this post will feature a few reads and resources for you that are part of a theme – the need to change K-12 education to face the realities of today and tomorrow, instead of preparing them for a world that has already turned. To do so will require children to gain a working understanding of the use of, and creation of, software. This is as important today as reading, writing and mathematics and it helps provide invaluable tools to build on, and strengthen, those foundational parts of children’s education.

Google Edu serves a terrific resource for educators and students that brings together many of these concepts – “Exploring Computational Thinking”. The lesson plan includes Python exercises that help illustrate computational thinking while strengthening math skills.

Why this is important

Over 10 years ago Lawrence Lessig exclaimed, “The Code Is the Law”, and in a series of articles, presentations, and an influential book spread the idea among the digerati, but interestingly enough, those outside of technology didn’t adopt the idea as a truism.

Douglas Rushkoff recently released his most recent book, “Programed or be Programmed” that took the concept further and declared a course of action for future educators.

Kevin Slavin: Kevin Slavin: How algorithms shape our world:

YouTube: “TED: Conrad Wolfram: Teaching kids real math with computers”:

Dizzying but invisible depth: on complexity

Jean-Baptiste Queru, on his Google+ profile, posts a poetic and doozy of a post, “Dizzying but invisible depth”:

Today’s computers are so complex that they can only be designed and manufactured with slightly less complex computers. In turn the computers used for the design and manufacture are so complex that they themselves can only be designed and manufactured with slightly less complex computers. You’d have to go through many such loops to get back to a level that could possibly be re-built from scratch.

Once you start to understand how our modern devices work and how they’re created, it’s impossible to not be dizzy about the depth of everything that’s involved, and to not be in awe about the fact that they work at all, when Murphy’s law says that they simply shouldn’t possibly work.

For non-technologists, this is all a black box. That is a great success of technology: all those layers of complexity are entirely hidden and people can use them without even knowing that they exist at all. That is the reason why many people can find computers so frustrating to use: there are so many things that can possibly go wrong that some of them inevitably will, but the complexity goes so deep that it’s impossible for most users to be able to do anything about any error.

Metrics and damn metrics: on systems

Sometimes we get caught in numbers and miss what’s real. This can happen especially when we focus on the wrong numbers writes Arpit Mathur in a sharp post. I’d add even if you were looking at the right numbers, without context, just like a soundbite, you could derive the wrong lessons or encourage behavior that you didn’t desire.

Always ask: What is it we are trying to effect or learn about? Are we looking at the right things? Do we have the context necessary to understand it?

Related:

“Systems Thinking, Lean and Kanban”: “Creating Useful Measures”

Michael Feathers: Rocky Mountan Ruby 2011 Keynote: “Code Blindness” – fantastic – watch the whole thing.

Impermanence and Software Design: on systems

When you’re building software, it is probably best to look at things half-Buddhist. Kent Beck writes about building software that won’t be around longer than him in a recent Facebook note:

…nothing I am doing now with software will remain in a hundred years. Indeed, there was a time not long ago when the only software I had ever written that was still running was JUnit. Thousands of programs started, and my work was in danger of becoming extinct.

I could try to achieve timelessness in my designs and encourage others to do the same, but in the end nothing I program will outlive me. It would be easy to despair over this, to go into my shell and settle for “good enough”. To do so would be to ignore both the immediate impact of my work, used by hundreds of millions of people today (one of the great things about working at Facebook), and the second order effects of my work on the lives and attitudes of others. No, my programs won’t be here in a century, but my work still matters.

Related:

Michael Mehaffy and Nikos Salingaros: “The Pattern Technology of Christopher Alexander”: “We have to remember that software engineers, by nature of their work, have a big problem. Their job is not to solve problems for computers, but for human beings; the computers are only tools in that process.”

Case Statement: “Articulate Coding” – his first post – a good one – keep it up!

InfoQ: Kent Beck: “Responsive Design” 1hr Presentation. Worth it!

On People, Process, and Passion and Persistence

My boss back at Bell Atlantic, who became my friend and mentor, Pat Trongo, had the following quote from Peter Senge’s “The Fifth Discipline” on his cube wall in big bold letters.

I found it inspirational back then. But now I am blessed to see evidence of this pattern in life daily – Great teams committed to a purpose accomplish great things.

The committed person brings an energy, passion,
and excitement that cannot be generated if you
are only compliant, even genuinely compliant.

The committed person doesn’t play by the rules
of the game. He is responsible for the game.

If the rules of the game stand in the way of
achieving the vision, he will find ways to change
the rules.

A group of people truly committed to a common
vision is an awesome force.

They can accomplish the seemingly impossible.

I am as blown away by this as I am with the OccupyPhilly protest teamwork I saw today, as I am with my co-workers who are one of the greatest teams I’ve seen in my career.

Great teams are everything. They don’t just ‘happen’ and require investments in trust, empathy, accountability, honesty, and crazy foolishness to grow. And when you see them you can’t help but be in awe.

On ever growing complexity in programming: on systems

Edsger W. Dijkstra gave a lecture, in 1972, that has since been come to be called “The Humble Programmer”. It’s a short piece that explains why software development, why programming, was growing more, not less complex over time, and some inspiration to be found in the dealing with it. There’s some choice quotes in here that I’m going to include, but read the whole thing.

On LISP:

With a few very basic principles at its foundation, it has shown a remarkable stability. Besides that, LISP has been the carrier for a considerable number of in a sense our most sophisticated computer applications. LISP has jokingly been described as “the most intelligent way to misuse a computer”. I think that description a great compliment because it transmits the full flavour of liberation: it has assisted a number of our most gifted fellow humans in thinking previously impossible thoughts.

Lets call it TDD before TDD was coined:

Today a usual technique is to make a program and then to test it. But: program testing can be a very effective way to show the presence of bugs, but is hopelessly inadequate for showing their absence. The only effective way to raise the confidence level of a program significantly is to give a convincing proof of its correctness. But one should not first make the program and then prove its correctness, because then the requirement of providing the proof would only increase the poor programmer’s burden. On the contrary: the programmer should let correctness proof and program grow hand in hand.

On decomposing systems:

It has been suggested that there is some kind of law of nature telling us that the amount of intellectual effort needed grows with the square of program length. But, thank goodness, no one has been able to prove this law. And this is because it need not be true. We all know that the only mental tool by means of which a very finite piece of reasoning can cover a myriad cases is called “abstraction”; as a result the effective exploitation of his powers of abstraction must be regarded as one of the most vital activities of a competent programmer. In this connection it might be worth-while to point out that the purpose of abstracting is not to be vague, but to create a new semantic level in which one can be absolutely precise. Of course I have tried to find a fundamental cause that would prevent our abstraction mechanisms from being sufficiently effective. But no matter how hard I tried, I did not find such a cause. As a result I tend to the assumption —up till now not disproved by experience— that by suitable application of our powers of abstraction, the intellectual effort needed to conceive or to understand a program need not grow more than proportional to program length. But a by-product of these investigations may be of much greater practical significance, and is, in fact, the basis of my fourth argument. The by-product was the identification of a number of patterns of abstraction that play a vital role in the whole process of composing programs. Enough is now known about these patterns of abstraction that you could devote a lecture to about each of them.

On education:

As each serious revolution, it will provoke violent opposition and one can ask oneself where to expect the conservative forces trying to counteract such a development. I don’t expect them primarily in big business, not even in the computer business; I expect them rather in the educational institutions that provide today’s training and in those conservative groups of computer users that think their old programs so important that they don’t think it worth-while to rewrite and improve them. In this connection it is sad to observe that on many a university campus the choice of the central computing facility has too often been determined by the demands of a few established but expensive applications with a disregard of the question how many thousands of “small users” that are willing to write their own programs were going to suffer from this choice. Too often, for instance, high-energy physics seems to have blackmailed the scientific community with the price of its remaining experimental equipment. The easiest answer, of course, is a flat denial of the technical feasibility, but I am afraid that you need pretty strong arguments for that. No reassurance, alas, can be obtained from the remark that the intellectual ceiling of today’s average programmer will prevent the revolution from taking place: with others programming so much more effectively, he is liable to be edged out of the picture anyway.

There may also be political impediments. Even if we know how to educate tomorrow’s professional programmer, it is not certain that the society we are living in will allow us to do so. The first effect of teaching a methodology —rather than disseminating knowledge— is that of enhancing the capacities of the already capable, thus magnifying the difference in intelligence. In a society in which the educational system is used as an instrument for the establishment of a homogenized culture, in which the cream is prevented from rising to the top, the education of competent programmers could be politically impalatable.

On recognizing the difficulty, challenge, and opportunity:

Automatic computers have now been with us for a quarter of a century. They have had a great impact on our society in their capacity of tools, but in that capacity their influence will be but a ripple on the surface of our culture, compared with the much more profound influence they will have in their capacity of intellectual challenge without precedent in the cultural history of mankind. Hierarchical systems seem to have the property that something considered as an undivided entity on one level, is considered as a composite object on the next lower level of greater detail; as a result the natural grain of space or time that is applicable at each level decreases by an order of magnitude when we shift our attention from one level to the next lower one. We understand walls in terms of bricks, bricks in terms of crystals, crystals in terms of molecules etc. As a result the number of levels that can be distinguished meaningfully in a hierarchical system is kind of proportional to the logarithm of the ratio between the largest and the smallest grain, and therefore, unless this ratio is very large, we cannot expect many levels. In computer programming our basic building block has an associated time grain of less than a microsecond, but our program may take hours of computation time. I do not know of any other technology covering a ratio of 10/10 or more: the computer, by virtue of its fantastic speed, seems to be the first to provide us with an environment where highly hierarchical artefacts are both possible and necessary. This challenge, viz. the confrontation with the programming task, is so unique that this novel experience can teach us a lot about ourselves. It should deepen our understanding of the processes of design and creation, it should give us better control over the task of organizing our thoughts. If it did not do so, to my taste we should not deserve the computer at all!

It has already taught us a few lessons, and the one I have chosen to stress in this talk is the following. We shall do a much better programming job, provided that we approach the task with a full appreciation of its tremendous difficulty, provided that we stick to modest and elegant programming languages, provided that we respect the intrinsic limitations of the human mind and approach the task as Very Humble Programmers.

On Making and Working Towards Big Things: on innovation

Wondering why we’re living in an age of ever increasing decreased expectations? You are not alone. Author Neal Stephenson wrote a thought provoking must read for World Policy Institute titled, “Innovation Starvation”:

The imperative to develop new technologies and implement them on a heroic scale no longer seems like the childish preoccupation of a few nerds with slide rules. It’s the only way for the human race to escape from its current predicaments. Too bad we’ve forgotten how to do it.