Early vs. Beginning Coders

When I was working on Learn Python The Hard Way I was frustrated by how often I’d have to explain that the book is for a total beginner. The problem is that most of the technology world considers someone with about two programming languages under their belt a “beginner”, but learning two programming language would take you about 4-6 months. After 6 months you can’t really say someone is a beginner since, well, 6 months later is not the beginning. The beginning of something is…I mean why do I have to say this…at the beginning. Not 6 months later.

It seems pedantic but this is a constant problem in the technology education world. When you look at the categories for technology book publishers they only have categories for “beginner” that fit the model of a person who’s not really a beginner. My book actually didn’t fit into many publisher’s categories since it was targeted at an audience that was before this level. This showed a completely ignored group of people, and it’s a very good sign that most technologists simply have no concept that there are non-programmers who want to learn programming.

To me this inability to visualize a person who is a total beginner is a symptom of most programmers being terrible at teaching programming. They frequently have bizarre ideas about teaching programming because they can’t visualize a person who knows absolutely nothing. My favorite is how they think you should teach programming without teaching “coding”, as if that’s how they learned it. They’ll have this imagined idea that they learned programming in their first discrete mathematics course, when really they were probably typing the code out of a book when they were 11 and simply don’t consider that where they learned to code. Or, they didn’t really learn programming in that class and only actually learned it when they sat down and went through a book that taught them code. Their arrogance simply makes them think they did, but I don’t know anyone who took an abstract “no coding” class and then went and wrote Java or Lisp without going through at least one book teaching how to code.

I have no idea why these people have such a hard time visualizing someone with zero knowledge, but I think a simple change to the nomenclature of software developers would help to at least talk about it.

The Beginning Is At the Beginning

What I propose is we have beginning coders and early coders. I got this idea from a painting teacher who kept referring to students who had never painted as “beginners”, but those who had painted for about one class as “early”. The reasoning is that you need a way to differentiate people who don’t know a damn thing vs. people who know the basics but just simply suck at them. Teaching a beginner is very different from teaching someone who’s already been doing it for a bit and just needs more training.

For example, a beginning coder doesn’t know how to type the | (pipe) character. They don’t even know it’s called a “pipe”. I’m not joking about this. Professionals actually don’t believe me when I tell them this, but it’s true. Beginners have zero experience so simple things like making a text file, opening terminal, and even the idea that you can type words at a computer and it will do stuff, are simply unknown to them. To teach a beginner effectively requires this level of information slowly fed to them in reasonable chunks.

The best analogy I have for this comes from either music or martial arts. In those disciplines you have a set of things that beginners need to get through repetition before they can start the process of actually learning. In music this is simple things like names of notes, ear training, scales, where notes are, and harmony training. In martial arts this is things like building strength, flexibility, how to stand, the names of techniques, and blocking. Without this initial basic repetitive training to get these core skills deeply ingrained the beginner will simply flounder trying to learn at the early stage and have a difficult time progressing to deeper understanding.

My current method for training up beginners is to make them learn the basics of 4 programming languages. I’m not sure why 4 seems to be the magic number, but after they’ve gone through 4 programming books and learned to make tiny little programs plus all the syntax, they seem to have a firm grasp of the basics. This phase is all about learning concrete simple things, but also understanding the idea that the concrete things are just standing in for abstract concepts. In one language || (two pipe symbols) might mean “or” and another language will use the actual word “or” but this is the same concept and the symbol doesn’t matter. After their fourth language they get this and can then move on to being an early coder.

Early Is After The Beginning

An early programmer is different from a beginner because they have the basic skills understood, but have a hard time applying them to problems. The early coder’s next challenge is problem solving, which is a much more abstract skill that takes longer to master. A beginner’s hurdle is training their brain to grasp the concrete problem of using syntax to create computation and then understanding that the syntax is just a proxy for how computation works. The early coder is past this, but now has to work up the abstraction stack to convert ideas and fuzzy descriptions into concrete solutions. It’s this traversing of abstraction and concrete implementation that I believe takes someone past the early stage and into the junior programmer world.

The best analogy for this would be with creative writing. First, a student has to spend time learning the alphabet, then words, reading, writing, and other concrete things. Even before that they have to learn to comprehend their native language(s) or else it’s difficult to teach them reading and writing. After they’ve learned this concrete task of reading and writing, through lots of mechanical repetition, they move on to the task of conceptual writing. They’re given problems of writing stories or essays and then figuring out how to express these ideas in concrete words. I’m not quite sure what takes someone from early to junior other than just attempting lots of projects with guidance. Similar to writing, painting, and wood carving, I think given a lot of projects to complete and then being critiqued on the results is probably the best way to build them up.

Significance

My idea isn’t new of course, but now that I have a word for who I’m trying to teach, next I can focus exactly on that person. By saying, “This is for early coders,” I’m able to craft exercises that will work to build their skill level up and take them out of the early stages and able to create things. I’m thinking that it won’t matter what kinds of projects they do, just that they do a bunch of them.

My only question is how many projects ends up being the breaking point for most people? Is it 10, 20? How much variation is there between them? Or, is it more a question of time and not quantity of effort?

Either way, I’ll be hammering this divide between beginner and early so that we can properly place educational efforts and materials where they belong. Now if I can only get the few people writing books for beginners to stop assuming every beginner is a little kid or a total idiot I’d be set!

More from Zed A. Shaw