I was struck again several times just this weekend by this idea that I've been having regarding levels of knowledge and learning. And when things come in batches like this, it makes sense to pay attention and think about them.

The basic example of the situation is this: When you first learn about a subject, you are by definition a novice. Depending on the topic area, there may be many books on the subject geared toward your knowledge level. As you become more adept though, the number of books on the topic that are worthwhile to you dwindle.

We were looking at books on home decorating over the weekend. There simply are no basic books. The books that exist all assume some fundamental level of interior design skill that we simply don't possess.

As an aside, these interior design books are also particularly annoying in that there is no practical guide -- all of the photos in the books are of well-designed houses that are configured nothing like the box of bricks the typical family lives in. I'm sure I'll eventually discover a book that shows how to decorate a typical American cookie-cutter home, and I'll be pleased when I do, but until then all I have to look at are books where every ceiling is vaulted, every entryway is parquet'ed, and all the woodwork is antique.

Programming is certainly this way. When I started to learn how to code, I was typing code from magazine listings and the scant few books that talked about programming. These were very basic. I don't know of any analogue to those publications these days. Where are the true beginner materials?

One of the fundamental things I discovered about people learning to program is that everyone starts at a different place. When you get into programming, you don't all get in on the "ground floor". The building certainly isn't a single high-rise, but a weaving Escher-esque nightmare of staircases that converge at odd angles, sometimes upside-down. As a result, many people are missing certain things that I find fundamental to know. For example, being able to "read" code - where you sort of "execute" the code in your head to imagine what it will do - is a fundamental skill that very few of the people I know practice explicitly.

But assuming you even obtain a basic layer of knowledge, everyone's ground floor is different. And like a concept well-described in Vernor Vinge's "A Deepness in the Sky", as the automation of a technology increases, the layers of abstraction increase to the point that the truly basic underlying systems are understood by hardly anyone. Take for example the workings of the web. While practically anyone with a keyboard these days can produce a web site using software they stumble upon while browsing, just because you can do so does not mean you have the knowledge of how the browser works, or how your TCP/IP stack requests the information it gets, or how the routers between you and the internet move that traffic, or how your computer is able to turn the code it receives into something readable, or how the jpeg images are decoded for display, or how the code that displays the images received from those vast distances is dissembled into bits of assembler instructions that cause the microscopic components of that machine to execute anything. What few software engineers know anything about the low level functionality of a floating point processing unit, for example?

Yet, you can pick up a magazine at any bookstore that will explain how to build whole, useful web sites.

Is it useful for a web designer to know anything about assembler? Probably not. And I don't posit that the art of compiler design is lost (yet) for all of them fleeing to build a new Facebook. But there is an interesting disparity of knowledge there. And my point here is that there's no real connection to be made between.

Sure, you can pick up the knowledge of how to build web sites, but if you wanted to learn the next thing - maybe it's how to build a browser - you'd be hard pressed to find a manual on that. And I think that's the case with a great many disciplines. After you've learned the basics, and maybe a level on top of that, things tend to either get specialized to the point of requiring knowledge that you would have to have obtained externally, or simply don't exist.

I wonder if there's a place for these in-between classes. A class you could take to learn how to get from novice to advanced specialist that is more general than jumping directly to the specialist class. Because I think that the way we learn these days is different than most formal instruction. With formal instruction, you have a path from knowing nothing to specializing. These days, you start out as a specialist, not needing to know more basics or advanced techniques to survive. But a class or some books that I don't think exist now to fill in the gaps to allow people to move laterally into related disciplines seems like something that could be beneficial.

Berta and I were talking a bit when she got home from work today about how it would be neat to team up with a designer and spew out great new web sites. I mentioned to her how with many of the designers I've worked with, you get about 5 designs in, and then the designs start to look the same, or there's a style between them that's very similar, then making the sites look very similar themselves.

To me, that was a clue to switch designers every few projects, just to keep things fresh. To her, it was a clue that a developer could clutch a design theme and run with it and get away with doing design too, an insight I hadn't had before. And this all got me thinking about how many times I've urged web designer friends to produce some kind of post or video or course that explains the basics of design to developers. But nobody has stepped up.

So it's a new idea, and writing about anything instead of doing it is the kiss of death to any good idea, but I've been thinking about publishing a self-taught design blog, from the perspective of a developer, learning as I go. I would expect not to proclaim any expertise at it as I learn, but I'd have certain goals so that by the end I'd hope to 1) have a rudimentary process for producing my own web designs and 2) be able to give adequate instruction to other developers to get to the same point.

Have you ever seen the movie Julie and Julia? Julie is a blogger who, through some changes in her life, comes to learn to cook (that's not exactly right, but good enough for my purposes here) by preparing so many of Julia Childs' recipes every week, with the intent of completing the whole cookbook within a year. And she blogs about her experience with it all? Well, that's the kind of thing I'd like to commit to: Some n number of posts every week for a year until I meet my goal.

I would likely not do it here, but on RedAlt, which seems a better venue for the topic. I could have guest authors, or interviews with people who do design for a living and ask them for specific insight. This could finally get my designer friends to get off their butts and help me produce this thing that I feel really needs to be published. And discussion in the comments could be very worthwhile, both with people who are designers with advice for doing the work and with developers who want to learn along with me.

Depending how it goes, it could even become profitable somehow. Sure, there's no guarantee, and that's not really the point. The profit is in the learning. But a little extra cash to make up for the time and hosting would be nice.

Is this crazy? Worthwhile? Would you read it?

On a mailing list to which I still subscribe (registered users only), a message was recently posted about pre-testing programming aptitude. Being a programmer myself, these topics always amuse me, and will no doubt be the focus of at least 10 minutes of our next work lunch.

In particular, the ensuing discussion focused on whether it's easy or difficult to teach programming. The focus was perhaps more concerned with whether programming skills are important at all in comparison to problem solving skills, and the difficulty of teaching those. Being that one of the better sessions I attended at BarCamp Philly revolved around the curriculum required for community college computer classes to produce employable programmers, and the difficulty of finding programmers in the marketplace with any skill, I have much interest in this topic.

But rather than discuss any of that, I have a good story...

I may have mentioned in one of the prior ten years of blog postings that I was a gifted student in school. "Gifted" in the sense that I had special classes once a week, and generally did a lot of pushing on the doors labeled "pull".

In the upper grades, our "assignments" in the gifted program involved visiting elementary school gifted classes and imparting some of our venerated teen wisdom. Our victims: The second grade gifted class of East Ward Elementary School.

We had quite a few good field trips with the younglings, including one to the zoo, which is a completely different experience when you're a teen in charge of a group of 2nd graders that may be collectively smarter than you. But this post, "Peanut Butter Programming", has to do with a particular unit with those kids on programming.

The 2nd grade DEEP (Downingtown Educational Enrichment Program - the gifted student program) teacher was one I knew from when I went through the program. She had prepared her students for a programming lesson by asking them to form two groups and collaborate on written instructions for creating the universal 2nd-grader food -- the Peanut Butter and Jelly Sandwich.

Not really being told exactly what they were in for, we Seniors stepped in. In was just two of us, myself and one of my better friends, Derek. We were selected from the senior gifted class to do this assignment because of our experience with computers.

At a desk in front of the class we were presented with the components for assembling the PB&J sandwich; a butter knife, several slices of bread, and a jar each of peanut butter and of jelly. I went first.

"Take the jelly," read the first kid from their list of collaborated instructions. I took the jar of jelly.

"Put jelly on the knife." Hmm. Someone left the lid on my jar. I attempted to put the jelly on the knife. The jar just wouldn't stay.

The class shouted a chorus of, "No! No!" So instead, I attempted to force the knife through the lid of the jar. Once again, "No! No!"

The unwrapping of the bread also became an issue. The teacher took this "three strikes" opportunity to tell the students that they failed to create a list of explicit instructions that would result in the creation of the simplest of 2nd grade foodstuffs. She encouraged the second group to take a few moments to revise their script, and then Derek stepped forward.

There's something to be said about friends who are this cool. I think I find myself with a lot of almost highbrow intellectuals these days, people who have good thinking skills or recall, but have no creative synthesis. Derek was obviously gifted, and had no creative roadblocks.

The lesson ended with Derek shoving a surprisingly complete peanut butter and jelly sandwich in his pants pocket and running out of the classroom. "Take the sandwich" was the next to last command before eating. Had they simply optimized their code, Derek wouldn't have had peanut butter in his pants for the rest of the day.

What is the point of all this, anyway?

I agree that there is a distinct separation between learning to write code and learning to solve problems using code. And while I think problem solving is important, teaching it's application - whether it's by writing C++ or listing step by step PB&J recipes - is perhaps equally so.

Remaining for future fireside chats: Why I think you can't teach a programmer to be "great", how we might do better to succeed at striving for great programmers, and the magic of the elementary DEEP classroom, which is home to posters of feudal castes, diagrams of unimpeachable problem-solving processes, and a chart by the door detailing the procedure to follow in case of a tornado, even though tornadoes don't frequent our region.