This is a post in our anniversary series 500 in 5. Check out our other posts in this series.

AND IF YOU CAN, DOES THAT MEAN YOU SHOULD MAKE A CAREER OF IT?

After five years of teaching students with limited or no prior training and experience in programming we’ve learned a few things about what works and what doesn’t work. And we’ve learned a few things about who can learn to code (and about who can but shouldn’t bother). Here are a few of our Lessons Learned relative to who can learn to code.

Lesson 1: Almost anyone can learn to code

A big question for years in the computer science and software engineering community was - who can learn to code and how can we identify them? Implicit in how the question used to be asked was the belief that not everyone could learn to code and the corresponding belief that there was an innate aptitude for coding that you either did or didn’t have. There have been studies of computer science students and computer science teachers that showed that large percentages of comp sci students couldn’t (or didn’t) learn to code in their classes. And for years the majority of computer science professors have held to the belief that many people just don’t have the aptitude to learn to code.

For years I belonged, at least to some degree, to the “some people just don’t have the aptitude” school of thought. I have to admit to still holding on to some of that old belief. However, our experience over the last five years at NSS has taught me that if such a thing as aptitude for coding exists, it is not some single factor that sits in the student’s brain and predetermines success or failure. It’s a much more complex cocktail of factors that has as much or more to do with the student’s beliefs about themselves,about learning, and about their potential as it does about their ability to think logically or do higher order maths. And that means that aptitude is not some innate, fixed factor, but changeable.

As Barbara Oakley discusses in her book Mindshift, those beliefs that the student holds can be modified. That’s why we recommended Mindshift on our blog a couple of weeks ago. So much depends on the student’s mental models about themselves, what they are “good” at, how well they do at math and science, etc. As Oakley demonstrates in her book with so many of the profiles of students an individual’s mental models can be changed. Many of our students built their own mental models based on things like: “girls aren’t good at math and science”, “you aren’t good at math and science”, “only introverted weirdos make good coders”, “you have to love math to be a programmer”, or whatever. Shifting or reframing those models can and does totally change how people experience school and learning.

Many people still hold strongly to the view that there is only a relatively small population of people with the aptitude to learn to code. A lot of those folks are really talking about the aptitude to learn some of the “deep” computer science subjects, not about who can learn to be a good developer at the application software level. At the application level, we believe that most normally intelligent people have the aptitude necessary to work at that level. Success is based on factors besides aptitude such as how the subject is taught and does the student want to learn it badly enough to put in the hard work.

Lesson 2: Almost anyone can learn to code, but it makes a big difference how it is taught

I have believed for more than 45 years that it doesn’t take traditional computer science classes to learn to code. In fact, quite the contrary. I myself learned on the job by being mentored, by reading, and by (most importantly) writing code and getting feedback. Over my career in the tech world I have known far too many software engineers who were self-taught, or who learned outside a traditional classroom environment, to believe that taking computer science classes correlates at all to knowledge of how to program or to the excellence of the programmer.

In fact, I came to believe over the years that the barrier to learning to code for many people was the way that programming has traditionally been taught. That’s true to teaching kids or adults and it’s true for how programming and computer science are taught in high school and college.

Bluntly, the traditional academic approach to teaching computer science is more likely to drive people away from wanting to develop software as it is to attract them to the craft. Of course, that’s because in academia they generally aren’t trying to teach the craft of software development, they are teaching computer science, which is a related but different subject. We take a different tack to teaching as we have a different, explicitly vocational, goal.

Our approach engages students in building things from the very beginning. Let’s see what we can learn to build. Let’s do it immersively (if you’re in one of our full-time bootcamps). A lot of the time, let’s do it in a team just like in a real work environment. This approach builds engagement. It builds skills that are work-relevant - both hard skills and soft skills. It makes the process a lot more fun - yeah, fun. Let’s face it folks, building stuff out of code is fun. And if it isn’t, maybe that’s telling as to whether this is going to be a good career path for the student. And better for the student to find that out early.

Corollary to Lesson 2: The way we teach is not ideal for everyone

We have also learned that our approach to teaching is not ideal for everyone. Some people just don’t match up well with how we teach. Our approach works for the vast majority of our students, based on our historical graduation rate of over 90%. But, our approach moves fairly fast and hits students with something new every day. Even with strong support from our normal three-person instructor team some students need more time to build their foundation and find a way to use all the tools we’re giving them. Often it’s enough to give those students a chance to repeat the front-end engineering portion of our course, but not always.

And, some people just don’t want to take sufficient ownership of their own learning experience. These individuals want to be taught, not learn. Our approach has evolved over the last five years to be very learner (and learning) centered. Some students just struggle with our approach, which is very different than traditional schooling in high school and college, which (in many disciplines) tends to be teacher/teaching centric. We don’t get many of these folks into the classroom but when we do it’s not uncommon to hear something like “but you aren’t teaching me anything”. Which in a sense is true in that we don’t spend a lot of time lecturing or broadcasting information from the front of the room into the students’ ears. We demonstrate, we provide examples but most of the learning in our classroom is driven by the student doing hands-on coding to apply the new skills/knowledge/concepts we’re dealing with on any given day.

Lesson 3: Persistence and drive are more important than aptitude.

This is possibly the most important lesson of all: how badly the student wants to learn is a far more important predictor of success than “aptitude”. Call it persistence, call it “grit”, call it drive - whatever this factor is it has more to do with student success - both in class and relative to finding a first job - than anything else.

Even though we teach software development in a way that engages the learner, this is still not an easy thing to learn to do. For almost everyone there are moments of intense frustration and feelings that they might just not be cut out for this after all. It takes lots of practice, lots of repetition, lots and lots of mistakes. And face it, even though we may be told that making mistakes is a natural and essential part of learning to code, it just ain’t fun sometimes to “learn by fixing our own mistakes”.

I think this factor is a major one in why we love students that are switching careers from music or audio engineering (this being Nashville, we see lots of these folks). Anyone who has learned to master a musical instrument well enough to play professionally in this town has more than demonstrated the persistence required to learn to code. Same for anyone who has been a working audio engineer. Plus, the process of learning to master an instrument has many similarities to the process of learning to be a professional software developer. There’s intensive, repetitive practice applying the basic patterns of the craft against the requirements of a unique problem (whether a song or an application). There’s the need to deliver ones part but in the context of a group effort (whether a band or development team). And there’s that whole you can’t learn it without making lots of mistakes thing.

Bottom line, if you have persistence and drive, are capable of learning in a hands-on, immersive environment, and believe you can do it, you can learn to code.

We’ve got more Lessons Learned to share but I need to stop here for now or my editor will kill me. Watch this space! More coming soon as there’s a lot we have learned over the last five years. Even better, there’s more we learn every week that goes by.