Understanding Comics…and Everything Else

I read this book called Understanding Comics by Scott McCloud. It’s actually an interesting read in it’s own right–the Ancient Egyptians and Mayans had comics that follow much of the modern form. Anyway, there’s a part where he talks about the development of the artist and how that relates to the final product. It reminded me immediately of programming…and possibly everything else that requires skill. Bad programs suffer the same categories of deficiencies as bad comics.

He describes all artistic work as having 6 layers:

  • Idea/Purpose
  • Form
  • Idiom
  • Structure
  • Craft
  • Surface

He then goes through people who stop progressing at a certain level.

6 — Surface

This would be someone who starts trying to draw the comics they read. They imitate what they see. When they show their work to someone higher up on the scale, they would be told they need to learn anatomy and about vanishing points.

In the programming world, these are the cut-and-paste programmers.

5 — Craft

These are people who learn how to use their tools well. They understand their craft. These people make great assistants, but aren’t able to weave a story together.

I think is where most programmers are. An education has given them tools and data structures. For any sufficiently small thing, they can go off and come back with a finished, working, good product. They can’t design a complex system though.

4 — Structure

These people can understand the whole picture. They can create a story for their comic and get all the timing and flow and progression together.

I think this is where most good programmers and “architects” are. They can design a complicated systems. The know what patterns and libraries and tools are and they can put them together in the right way. I think all maintenance programmers have to be in this category in order to function well. I think these people can actually debug without a debugger — they can look at the behaviour and infer an underlying problem.

3 — Idiom

These people are looking for an identity. They are trying to create a new style that uniquely represents them.

I think many of the leaders of OSS are here. These people create new styles; I think new OO patterns would fall in this category. New ways of doing things, such as Duff’s device. They look at problems and create techniques to solve them.

According to McCloud, when people in this category ask “why am I doing this?” they get into category 1 and 2.

2 — Form

People in form want to see what the medium is capable of doing. They create something experimental to see what it’s like. To see it’s effect on readers.

I think a lot of PL and DB developers fall in here; they wanted to see what lambdas/no primary keys/monads would have on the way they wrote programs.

When form leads design, according to McCloud, there is a tendency for the work to be “seedless”. There’s no point in it. That explains a lot of programming languages. They are experiments to see what the medium can do and they don’t gain traction because there isn’t some idea to latch on to. That’s not to say they are fruitless. All of those wacky PLs in the 80s have concepts that started to filter into mainstream languages.

1 — Idea/Purpose

When you have an idea, then the art becomes a tool for expressing it. I think there’s almost no software in this category and almost no programmers here. This is where we need to focus to make great code. To have fundamental ideas that we can latch onto to drive the development of everything else. To create a purpose for a piece of software that can be relentlessly pursued in a way that every other decision is obviously in service of it.


There is a tendency, according to McCloud, for masterful people to neglect the surface. They spend less time with the polish because the are spending all of their energy on the core. I think we see that a lot in programming: Unix and LISP being two prime examples. In both cases, people were experimenting with idioms and forms and the surface is terrible.

I think there are many fields that follow these categories and it’s useful to understand an communicate what people are capable. It’s not meant to be disparaging either. Achieving craft or structure is a worth-while goal and we have to make sure that programmers in that category are recognised for their accomplishments.

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.