How could computer programming be made easier to learn?

I just had a conversation today with my coworkers about whether or not everyone should learn programming or computer science. The topic ranged from the distinction between programming and computer science to what were the minimum basic skills someone should take away from a programming class. Due to the diverse nature of the conversation, I will state my perspective and let them weigh in with their perspectives (, , , , ). Based off of the current answers, I think there are some pretty consistent themes; there needs to be motivation, context, quick and attainable goals, and a good support system (good teachers). I've had the fortune of recently reading a lot of literature about behavioral learning in the context of health, but I think they apply here as well. Social Cognitive Theory generally states that an individual needs to have 1. some level of self efficacy 2. an understanding of expected outcomes and 3. goals in order to learn a behavior and maintain it. Self efficacy is the belief that you are competent and able to make the necessary changes that help you achieve your goal. Essentially, the lower your self-efficacy level is, the more likely you are to give up and quit when faced with challenges because they appear simply insurmountable. For example, If you think your recycling efforts aren't going to make a difference, then you probably won't recycle. This is why small goals that provide immediate results are so important and effective. It immediately shows a student that the code they've typed actually does something (whether that just says hello world, or produces an html page with a background color of yellow). Understanding expected outcomes usually refers to the cost-benefits of performing a particular action; the benefits need to out weight the costs. Exercise more, sleep less, work the same vs sleep more, work more, make more money. If programming is a required class, this criteria may not apply as much. I think the important part for this section is that for the casual learner, we have to show them how and why software development can be enjoyable. I think whether or not a student stays engaged and enjoys the process is also highly related to the goals of the class. There needs to be short term goals such as the simple output achievements to help build self-efficacy in the student and there also needs to be long term goals which help frame the context and purpose for programming in the first place. The learning process should always tie back to these goals so students know why they're learning this portion of the material (understanding expected outcomes). Where does the support system fall into this theory? I think teachers are a part of the system that makes this all possible. While many of us have learned to code and develop on our own, teachers are vital for students that need more hand holding through the process. Hmm, this answer is getting a bit long winded. I also realize my answer doesn't necessarily provide very concrete steps for simplifying the learning experience, but people are going to have very different learning styles and as long as we keep these concepts in mind, we'll be able to lower the barrier to entry.

Almost all of the programming instruction that I have seen or used takes a bottom-up approach. You start with the very basic pieces like conditionals, loops, etc., and build on that, adding something not necessarily related to the mix in subsequent chapters or lessons. There is also a focus on syntax at certain points - this is somewhat unavoidable, since you have to be able to translate thought into code somewhere. What follows is not necessarily a novel suggestion, but my opinion on how best to teach programming based on the goal (learning to build a specific type applications vs. becoming a computer scientist). When high school science is taught without calculus, you have a basic set of the math skills necessary to understand what's going on, but are limited in your approach by the amount of math you know - for example, in physics without calculus, you memorize various equations because you don't know how to derive them, and you make certain assumptions about the world, like that there is no friction. That's good enough to get through a lot of basic concepts and even allows a fairly decent understanding of physics - is it completely correct 100% of the time? No, you have to make assumptions. In a more top-down approach, my preference would be to focus on the end goal after the brief primer about the basic flow of code or syntax. For example, say the goal is to learn how to build applications, as opposed to becoming a computer scientist. Start with a finished product and deconstruct all of the blocks that make up this finished product. One of my major gripes about my early education (and even some courses in college) was that it lacked context - I learned a concept without knowing an application, so it didn't stick. I believe that starting with an end goal and working towards the pieces that make up that end goal will help with context. Think about classes like art or woodworking - your goal is to paint a picture of a basket of fruit, or to build a birdhouse. Do you start off with learning the ingredients that make up paint, or the history of the saw and how lumber is manufactured? No, of course not. You start with guided instruction - paint this arc, cut this piece of wood to these dimensions. This is how we teach people to build things - we don't start with esoteric theory and work to practical applications, we guide people through practical projects and then gradually decrease the level of detail provided in the instruction until they can paint or build on their own. While computer science is a science that has many building blocks and prerequisites, programming practical applications is more of a woodworking project. Yes, I can write a quicksort as a computer scientist, but why wouldn't I learn how to use a library sorting routine when I'm starting out as a programmer? Do I need to understand exactly how a sort routine works in order to sort something? Not any more than I need to learn how to make paint before I can paint a picture. We should teach programming more like introductory physics and woodworking - start with a basic set of prerequisites, and work on guided instruction towards whole finished products, gradually increasing the complexity and depth as we go, rather than starting with the most obscure concepts and building on top of those. Ignore the esoteric exceptions for now, and make sure that it is clear what assumptions are being made up front so you can start to remove them later, or add in little bits of good practice without explaining them immediately. Toy code doesn't have to be useless, just clear.

1. Learning for the sake of learning should not occur.      Musicians learn songs that they themselves enjoy listening to. However, it's not like this with programming. For some reason, CS educators think that learning how to write a recursive program that produces the nth-number in the Fibonacci sequence is somehow interesting to their students. That's not why most students initially take up programming in the first place. Students want to make video games or cool websites like Quora! That other stuff should come later, when it is applicable to the end-goal, not just because it should be learned for the sake of learning it. A context is needed when learning something. 2. More "repeat after me" needs to occur.      When you learn to play piano, you immediately know what the result should sound like, and it is a step-by-step process where you simply follow the notes on the sheet of music. From this, you can observe how the notes become the end result without being taught this directly. Thus, you are, in a sense, also teaching yourself. Though at first you cannot be creative, over time you learn from the patterns and can play with more feeling, and can eventually create your own songs. Sometimes, this takes years.      With programming, beginner programmers are immediately expected to create programs from scratch. There is only an explanation of what the programs should do or look like, and typically no interactive example is given so reverse-engineering cannot occur. There should be more "here's what the end result should look like. At first, here are some steps to follow to achieve this result. (Later on:) Reverse engineer this now that you actually have the basics down and have observed how certain things are used."

I think about this all the time. I tried to learn to program many times, and always bounced off. I think what made the last time different was that the environment was the web. So there was an incredibly quick payoff: it only takes a few minutes to get something showing on the screen with HTML, and not too long after that to share it with your friends. After that, there's a long slow ramp all the way up to very complex JavaScript development, server-side, databases, etc. So to me, I think a big part of it is getting people the payoff of "wow, I can make something show up on screen!", and "wow, I can make something my friends can see on their screen!" as quickly as possible.

I don't want to come off as a Bret Victor fanboy, but I believe the man is on the right track: Bret, and are all pointing towards the same thing: Abstraction makes it difficult for people to stay engaged. I come from a Photoshop background. I'm used to seeing direct results. If I use a paintbrush, then I can see it work immediately. It might not be pretty, but it's there. Code is different, code requires you to create a mental model of what is going on before seeing anything. If something goes wrong then you have to step through your code. Instant feedback and 'inventing on principle' as Bret calls it, alleviate this problem greatly. But I don't think that the problem lies solely with the medium. Programming is hard. Good programming is really really difficult. I'm taking Norvig's "design of computer programs" on Udacity right now and the patterns he pumps out blow me away. Thus when teaching programming it's important to have the right teachers. Udacity is awesome in this regard because not only is Norvig a great teacher, but I can replay what he has to say. I'm also constantly busy answering questions in between the small chunks of video. I think that programming is hard for similar reasons that math is hard and quantum physics is hard. We're not used to pushing around abstract symbols. We're not built for that. I'll never forget what Susskind said about Quantum Physics: "Physicists rewire their brains after years of practice." Programming is similarly an alien concept to the average Joe (and also the not so average Joe). The initial hurdle is huge. Even in college there's a difference. As an econ major I often deal with counterintuitive results. But the math behind the econ is intuitive. On the other hand I took a linear algebra course and found myself dabbling in abstract mathematical definitions. That blew my mind and then taught me a lot. Once you get through those initial phases it becomes more manageable. Chris Granger recently took Bret Victor's ideas and developed it into a concept called Light Table. http://www.chris-granger.com/2012/04/12/light-table---a-new-ide-concept/ I think that combining tools like that with learning platforms that allow for custom paced education (Udacity/Coursera/MITx) will increase  the enthusiasm to code.

I agree with Aaron Boodman's answer - the immediate payoff effect makes it so much easier. When I was first starting out I gave various tutorials and books a shot, but those never came through for me. Not a single one of those guides actually produced anything tangible, and almost all of them ended with "..obviously, this example is not production-worthy and is only an example, you should probably pay more attention to X and Y while working on a project for live deployment..." and this was one of the most discouraging parts because X and Y were never to be found anywhere, or required "paying attention" to Z and W and Q ... In essence, my opinion is that computer programming could be made easier by giving concrete production-worthy examples on small separate units that can be easily combined into a greater whole without losing integrity.

I think the population in general is way too underexposed to programming, while it's certainly not for everyone, I do believe it's an increasingly important skill especially in the job market today, and it's unbelievable that it's still not part of the standard curriculum in our schools, I mean, programming should be just important (if not more important) than subjects such as Math and Geography. Everyone knows Bill Gates has made more money than God, but how many people know that he started programming since he was 13 years old? Bottomline, I say get kids involved in the beautiful art of programming as early as possible.

Other than those who are naturally endowed with this ability, there really is no substitute for a great teacher. I fortunately had that endowment and needed no assistance to pick it up. I took to it like a fish to water. But my son was probably a little less to start with. It didn't help that he had a lousy teacher in junior classes. I nearly took off in orbit when I realised that he had taken to memorising lines of code for standard programs. Then I sought and got him a good tutor. The man was just amazing. In six months he had turned my son around, and now he writes tough programs just as well as I once used to - if not better.

Head on over to Programr ( http://www.programr.com ) and practice programming using the automated 24x7 faculty there. It gives you exercises, spots bugs in your solutions and then gives you hints on how to solve each bug. Disclosure: I am founder of Programr.