Everybody signs up for codeacademy at some point but almost nobody finishes. It’s because they can’t get over sucking. It’s torture to suck so bad for so long. Understanding how to get them unstuck could transform how we learn to code.

I recently learned python. I’m not good at it — I still suck — but I’m a lot better. I was reflecting on how I learned it. In particular, what obstacles I had to overcome as well as how a couple of colleagues helped me. I was also reflecting on my experience teaching SQL to at least 50 people and what types of problems they encountered most.

Everyone who starts coding sucks at first. But what does it mean to suck? Basically, you suck if you can’t do anything useful with it. Why can’t you?

1. Because you don’t know the logic and the syntax. It’s not natural to you yet. Why?

2. Because you don’t have enough experience with it. Why don’t you have much experience yet?

3. Because doing anything in a language you don’t know is a slow, hard slog because of errors. Why is it slow with a lot of errors?

4. Because to learn a language (to stop sucking) means overcoming many errors until you know what you will do if you see error X. You may not know exactly what the cause is, but you’ll have a strategy to solve it, and you’ll be confident that you will be able to find a solution.

Learning a language starts at the bottom of this list (4. strategy to solve errors), then your speed improves (3), then you build up your experience (2) and then you understand the logic and syntax (1). Then you don’t suck anymore. Yay!

If all that’s true, then you can really accelerate how fast someone learns a language by focusing on (4) - helping learners fix errors faster. Everything falls into place much more easily after that.

Learning a new language is about learning how to be ok with failing many times in a row until your ratio of fail to succeed on each line of code gets above some threshold (say 50%).

In general, you’ll fail every time you try to do something new in a language, and you’ll also fail most times to do the thing you successfully did last week. But you’ll get to success faster the 2nd time, and even faster the 10th time.

It takes multiple times of seeing the same error (5-10 for me) before I "learn" something that I will remember for a week. And I probably need to encounter a particular error 30-50 times to learn it permanently.

When teaching students, the value that teachers add is that they've seen the error many times and know one or both of the following naturally:

• What is causing the error (just from looking at the code)

• How to debug it (if it’s not an obvious problem or they don’t know the underlying data structure)

Debugging is a learnable skill. Essentially, the best strategy is to narrow the problem down to its absolute essence. To do this:

• Creativity is needed

• Hypotheses are needed

• Experience helps, but is not necessary

Take the absolute simplest python task:

var = 1
print "var = " + var

Gives this error:

TypeError                   Traceback (most recent call last)
<ipython-input-9-63b6d99501e5> in <module>()
      1 var = 1
----> 2 print "var = " + var

TypeError: cannot concatenate 'str' and 'int' objects

If you’re not familiar with python (or programming generally as many learners aren’t), you don’t know:

• What exactly the problem is

• What ‘str’ and ‘int’ stand for and maybe the word concatenate. What TypeError, Traceback () or the rest of the error message is saying.

• And most importantly, you don’t know: what to do next to solve it

  If you had a good teacher sitting beside you, they would help you understand all of those things. But you don’t.

  So, what if you could automate what a good teacher would do. Well, perhaps you can.

  Each learner has made this error many times (i.e. 30-50 times to get to the point where it’s hard-wired into their brain), and collectively, every single python user has made this exact error many times. We can leverage that. How?

  By figuring out what the likely solution is. How do we know what the solution is? It’ll follow this pattern:

  • Try X → fail

  • Modify X slightly → succeed

  So, to automate this learning (using the example). When you type this:

  var = 1
  print "var = " + var
  

  And get the error above, we can search for examples in your code history where:

  • You got that exact error

  • Then immediately after, with very similar code (i.e. fuzzy matching or diff distance) you didn’t get an error. The change you made before is very likely to be the solution to this new problem.

  More concretely, it would quickly find that this example on the right which syntactically identical to the a couple of examples that didn’t give an error:

  

  And with those two examples - from your own coding history if possible - the learner will be able to debug their current issue much faster and accelerate how quickly they learn.

  Technically how it might work

  Capture every code execution along with the error codes if there are errors. For python, a library like this might be the foundation. Or this. Or this.

  When an error occurs at code execution, a browser window will open. In that window:

  1. All of your previous executions that resulted in that error are listed, ordered by how similar the code is that caused the error. Your code is highlighted first because it might flag your memory and use variables you understand.

  2. But also the closest related code patterns from other YSAC users that eventually worked are also listed

  3. Automatic, streamlined google/stack overflow/github search provides the top answers likely to help

  4. [later paid option] ask for help from a "code coach" - offline or real-time via chat. A mechanism to quickly provide everything the coach would need to be able help the student.

  For (1) and (2) it’s basically a matching algorithm to find similar code that failed then worked. A nicely designed diff interface makes it easy to figure out what subtle changes made it work.

  For (4) cost is fixed for the student and usually $2-20. Coaches would bid on it and receive the code. If the question isn't clear, nobody will take it. Coaches would provide back:

  • Code that doesn't error (including an automatically created diff)

  • Explanation of the error

  • If the code still doesn't work 1-2 retries would be possible as well as 1:1 chat to quickly ask clarifying questions

  In principle, this sort of structure could work for any programming language and maybe even natural languages (English, Spanish)

  Benefits

  If I think about my own learning pace, I’d estimate that having this would have helped me to learn python at least 2-3x faster. That’s an enormous gain.

  The gains from this will be highest for those with the least experience. And it could make the difference for many between getting over the initial learning “hump” and giving up. That’s huge.

  Updates

  It links well with the ideas in this blog post: How to help a student get unstuck.

  --

  I have no intention of pursuing this right now but I’d be delighted to hear if someone is working on something like it. Let me know at mcclelland (dot) jeff at gmail.com

  Go back to the main page.

  Photo by Chris Ried on Unsplash