Predictors of student failure and success in learning to code

I’ve mentored students through Bloc—mostly with no prior experience—to teach them Ruby on Rails and helped them develop and deploy custom web applications over the past year.

If you want to learn how to code—that may be the single best investment you can make right now in 2013—you should apply to Bloc. If you’re just testing the waters and you’re not really sure whether it’s for you, check out something like Codecademy.

Here are some predictors of failure:

1. Having other major life commitments. A job or a significant other can potentially act as distractions or derail you. Family and spouse emergencies have caused dropouts in the past. Having a job and/or spouse are fine as long as they’re fully supportive of the effort and understand the time and commitment required. Some types of jobs will drain you mentally, making it difficult to focus. Read Your Brain at Work to understand the neurology of working and learning.
2. Not booking office hours or meeting with your mentor several times each week. Whenever I see a student who didn’t attend office hours for a full week, they’re depressed and stressed out. They were stuck inside their own head and they start to believe that they’re not cut out for this stuff. I don’t understand the thinking here. Maybe it’s a pride thing? “My mentor will be impressed if I don’t use up his time, I can figure this out on my own.” Actually, I worry when a student doesn’t show up to office hours. I think they’re too afraid to ask for help, and that’s a bad sign for a student. There’s a similar correlation with Y Combinator: not showing up to office hours once per week is a bad sign. Startups that fail go into hiding somewhere in a dark corner away from the partners and they slowly die in isolation.
3. Not being comfortable with being uncomfortable. Learning to code is not easy, especially under Bloc’s intense schedule. I tend to tell my students: “Confusion is just the feeling the precedes understanding.” I even made a poster.
4. Being judgmental. You’re like an infant who is learning to walk. Unfortunately, you’re disadvantaged because you have a goal of getting a job or starting a company. This is a good and bad thing: it’s good because you’re enrolled in Bloc, but it’s bad because it can derail you. You’re at risk of constantly second-guessing yourself because you’re not at your “destination.” It will be very tempting—at every stage along the process—to judge yourself. Infants don’t think “I want to run, and I can’t even stand on my own two legs” anymore than a seed in the ground thinks “I want to sprout and become an enormous tree.” Infants will just keep trying without any emotion or judgment involved in the process. There are no deadlines, there’s just simple iteration. Read The Practicing Mind to learn how to maintain a Beginner’s Mind and remove any judgment. They’re simple concepts, but even discipline and focus (which both involve removing any judgment against yourself) have to be practiced and this book helps with that.
5. Falling behind the suggested curriculum timeline. The problem isn’t falling behind one week—it’s what happens when you’re building your final project and you only have one week instead of three. I think there’s also a compounding demoralizing effect: the farther behind you get, the more you stress out about being behind.
6. Being easily distracted. In the same way that Y Combinator tells founders that Y Combinator is the perfect social excuse to be antisocial, Bloc works the same. You’re taking classes at Bloc, and we have tight deadlines. Tell your friends you can’t go out because your Bloc instructor told you that you couldn’t, that way your friends don’t criticize you, but they direct that towards us.
7. Not having a method for decompressing. It varies for everyone, but generally having a gym membership is the best option. Swear, walk, take naps, do yoga, lift weights, practice Rubber Duck debugging, etc.
8. Not putting in the minimum 25 hours per week required of the program. If a student is having trouble, this is my first suspicion: they’re not putting in the minimum amount of time. If they don’t understand something, they either haven’t practiced it enough, didn’t seek out alternative explanations, or didn’t book office hours to ask for help. All of those are part of the weekly time commitment and you can’t cut corners.
9. Getting stuck early on and not using Google before asking your mentor. The rule of thumb I tell students is to struggle for 30 minutes before you ask for help from a mentor. The reason is you want to develop a routine of solving your own problems, and going to Google something should be a reflex when you see an error that you don’t understand. You should also never struggle to the point where you waste time—and more than 30 minutes is both wasting time and causing unnecessary stress. You will have problems in your career that take 4 hours to solve and you just forgot to restart the server so the initializer would work, but in Bloc, you’re a fragile learner and you’re more susceptible to quitting. You could ultimately solve every single one of your own problems by sheer force and determination, but you’ll burnout doing that. So don’t do that in Bloc.
10. Not using IRB while completing exercises. You will use IRB a lot when you get a job or work on your own apps. It’s a much faster feedback loop than using Bloc’s “Run” command on your tests. You can define methods inside of IRB and run loops, just like you could do in any Ruby program.
11. Writing your code specifically for the rspec tests. Your code should handle any type of input. Think of your code as battle-tested. You could pass in an array of any size to a method that creates a playlist. Don’t create one that’s a static size of 3 every time. There are some exercises where this is the exception and you want to write it specifically for the test, but in general, always think: “how do I write this method or code to work for any size array?” Or how do you make it work for most—if not all—inputs?
12. Being closed-minded. Learning to code will teach you entirely new ways of thinking, and if you’re closed off to those methods, you’ll never internalize them. Indeces in loops and arrays can be difficult for beginners, just as recursion can be difficult for people who are farther along. For me, I had this moment when I learned base numbers and logic gates in college. It changed the way I thought about counting and logic. You’ll experience moments like this where your memory gets an overwrite by new ways of thinking.
13. Not spending enough time looking at Ruby Docs. Spend time in the Array, Hash, and String classes when you’re using them.
14. Not being able to verbally talk about what the code is doing at a high level. Beginners tend to focus too much on the vocabulary, and less on “what is it that this code should actually be doing right now.” You must simultaneously understand the big picture and the granular logic.

Predictors of success:

1. Having a clear goal for learning and being confident in communicating that goal. A successful student says “I want to learn to code so I can get a job” or “I want to learn to code to build my own web apps.” A student that fails might say “I’m just testing the waters” or “I’m not sure why I’m doing this, but I think it’d be fun to try out.” (Spoiler alert: it’s very difficult, and you need a good reason to do this so you don’t give up)
2. Determination. A student that succeeds will think: quitting is simply not an option here. I’ll struggle, but I won’t consider the option of giving up. A student that fails will come up with some excuse for dropping out. I experienced something like this just before I ran a marathon. Several people thought they were doing me a favor by saying “it’s okay if you need to stop early, they have vehicles that can pick you up along the way.” I sort of responded in disbelief and said: “there isn’t even a question in my mind as to whether I’ll finish this marathon. I’ll finish it, it’s just a matter of how long it takes.” I was almost offended by people telling me how to quit on my own marathon before I even started. And they responded “you’ll do great, keep that mindset.” You should feel the same way about learning to code. I find that when I explain this list of predictors to my students, a few of them (who so far have turned out to be really good) rush me through it and they’re pretty dismissive. They just want to start, they don’t want to hear about how other people failed at this thing they’re about to do. They’re not rude, and they acknowledge it’s good to see patterns, but they’re itching to get started.
3. Consistent work ethic. A successful student will show the same effort on week 12 as she did in week 1. A student that fails will behave like an amateur runner in a marathon: they’ll sprint really hard initially and then get lapped by everyone after a few miles.
4. Resilience. A successful student will think “this PostgreSQL install isn’t the easiest thing to do, but it’s necessary and I’ll figure it out one way or the other. I can handle anything that comes my way.” The student that fails will think “Oh wow, if PostgreSQL is taking me long now, I must not be cut out for this. What kind of other problems are lurking out there after I figure out this one?”
5. Willingness to be vulnerable and ask questions. There is no such thing as a dumb question—or at least rest assured that your seemingly “dumb” question would probably seem incomprehensible to the average non-technical person.
6. The ability to break down complex problems into small, discrete steps. Could you describe your morning routine in 100 or more steps? Brushing your teeth alone could account for 25 of those steps. If you can do that, you’ll be fine with breaking complex problems into smaller steps. Your brain knows how to walk you to your bathroom from your bed because you trained it through years of balance and coordination and falling over as a toddler. Your Hypothalamus is dilating your pupils, your Medulla Oblongata is regulating changes in your blood pressure, etc. This all came from years of evolution. Your computer on the other hand is stupid. It only does exactly what you tell it to do—it’s a dumb slave. This popular misconception of computers knowing more than they do comes from Hollywood. Many studies show that students fail out of CS classes because they assume the computer is doing more than it is. They incorrectly assume, for example, that the names of the variables actually matter and the computer is interpreting them on your behalf. The names of variables are meaningless except for when you or other programmers are trying to figure out what your code is doing. This is what they mean when they say “are you a sheep or a goat?”
7. Knowing when to take breaks. Too much stress will mentally block you from being able to code or learn for a period of time, or write really bad code. You will often feel anxious (see this diagram for conditions for flow to understand how this will affect your productivity). You will experience this at least once during Bloc, and you’ll experience it many more times in your professional career. You’ll eventually get good at finding the stopping point.
8. Curiosity, but not too much curiosity. Curious is good, but don’t follow rabbit holes this early. Example: tracking down the source code for the Array Class’ append method and trying to understand it is a bad idea. Abstraction is good and it’s there for a reason, but there’s too much volume and it’s too early to zoom in right now.
9. Trusting that the curriculum is worth going through, even if it feels like nothing is “sticking.” You will not gain mastery in 3 months due to the sheer volume of topics covered, but you will at least know what you don’t know — to be able to find answers on your own, you must know the right questions to ask.
10. Trusting that you are in fact learning after you’ve been in the program for several weeks. When you’re in an airplane, you can feel its acceleration, but you cannot feel how fast it’s moving. Likewise, you’re sitting down right now in a seat. That seat is moving at about 1,000 miles per hour, and Earth itself is doing laps around the Sun at 67,000 miles per hour. Because of solar and galactic rotations, you’re actually moving through space right now at about 2.7 million miles per hour. In comparison, you will most likely feel like things are different in the first or second week, but that effect will wear off after you’ve accelerated yourself to the pace that is required to do Bloc. In reality, if you were in week 3 and could talk to your Week 1 version of yourself, you’d be surprised at how many things Week 1 Self doesn’t know. Yields, lambdas, and Procs might feel weird now, but remember when you were dealing with variable scoping and conditional logic branching and you thought that was difficult?

Closing thoughts

There was an academic paper written in 2006 by Saeed Dehnadi and Richard Bornat called The camel has two humps. It’s worth a read to understand the patterns observed in students who fail to learn to code in an academic setting. I’m emphasizing academic setting because in my opinion, that’s not the right way to teach people to code. It’s not where I developed most of my understanding.

This paper is referenced in academic circles in computer science claiming that some students are simply not cut out for learning because they can’t grasp topics like variable assignment, control flow, recursion, iteration, and concurrency. Some of these topics are very difficult for beginners. If you’re going into a junior development role, you don’t need to understand recursion or concurrency. Eventually you’ll work your way up to it.