Quick review: "Dreaming in Code" and why isn't Programming taught like Creative Writing?

I finally finished "Dreaming in Code" by Scott Rosenberg last week. I absolutely loved it! (BTW, it was brought to my attention that I seem to "absolutely love" everything I review/watch. The person who pointed this out believes its a personality trait/problem.)

The book chronicles the development of "Chandler", an open-source Personal Information Manager whose development was sponsored by Mitch Kapor. However what makes the book so great its use of this story as a way to frame explanations and discussions about the development, design and process of software. While reading it, I found myself smiling and nodding in agreement with so many issues and situations I recognized from work, and from school; issues fundamental to writing software, issues unavoidable in managing large software projects and frankly so many things I thought we did so well at work (when I say "we" here I really mean my managers.:))

I also ended up learning a lot: about the history of programming, the colorful characters involved, and some fascinating opinions/complaints that different people have about the future of software development.

A discussion that stayed with me for a while though was the argument that programming should be taught like creative writing rather than like engineering. Having experienced a bit of both I can see the argument, though I can see the pitfalls as well.

From the book:

"...Is programming a kind of creative writing? The notion seems outlandish at first blush. Any discipline that involves complex mathematics and symbolic logic does not seem to share the same cubbyhole with poetry and self-expression. Yet the programming field could learn much from the writing world, argues Richard Gabriel, a veteran of Lisp and object-oriented programming who is now a Distinguished Engineer at Sun. 'My view is that we should train developers the way we train creative people like poets and artists. People may say, "Wall, that sounds really nuts." But what do people do when they're being trained, for example, to get a master of fine arts in poetry? They study great works of poetry. Do we do that in out software engineering disciplines? No. You don't look at the source code for great pieces of software. Or look at the architecture of great pieces of software. You don't look at their design. You don't study the lives of great software designers. So you don't study the literature of the thing you're trying to build.'"


This is essentially true. Most programmers leave school (or not) armed with very basic tools (programming languages, logic, data structures, algorithms etc.) At best they've learned some software methodologies and design patterns. I didn't believe it earlier, but chatting with some of my friends in large software shops I'm now convinced that most programmers suck.

Would they be better served by getting this form of education?

The book correctly points out that there are many reasons that this is hard:
availability of "good" code, agreement on what is "good" code, how time-consuming this is and just mustering the enthusiasm for something like this in a culture that will view this as uncool.

I'll add another one to the list: goals.

Most people that want careers as writers are driven by very different goals than people that want careers as software engineers. The amount of time they can spend, and are willing to spend, to perfect their "crafts" are very different. Still I think introducing a software practicum class of sorts (where you write code, review your peers' code and review recognized "good" code) and combining it with teaching design patterns could lead to better results. In fact, just getting it into people's heads that reading other people's code and that writing readable code is valuable might be worth it in itself.