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. With that in mind I started a new blog Projects The Hard Way which will feature a sequence of projects in varying levels of difficulty. I’ll see what ends up working best and how to work with early coders using this format.

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!

11 thoughts on “Early vs. Beginning Coders

  1. “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!”

    So true. I’ve been slowly learning programming; this is attempt two or three. Not like I discretely tried and failed/gave up, but just couldn’t find a tutorial that fit me. I grew up editing autoexec.bat files for games in win95/dos (not well either) and edited some games written in BASIC (literally just changing variables). So that was my first exposure to programming. Then I started using Linux when Ubuntu first became a thing. This is where I was introduced to the CLI, and the concept of a file object– I thought that was sooooo cool! Still do. I don’t really know any CLI scripting, but I became exposed to it. I guess that Linux CLI was my first exposure to a syntactic structure. Anyway…if I hadn’t had those and MAN pages to decypher (because archlinux w/o GUI!)…I don’t think I’d know anything.

    All that kinda ruined any beginner programming books for me at the time..2006? Like you said– kids or a total idiot. So I tried some more intermediate books…nope, too advanced, or dry, or effing errors…but mostly dry.

    Finally fast forward to now: having gone through all that (and being of the mind-set that I need to stop fscking around and get a career!), I found your book on Python…which I decided not to do. I started Learn C The Hard Way, which I gave up on (because of C, not you…I still plan on doing/buying the book!). While doing LcTHW, and getting pissed at C, I’d take breaks by doing Eloquent JavaScript…JavaScript reminded me that I wanted to check-out Lisp. I picked-up Touretzky’s book on Common Lisp..which was finally a good fit. It starts off simple (like you don’t even need a computer for the first 2-3 chapters), syntax is a synch, and it’s a cool language if you have a concept oriented mind (yay sexprs!).

    Well that was kind of a tangent.

    TL;DR What really happened was I read so many intros and chapters 2 – 3 of so many beginner programming books, that what I really learned from them was what I *didn’t* need in a book teaching programming. Probably I’m a boundary case (phrase of the day.)

    Liked by 8 people

  2. A blog post I’ll be sharing. When talking to employers and academics about the efforts of entering people into ‘coding’ it does astonish me at the assumptions of a how far advanced many think the “starting point” is. The “what’s a pipe character” is a great example.

    Like

  3. Interesting post and a good read.

    By your definition, I’m past the early stage, but I’m still not sure where that classifies me. Full disclosure: I’ve taken courses in VB, C, Assembly, C++, and Java. I’ve also done a small amount of work in bash and tcl, and I know SQL fairly well. Unfortunately, the bulk of my professional experience is with a proprietary language used by one specific vendor in the healthcare world (basically a mish mosh of C and SQL called CCL).

    After a decade of experience, I’ve realized that I enjoy coding more than anything else I do (I should never have listened to my college adviser that recommended a change from CS to IS), but I’m handicapped by having so much experience in this proprietary language. There are a ton of concepts I know well that are in every language (variables types, looping, data structures, etc.), and I think I have an aptitude for learning new languages. That being said, every job I look at requires X number of years of production level experience in language XYZ that I simply do not have. At this point in my life, it would be financially difficult to take an entry level salary, but I wouldn’t expect to get hired in the 100K+ range either. So what is the solution for someone like me that is kind of intermediate level but not really? One idea is to put together a bunch of sample projects and develop a github portfolio, but I don’t want to spend the time and effort that would involve if hiring managers are going to just move onto the next resume when they see a lack of production experience.

    I know – not exactly the topic of your post, but I thought I’d ask.

    Like

    • I think at your level I wouldn’t worry about labels. Trying to label or categorize yourself will end up limiting where you go and what you learn. I actually always learn a “Plan B” language in my spare time whenever I have a job. The Plan B Language (PBL) has to be something totally different and outside my comfort zone, but potentially useful and on the rise. The reason is jobs in programming change whenever the programming languages change in popularity. If you fall in love with one language and that language suddenly is not the king then you are out of a job. A PBL keeps your skills sharp, and in the event of a change to language popularity you can switch to that language or at least any similar language. Right now my PBL is F#, mostly because it’s fun, but also I may build something with it soon.

      Liked by 1 person

  4. This is gold, Zed! I will comment on this using my twitter account once I am not on our corporate proxy that blocks twitter.

    Liked by 1 person

  5. I love this distinction, and I think your labels make sense. I had the experience of learning what it’s like to actually teach total beginners when I was living in Swaziland, South Africa for a year. I taught a computers course to people who had never even *seen* a computer, much less touched one. They had to learn how to move the mouse, how to type, what a folder was, what an “application” was, etc.

    A few of my students excelled at general computer usage and wanted to learn how to program. We really had to begin from first principles. I used Chris Pine’s “Learn to Program” plus supplemented with a lot of my own “problems,” but I like your approach of teaching the basics in multiple languages. That really drives home the distinction between abstract concept and syntax.

    Good stuff.

    Liked by 2 people

Comments are closed.