On Hackers and Painters and Education and Bonding and Risk and Nanny Languages

You may remember that in a recent post of mine, I linked to an essay by Paul Graham on What Business Can Learn from Open Source. Fascinating essay. I hadn’t read much of Paul since his LISP days, just the occasional wander over to his site. My bad.

Reading that essay made me go out and buy his latest book, Hackers and Painters. It’s not often that you get a book endorsed by people as diverse as David Weinberger, Chris Anderson, Larry Lessig, Andy Hertzfeld and Commander Taco. I had to buy it and read it.

I’m still reading it. Very. Very. Slowly. I like it that much. [An aside: Endorsements on book covers may be old-world ways of acquiring collaboratively-filtered ratings, but they do work. For example, I would read any book endorsed by John Seely Brown. Even a telephone directory.]

Why do I like Hackers and Painters that much? Here are a few extracts from the book (all in italics and judged to be “fair use”, annotated with some comments from me:

Paul on hackers:

What hackers and painters have in common is that they’re both makers. Along with composers, architects and writers, what hackers and painters are trying to do is make good things. They’re not doing research per se, though if in the course of trying to make good things they discover some new technique, so much the better.

…………………

Sometimes what the hackers do is called “software engineering”, but this term is just as misleading. Good software designers are no more engineers than architects are. The border between architecture and engineering is not sharply defined, but it’s there. It falls between what and how: architects decide what to do, and engineers figure out how to do it.

What and how should not be kept too separate. You’re asking for trouble if you try to decide what to do without understanding how to do it.

My comments:

This is important. Too many firms, too many IT departments in firms, think everything is about process. Past-predicts-the-future assembly line. They get egged on by efficiency experts masquerading as consultants (or is it the other way around, and who cares anyway).

Software development is first and foremost a creative process, trying to find unique solutions to a firm’s unique problems. Those that aren’t unique problems can and will be solved by the opensource market, so contribute and participate, but stick to your knitting. Your job as an IT professional within a firm is to find those firm-unique solutions to firm-unique problems.

Take the creativity out of an IT department at your peril. Soon you will pay firm-unique prices to implement solutions to other people’s problems, not yours. Treasure your hackers. They’re like the nerds at school, more interested in being smart than being popular. Use kid gloves with them, there is a war for talent out there. And Generation M will make it even harder.

You want D-I-Y IT, treasure your hackers, they’re the only ones who care enough. Who stay up nights trying to figure out the best way to solve a problem. Who find those solutions that are appropriate to your firm.

You want Because Of IT, treasure your hackers. They are Because Of material.

Treasure your hackers.

Paul on smart kids and popularity and education:

Why are smart kids so consistently unpopular? The answer, I think, is that they don’t want to be popular…… [they wanted] to be smart. Not simply to do well in school, though that counted for something, but to design beautiful rockets, or to write well, or to understand how to program computers. In general, to make great things.

………………………….

The main reason nerds are unpopular is that they have other things to think about. Their attention is drawn to books or the natural world, not fashions and parties. They’re like someone trying to play soccer while balancing a glass of water on his head.

……………………………..

… I think the main reason other kids persecute nerds is that it’s part of the mechanism of popularity. Popularity is only partially about individual attractiveness. It’s much more about alliances.

…………………………………………

What bothers me is not that the kids are kept in prisons, but that (a) they aren’t told about it and (b) the prisons are run mostly by the inmates…… a world ruled by a caste of giants who run after a brown oblong ball….

My comments:

Again, some very telling insights. But Graham is not despondent, he recognises that we as adults, parents and teachers, can do something about it. The article on Why Nerds are Unpopular set off a whole pile of Searlsian snowballs around me. Why children from some cultures do so well at school, their will and wish to be smart rather than to conform to popularity. Why some children have the emotional intelligence to do this and others don’t. And so on and so forth.

What gets me excited is how much impact social software can have on this arena, as teachers and parents help children bond and collaborate, help children want to do beautiful and creative things, rather than just waste their lives wanting to be popular, and becoming miserable in the attempt.

Good teachers (and there are many) have had an uphill fight for many years, trying to get the talent they can see to become something, and watching that talent atrophy before their very eyes because of peer pressure and popularity contests and what Graham refers to as “court hierarchies”. But now we have tools to help the good teachers, tools that can help children bond and learn without the fear of the popularity contests.

This is worth a separate post sometime soon.

Paul on Risk and on Languages:

When I grew up, it felt as if there was nowhere to go, and nothing to do. This was no accident. Suburbs are deliberately designed to exclude the outside world, because it contains things that could endanger children.

………………………………………….

People sometimes send me mail saying “How can you say that Java won’t turn out to be a successful language? It’s already a successful language”…..When I say Java won’t turn out to be a successful language, I mean something more specific: that Java will turn out to be an evolutionary dead-end, like Cobol. This is just a guess, I may be wrong. My point here is not to diss Java, but to raise the issue of evolutionary trees and get people asking, where on the tree is language x? The reason to ask this question isn’t just so that in a hundred years our ghosts can say, I told you so. It’s because staying close to the main branches is a useful heuristic for finding languages that will be good to program in now…… I have a hunch that the main branches of the evolutionary tree pass through the languages that have the smallest, cleanest cores. The more of a language you can write in itself, the better.

My comments:

I think Paul is on to something here, although I quote from different parts of his book. It is something about Nanny States and Nanny Environments and Nanny Languages.

Human beings, yes this includes children, should never be insulated from risk. Trusting is all about risk. Bonding is all about risk. Learning is all about risk. Love is all about risk. Even faith is all about risk.
We need to empower everyone to take risk and be accountable for the consequences.

You remove the risk, you remove the accountability for consequences. And the incredible value that can be gained from that vulnerability.

I am not preaching anarchy. As a parent you have responsibilities for your children, as a leader you have responsibilities for the people you lead. But. You should be letting those “under your charge” find their potential, develop themselves to that potential and then exceed that potential. To dream dreams and see visions.

You have to discharge your responsibilities with care, but I don’t think you can do this by preventing risk, you do this by connecting risk with consequences and accountability for those consequences. And allowing people to take risk commensurate with their ability, that’s where the wisdom and leadership comes in.
So children do come off bikes and burn their hands and hit their heads on rocks. And they have to be allowed to, in order to learn. There are bikes and fires and rocks at work as well, and people have to be allowed to learn about them.

The important thing is to make sure that everyone is made aware of the likely consequences, and to take responsibility for those consequences.

In Nanny Environments, when something goes wrong, people look for someone to blame. Because they know it’s not them. Because we made it so, by removing risk and accountability.

And you can have Nanny Languages as well. Languages that prevent you from doing “wrong”, whatever that wrong may be. In the benighted belief that you should be stopped from making mistakes.

More later. Go read the book.