The murmur of the snarkmatrix…

August § The Common Test / 2016-02-16 21:04:46
Robin § Unforgotten / 2016-01-08 21:19:16
MsFitNZ § Towards A Theory of Secondary Literacy / 2015-11-03 21:23:21
Jon Schultz § Bless the toolmakers / 2015-05-04 18:39:56
Jon Schultz § Bless the toolmakers / 2015-05-04 16:32:50
Matt § A leaky rocketship / 2014-11-05 01:49:12
Greg Linch § A leaky rocketship / 2014-11-04 18:05:52
Robin § A leaky rocketship / 2014-11-04 05:11:02
P. Renaud § A leaky rocketship / 2014-11-04 04:13:09
Jay H § Matching cuts / 2014-10-02 02:41:13

'Having Ideas Is Not Very Parallelizable'
 / 

It’s a powerful observation if you can make your way through the context (which is computer programming):

In fact, if you look at the way software gets written in most organizations, it’s almost as if they were deliberately trying to do things wrong. In a sense, they are. One of the defining qualities of organizations since there have been such a thing is to treat individuals as interchangeable parts. This works well for more parallelizable tasks, like fighting wars. For most of history a well-drilled army of professional soldiers could be counted on to beat an army of individual warriors, no matter how valorous. But having ideas is not very parallelizable. And that’s what programs are: ideas.

August 24, 2007 / Uncategorized

4 comments

At the same time, there’s a problem with any intellectual endeavour that’s outside the control of a single person, which is that it needs to be put into production.

One parallel (ha!) that came to mind is the movie industry: are films a work of art, or an industrial product? Of course, they’re a little bit of both, and software is too.

You could read this as a manifesto of software auteurism. When cinematic auteurism appeared, championed by director/critics like Godard and Truffaut, it helped to shift some of the attention away from a film’s producers and its stars toward the directors, and that shifted some of the production responsibility in that direction, too. Sometimes everything needs to get shaken up a little bit.

Two thoughts:

1. Paul Graham’s essay–complete with this notion that programs are ideas and best left as individual creations–could be read, oddly enough, as a damning attack on the opensource movement. Take this passage:

Don’t have multiple people editing the same piece of code. You never understand other people’s code as well as your own. No matter how thoroughly you’ve read it, you’ve only read it, not written it. So if a piece of code is written by multiple authors, none of them understand it as well as a single author would.”

But I suppose there is nothing new in the insight that design can trump openness and cooperation.

2. Graham draws comparisons to the work of mathematicians, but there is a much older and more diverse tradition that he is really paying homage to: the trades. Graham is calling for a return to the making (as opposed to manufacturing) tradition of pre-industry/early-industry. Graham wants the work of programmers to be the work of an individual, who can work in a unique rhythm (usually long spurts), and not be bogged down by management’s scheduled distractions. That sounds like the perfect description of either a 17th century peasant/artisan or a college student. (Or maybe Robin)

I think you’ve hit the nail on the head, Dan. There’s been a real resurgence in the idea of ‘craft’ around code and other web-stuff. I would never have thought to call it making vs. manufacturing, though — I love those words, and that distinction.

That PDF looks terrific!

And Tim, you’re right re: software auteurism. (Not to be confused with autism. Although one wonders…) I’ve been meaning to write something about the web and the relatively rare affordance it gives for Total Authorship… but… yeah we’ll see.

The making/manufacturing distinction is an old one. See Charles Babbage’s On the Economy of Machinery and Manufactures, chapter 13.

The chapter “On the Mental Division of Labor” is also worth a glance.

The snarkmatrix awaits you

Below, you can use basic HTML tags and/or Markdown syntax.