Nobody Wants to Learn How to Program

I frequently see a problem when people (especially techies) try to teach programming to someone (especially non-techies). Many programming tutorials begin with basic programming principles: variables, loops, data types. This is both an obvious way to teach programming and almost certainly a wrong way to teach programming. It’s wrong because nobody wants to learn how to program.

If you are teaching a class of adults who are paying with their own money for an education, then this is an appropriate and direct way to teach programming. It’s their money. They expect that they’ll have to focus and slug through concepts to come out the other end with programming knowledge. The start-with-variables-loops-data-types approach is fine for this. But most likely they still don’t want to learn how to program.

But for the casually interested or schoolchildren with several activities competing for their attention, programming concepts like variables and loops and data types aren’t interesting in themselves. They don’t want to learn how to program just for the sake of programming. They don’t want to learn about algorithm complexity or implicit casting. They want to make Super Mario or Twitter or Angry Birds. This idea is best summed up in one of Ryan North’s Dinosaur comics (click to enlarge):

Here are my five pieces of advice to people who want to teach programming or create programming tutorials:

1. Kits Are Not Programming

If you make the realization that nobody wants to learn how to program and jump past that trap, there’s a second brick wall on the other extreme you might hit: software creation kits. This is especially notorious with drag-and-drop game creation kits. In trying to make it programming easy to do and abstract away details, these kits end up getting rid of, well, programming. (Although there’s no end to products that claim to let you create applications without any programming at all.)

But people can feel the limitations that these programs have. Many of these kits are good for creating a certain class of applications or certain genre of games, but have a restricted reach because they aren’t flexible enough. We need legos, not playsets.

(I enthusiastically endorse Scratch for use by the pre-teen crowd, especially since typing can be a large barrier to programming for that age group. Scratch rides the kit/programming line very well. GameMaker, RPGMaker, and other kits, not so much.)

2. Toy Examples Are Fine, As Long As They Are Braggable

Almost every programming book and tutorial has examples, but these are usually code snippets to demonstrate a single function or concept. Breaking down learning material to single concepts and providing a simple example. This is an obvious way to teach programming, but nobody wants to learn programming.

The main examples in my book, “Invent Your Own Computer Games with Python” (free to read under Creative Commons at present the complete source code to simple games like “Guess the Number” and “Tic Tac Toe”, and then explain how these programs work. A small amount of programming concepts had to be taught at the start and some single-concept examples are given, but the chapter always centers around a complete game.

The first few game programs are all under 50 lines long, but this is fine because they are still complete programs. This isn’t something they can make money off of in an appstore, but the standards for something neat enough to show someone else are much lower. By leading with complete programs and then explaining the programming concepts that go into them, you give the learner a reason to continue learning.

As a result of what code goes into each game program, programming concepts in “Invent with Python” are given in an unorthodox order sometimes. That’s fine. Beginning programmers don’t realize they’re learning concepts in a weird order and don’t care as long as the learning material makes sense. If you are creating tutorials for self-directed learners, they’re going to learn in a non-linear manner anyway.

3. Beginner Programmers Are Plagiarists (So Give Them A Lot To Plagiarize)

I began learning BASIC in the third grade. This might sound impressive to people who think that only the highly intelligent can learn to program computers. The thing is, all of my programs for the next several years were just slightly-modified copies of the same two or three types of programs I had already seen. They were mostly print and if statements with a few random numbers thrown in.

Newbies’ programs bear a lot of resemblance to the programs they’ve already seen because they don’t have enough experience to know how to take an original idea and deconstruct the code needed to make it. So help them along by giving them several different examples. (“Invent with Python” has simple “coin toss” guessing games, games that manipulate strings such as Hangman and Bagels, games that use 2D Cartesian coordinates, and a small encryption program).

It’s okay if they don’t completely understand how a program works after they’ve played with it a little. Very few ideas are completely original. The more material you give your students to plagiarize, the wider the range of derivative works they’ll make from them.

4. My Programs, Let Me Show You Them

One thing that MIT’s Scratch programming environment gets right is that they have a way to share programs that students create built into the software directly. Nobody wants to learn programming, they want to make cool programs. Being able to easily share their programs with a community not only provides an incentive to learn and create, but it also provides a library of examples for other people to look at to inspire their own programs. The website has a sidebar that is constantly updated with people’s submitted games (source included), which supplies that community with hundreds of examples to learn from. I’d say this is a major factor for Pygame’s popularity over Pyglet and other Python game frameworks.

5. Don’t Distract New Programmers with OOP

Enough said. Things you can also toss out for the new programmer syllabus: recursion, regular expressions, MVC, networking, and file I/O. These things can come much, much later after they’ve made a few programs on their own.

If you are teaching programming, remember that nobody gets excited over remembering to put semicolons at the end of a line. Nobody wants to learn programming, they want to learn how to make programs.


Zed Shaw (author of the great book "Learn Python the Hard Way") left this comment on Hacker News:

"And no, I'm saying it's a huge myth that nobody wants to learn the "hard stuff". They do, you just have to teach it right. After that you just have people who aren't interested in programming at all and no amount of graphics, games, or cute cartoons is going to make them want to. You can't force or trick enlightenment on people.

But more importantly, I have evidence to back my beliefs. This article has absolutely no evidence."

He brings up a good point. Here's my response:

"Hi Zed, I'm Al, the author of article. I'll admit the title is hyperbole. There are people who want to learn programming for the sake of programming, just like there are people who like learning math even though they don't see immediate practical applications.

I teach programming to a tiny class of 10-12 year olds on Saturday mornings, and have taught a couple one-off classes at Stanford's Splash program to a classes of a dozen students. I've found that having an end-goal in mind of what they will create is a much better hook than just explaining what for loops are (or the idiosyncrasies of the languages are, which Python & Ruby are good about keeping to a minimum.)

I don't think graphics and cute cartoons are needed to make programming engaging either. My book "Invent with Python" has games that use ascii text up until the last few chapters. There's a pretty low standard for games/programs that are cool enough to show off to other people, but nobody ever shows off code snippets.

I think the best thing about "Learn Python the Hard Way" over a book like O'Reilly's "Learning Python" is that your book cuts it down to the bare concepts: "Type this. This should appear. This is what is happening." That's great compared to most computer books where there are paragraphs upon paragraphs that could be whittled down to a single sentence or cut out entirely. "Learn Python the Hard Way" is barely over 200 pages. That's much more digestible than some 600 page tome.

I just think that many classes where the students aren't CS majors or necessarily dedicated to learning programming forget that it's not just the concepts that people want to learn but what they can make using those concepts. Small games and web apps are great for that. Like in Exercise 22 of your book says, "It’s important when you are doing a boring mindless memorization exercise like this to know why. It helps you focus on a goal and know the purpose of all your efforts.""

59 thoughts on “Nobody Wants to Learn How to Program

  1. Totally agree with all points! One thing that I also see as really important is a short feedback cycle. Short programs or programs to copy help with that. Graphical environments (I've used Processing as well as Scratch) are also helpful.

    For me as a kid, that change-test-repeat cycle was the hook. Once someone is hooked, you just feed knowledge in the side and guide the process.

  2. Nice article thanks. I agree with your last point (oop) especially. I'd like to hear your opinion on teaching programming via some sort of a scripted language which takes commands at runtime, e.g. like logo (turtle graphics) which was popular in my computer class as a kid. And what's your view of a game like Minecraft (which is incredibly popular with young kids); do you see level/world building as a basic form of programming?

  3. When I started programming, I suffered through these mistakes you mentioned and because of it, I was so distracted by OOP that many times I would stare at my java file, not knowing where to go next to solve a problem. Because of OOP, it took me an unnecessarily long time to realize that all computers simply do is take data from memory and change it and put it back. I wish during my intermediate phase of programming, I was shown something like this:

    A program that stripped away the abstractions of code to show what was going on in the machine itself.

    At a beginners phase of my learning, I wish programmers who were showing me their profession didn't concentrate so much on the technology ("oh python is this scripting lang…" "…oh so it's a procedural language. Well it'll be easier for you to learn object oriented…oh you don't know what that is? Well imagine a bike…" "…vim is a modal text editor…" "…with the GNU debugger, you set breakpoints…" ) Instead of concentrating so much on the technology, leading them to blurt a bunch of terms that were going over my head, I would have appreciated if they at least explained their workflow. How did they solve problems? What is there mindset like? What makes them enjoy programming? Essentially, communicate to me what I might become as person if I took up the art of making programs. The best I've seen of this is watching Notch code and him blurting out what was going on in his mind:

    That last point doesn't really have much to do with learning how to make programs, but more about programmers communicated better to the laymen. We don't have many literature akin to G. H. Hardy's "A Mathematician's Apology" and even if we did, it totally was buried to me as a beginner by all these technical wikipedia articles and open source software websites.

  4. Hi. Nice post. I also teach game programming at College here in my country (Brasil). The course is focused on game design and not game programming and this has a great impact on the students' will to learn how to program, but, although I agree with you that "They want to make Super Mario or Twitter or Angry Birds", most of them (my students at least) wants to make them without any programming at all. Maybe I'm approaching the problem in a wrong way, or there's something else I'm missing, but I don't see a great enthusiasm in general for programming. Again, they are taking the course because of the game design and not programming, but the minimum ammount of programming knowledge I (and the supervisor of the course) think is worth learning, they tend to still think it's too much.

    Scratch is a nice tool. In my first classes on game programming I use Processing ( because it's essentialy programming and the result is visual, not just a string printed on the console.

    Anyway, thanks for sharing your ideas. Maybe I will try them too and see if I can change the students' mood about programming.

  5. I was recently involved with an online discussion where a teacher was arguing that teaching programming should be left to 16+, as it required a level of maths and logic that they wouldn't have.

    My response was that I, and my peers, all taught ourselves to program at the age of 11. In retrospect, we did it exactly following your approach - typing in games listings from the back of magazines, then adjusting them into something else - or trying to copy the arcade games we liked (I recall writing a poor version of Frogger and Space Invaders. In BASIC, rather than assembly, so dead slow).

    Of course, the priesthood would disagree, but then priests often offer warnings you should pay no attention to

  6. Great read. As someone learning, I totally agree that full working code is much more useful than snippets. Let me tweak and change to view something actually exciting.

  7. Addendum: Great article. My dad first taught me (I am now 35 and professionally programming for 15 years) to program when I was 5 by making it seem like a game to try to make a text bat \O/ -O- /O\ fly across the screen and this, along with your suggestions, are how I'll teach my son.

  8. Absolutely, nobobody wants to learn programming for the shake of programming but to make programs. However, in this fast moving world starting every program from the "Hello World!" is being crappy, they got to have something common, avoidable to get started with.

  9. What you describe in your introduction is not learning to program.

    Most people when they want to be a carpenter they want to build actual solid goods.

    If carpenting was learnt the way programmation was learnt, you would have to spend endless boring years learning hammers, cisels, glue concepts and how to craft tools before even using one. And you would be -as you implied it- demotivated.

    On the other hand, I come from Perl, where CPAN is actually full of usable sample of code for real use case that you can learn to mix in order to achieve *real goals* (your point). I came to python by matplotlib, that comes with extensive short snippets of code you can try in a console to show graphs.

    So I do agree with you on almost everything.

    But, programming is not about learning programmation, it is about learning to be creative, to ship your code and the price to pay. It is a craftmanship.

    Realisation worths more than idea,
    Publish early even if it is crappy,
    The vanity of thinking you are right, the humility to accept your mistakes,
    Going further by standing on the giant's shoulder,
    QA is boring, but is the skeleton of big enough software,
    system is abstracted by langages, but you cannot pilot accurately a bot in a space you ignore,
    Programming is being alone in its head, but ultimately you connect to others so know the exact concept of the system with which you interact (human beings included),

    Programming is as much a destination (shipping your code) as a journey (discovering where your imagination leads you).

    And above all : believe in the ignorance of the experts.

  10. Great post and advice.

    Also, I think you mean "derivative" not "derisive" which implies you want young programmers to produce programs with contmpt.

  11. I learnt to programme by typing in code from magazines and then debugging it. We did also do some simple stuff at school but I remember logo and making robots draw stuff better than any of the BBC stuff they taught us. I got into programming to create stuff not because I enjoyed the syntax (z80 assembly code syntax is not particularly enspiring)

  12. This is by *far* the best article on teaching programming I have ever read. Points one and two in particular really cut to the heart of it.

    Maybe there *is* hope for something like Robot Odyssey in the modern world, if only it could get more shareable and braggable...

  13. You programming book publishers should be happy with the likes of me. I have bought over 30 books of programming, and still can only do about 2 lines of code if I'm lucky.

    I can certainly point out a few problems. First off-I have a learning disability & I would fall hopelessly behind in a classroom setting. That's a personal thing but...

    1. Studying ANYTHING on your own is very difficult.

    2. If you actually don't use a programming language much of the time-you forget it fast. Really fast. So if you don't do it for a living...

    3. Programmers( and this is going to sound like a politician or athlete blaming the media) are NOT good authors. They never write a book from the shoes of the student. Authors can assume NOTHING about what a potential student reader is going to be told by you the author. Your reader knows nothing or , for sure, not what you assume, he already knows.

    4. You can NEVER make something for the beginner too simple. Genius is the ability to make something complicated or murky understandable. Any idiot can complicate a subject-be it simple or complicated to start with.

    5. And the last a general thought-liberal arts majors are not esteemed in the high tech field. What a shame & what a pool of talent many companies miss out on.

  14. Good post. I don't teach programming, but I often think about how it could be taught differently. Like you, I also taught myself, starting with BASIC right around 3rd grade. On a TRS-80 Model 100 laptop, actually. I remember when I first figured out you could turn individual pixels on and off as opposed to just having text.

    I experimented with Perl on a Mac SE back then, too, but honestly I got most of my first "large"-program experience with HyperCard, which was a really great way to learn how to code. HyperTalk was essentially object oriented, but the ability to organize things graphically and then dip into more and more code on individual buttons and cards made OOP seem intuitive when I finally learned about it much later. Most importantly, it wasn't a kit for making games; other than a few buttons and shapes, there was nothing prefabricated to work with; but at the same time it obviated the need to learn a lot of esoteric system calls that I was struggling with in Perl, just to set up a window to draw in. It was flexible enough to write some real simulations or even business applications. And SuperCard took it even further let you compile color, no less.

    It's a shame that things are made so easy, colorful and kid-friendly now that there really isn't any programming involved. The end result is a lot less rewarding if you didn't have to think around a few problems to get to it.

  15. "Bear a lot of resemblance". To bear is to carry; to bare is to strip away the covering on something.

    This is a great essay and sums up a lot of what I feel about learning to program. And your books are awesome, thank you!

  16. I thoroughly agree with your article and have been thinking and saying the same thing. Same goes for teaching Spanish. I took Spanish in middle school, 2 years in high school, and 2 years in college and I still cannot hold a conversation. I learned basic and logo in 3rd grade, a basic in 9th grade and took a programming course of concepts in college and I still can't write a program. I'm going to try your book.

  17. As someone who has been trying to get kids interested in programming by turning them on to, this is a welcome source of alternative ideas. I have not been entirely satisfied with codeacademy (but kudos to them for doing it) and perhaps the Python approach will work better for some. Unfortunately, in a school environment, it is sometimes difficult to get authorization to install the required software. I plan to try though!

  18. Great blog post. I agree with much of this, and will probably adapt my teaching methodology based on the rest!

  19. +1 --- we run into these same issues when teaching scientists how to program (they'd rather be doing science). Mark Guzdial & colleagues have hard data showing that a "multimedia first" approach to programming works well: if people's first practical work is resizing and color-correcting images, they learn "real" programming while doing things they can show off, and as a result, retention rates are significantly higher (especially among traditionally under-represented groups).

  20. Nicely said, Al. I will send a link here to several people I know.

    Darn you spellcheck: "derisive" should be "derivative" (#3, last para).

  21. Really interesting article. I'm currently considering launching into teaching some form of programming to 13-year-olds so this has given me some food for thought. Thanks!

  22. Agree on much of the article. I'm trying to get my nephew (8 years) to learn how to program and i can see, that he's very interested, but at the same time, i have to deliver the incentive in form of actual results, so programming a sort algorithm (to name an extreme version) would really not help at all..

    Initially, I started out with some print statements and it was nice seeing him printing 1.000.000 times his name, but it got old after a while. Then i got him to learn the basics of turtle and that was nice, because he got to write his own name and others' now graphically. But i was astonished, when he asked me, why some lines were zig-zags rather than straight lines and i realized, that he doesn't know about pixels! We got over that point and i was going to let him program an old plotter (i built a simple turtle-like syntax to drive it), but we didn't get to that yet.

    Instead, i've been programming with him some simple pygame-game inspired by the recent humble bundle online game programming event (majong). I didn't know pygame before, but i think it's really nice, that you can achieve nice results with little effort. Also, it gives him the opportunity to have his say in what the content of the game should be and what graphics we should use..

    Next stop is going to be raspberry pi. I hope to be able to get him one for himself to give him some pride in his very own first computer. Let's see what comes after..

    Thank you very much for your tutorials by the way.

  23. Huh. When I began to learn programming, it was not about variables or control structures. It was about the skills to analyse a problem and break it down into small parts that could be communicated.

  24. I've never had as much interest in my classes as I have right now--decided to give up both plan periods this semester rather than cancel two extra Intro classes. In this economy I consider myself pretty lucky to have so many students interested in taking CS courses.

    My lineup:
    --Python (and Pygame)

    I also teach Java (required for the APCS course), and lately we've been developing mobile apps using HTML5.

    Supplement those with Inkscape and GIMP for producing graphics and Audacity and GarageBand for audio, and you have a great setup for producing interactive visual programs, games, and other applications.

  25. I must disagree with the whole "nobody wants to learn programming". As the guy who loved his classic programming classes with print a + b, and why goto is dumb. I also love recursion and make a living coding algorithms. No, not programs, but pure mathy algorithms.

    Either way, this is just another remix of the theory vs. practice debate. As the site is called inventwithpython I have no doubt that the bias here is towards practice. But the reality is that no matter how cool practice is, without a firm theory you will learn things through your practice that you will find hard to unlearn. Maybe you don't like to learn structured programming, but such is life, you will HAVE to learn it if you want your programs not to suck. Because really, we don't have a shortage of people who can make programs, so as society we are not obligated to teach you programming the way you like. What we do need is less people that are terrible at programming, and thus we will have to be serious when teaching you programming to avoid to increase that number.

  26. I agree with a lot of points in this article, and think that students having something to 'show off' and be proud of is an amazing motivator.

    In an actual classroom setting, having an enthusiastic mentor can also be a great benefit. It's invaluable to have someone there to help and figure out subsets of larger ideas that are actually possible to implement.

  27. What's wrong in learning how to program? I think "Nobody" in your post title is way too strong? Quite many people do enjoy the "how", ponder at the intricacies of the "how". Yes. The end - the solution of the problem being solved - is the glory. But the journey - the way of formulating the solution for a computer - is a reward too!

  28. One thing that I think would make learning programming a lot easier is to give more "context" to material being studied.

    Too many tutorials and texts come at the learner like this...

    TITLE - How To Do Something.

    INTRO - Something is very important in programming. Today we are going to learn how to do it.

    STEP 1 -
    STEP 2 -

    What I find more helpful, is something like this

    TITLE - How To Do Something

    INTRO - Something is very important in programming. Today we are going to learn how to do it.

    CONTEXT - Here are some real world examples and applications where you can see the things we will be learning being utilized. Some of the things we learn are not really used in "real world" programming. Concentrate on A and B, but C is something that you wont be doing when you advance your skills. The hardest part to understand about the topic is D and you will probably want to create some kind of reference target for yourself for this.

    Maybe this is too much hand-holding, but I found that as I was teaching myself to code (and taking courses with less-than-stellar instructors), one of the biggest problems was simply being lost in the middle of it all, with no real idea of what is the important stuff what isn't, where everything is going, and when to stop.

  29. Thanks Al for the excellent article. As a professional that started learning programming back in 1973 (FORTRAN4),i can relate to your concepts abut the best way to promote interest in the subject, particularly to the beginners. I was one of the many that suffered through the experience due to a wrong way to teach programming and still came out as one of the few that made a career out of it.

    I left programming in the mid '80s, but i decided to come back at it last year and i found that the best way to reacquire the skills & knowledge was the way you so well propose and describe.

    Now, i enjoy it despite of the in my opinion current wrong approach to programming itself !(Back in my time we mostly underrated COBOL, but nowadays i wish programming languages were as simple and the workflow as easy to follow, as it mostly was with COBOL)

  30. I agreed with most points except oop. You said it yourself that teaching language syntax is boring, oop concept and language is difficult to say the least. However we live in the world of objects. What better way to teach new programmers who have little interest in logic and mathematics, but in reality what they already knew -- objects and their relationship. We just need to create a better way teach oop early without involving syntax(until their hooked first of course).

    I found that teaching music by reading musical notes and drills will put kids to sleep quick. However, I have been teaching classical guitar to teenagers and no one has quit yet. Don't teach them about cord, notes, etc. Just pick a song they like, and start with a simple melody, then add a few note each time. Pretty soon, they can play a song (in a day). Some of my trainees don't even know what power chords are, but they write and play complex classical songs few professional could.

    An old chinese proverb: words are spoke kidding, what lies under the words are the real meaning.

    To take Scratch idea further, we (computer engineers, researchers, professors) need to do away with programming languages. Use symbols, blocks, connections as objects and messages to build application. These elements generate machine code directly. Just like natural language, we understand them intimately.

  31. I certainly don't want to program. I want to do things that I can only do by using a computer program, and there are no such programs. Therefore, I program.
    I taught myself programming. I now write the programs I need and use and they work very, very well. I have yet to write a single line of recursion, MVP, networking, or regular expressions. I hope I never have to.

  32. Excellent article that applies not only to programming. Years ago when I started taking guitar lessons, my instructor (who was a guitarist with a local jazz band) told me up front that his method was to get me playing something (anything) as quickly as possible rather than overwhelming me with music theory and finger exercises up front. I didn't have to do months of scales before I could play recognizable tunes (McCartney's Blackbird and Paul Simon's The Boxer). I wasn't going to become a Segovia or a Don Ross but I saw steady progress. The theory eventually followed. When results come quickly there is motivation to continue.

  33. Probably the best advice I've seen in a long while. What counts is the doing - create a web app for HR or sales staff and they want the app to help them do their work quicker and easier - not give them one more thing to learn how to do; one more thing that makes their day more frustrating.

    Learning more advanced aspects will come easier after the beginning topics have been internalized.

  34. @ i❤computers - thanks for those links. i don't even understand what that python visualizer is doing but it looks like if i spent some time with it i'd get a lot out of it.

    and that vid of notch programming is excellent. as one of the commenters said, "he codes faster than movie hacking!" i agree. what he was doing looked practically fake it was so fast. and man, debugging in real time while the game is running would have been an amazing ability to have back years ago when my friend and i were hacking quakec code for mods.

  35. People assume that learning to program is a function of natural curiosity and enthusiasm for the process of creating a program. I think that's a bad assumption and I'll tell you why.

    Lots of people out there see programming as a job, not a lifestyle. They don't program unless they're being paid to do it. And you know what? THERE'S NOTHING WRONG WITH THAT. Some people like to leave the work behind when they go home for the evening (and some like to leave the office at a sane hour, like *gasp* 5PM).

    Are the enthusiasts better programmers? Probably some, but not all. You can be a competent programmer and have no interest in the subject beyond getting your assignments done at your place of work. Is that limiting? Probably. But does it let you pay your bills? Yes. And in the end, it's making money that matters, not how psychotically obsessed you are with the subject. You can be the best programmer in the world, you can dream in Java and Python and (insert language here), but if you're not getting paid for your skills (or not being paid enough) then it's meaningless.

    Programming is a marketable skill, like typing or working with Office or managing people. It shouldn't be elevated to an unreasonable level, because to the rest of the world, it's just another item on a resume. Some might see it as black magic, but those people are wrong (and stupid).

  36. I think part of the problem (in the U.S.) is that most educators in computer programming are actually Computer Science university instructors, and the classes where students learn computer programming are Computer Science classes.

    With a class called Computer Science taught by someone with a PhD in Computer Science and your major is Computer Science, of course you're going to learn recursion, data structures, OOP, etc.

    I would argue that teaching Computer Science would be a lot more effective if the students could do some basic programming -before- they started learning CS.

  37. I really like your old book and am looking forward to reading the new one. It is on our 'recommended further reading' list for our introductory programming website
    which aims for the true beginner audience, with no prior coding experience... we try to minimize the slope of the learning/installation curve.

    I appreciate hearing from more people that their first 'programming' was just copying from a book... I remember coding Wacky Mad Libs into my Atari's BASIC environment! More than anything else, people who I have met who became serious programmers seemed to learn best when they had oodles of free time to use in playing around with code. I think teaching students some elements of computer science as early as possible is important for this reason (6th-graders have an awful lot of free time).

  38. I feel alone... I have always been fascinated by technology, and while I admit I originally wanted to be a game developer, I have since ditched that and I now want to pursue artificial intelligence. You are making a hasty generalization. I love programming. The only problem is that I feel that colleges and universities spend too much time going by the book teaching the various principles of programming, and not enough time showing you how to apply that knowledge.

  39. YES, if they can see some early success. Yes, if the overhead doesn't fry them.

    I've taught Comp Sci for 20 years in a high school. The secret is a simple language that lets them have early success. Sorry to mention this, but the best language I've found to "hook" them to further programming is BASIC (stop cussing my name, just reporting my experiences.)

    I've had students, that found out they did NOT want to program, come back and tell me how valuable their exposure to programming was in later life (especially college and work.)

    Too bad, it is a disappearing entry. I've had to go to some extremes to keep it running, as a SIMPLE language, on our school computers. TrueBASIC (c) won't run on Mac OS 10.2+ so had to get CrossOver to act as an emulator. Awkward, but within minutes I have students running "Hello World".

    Then I "set the hook", and I've got'em. (Not just the geeks, but 90% of the students, for a happy and productive year.)

    With a high School graduating class of around 85, I've sent as many as 7 to college in CS, 5 graduated in CS. ( Of course that was an exceptional year, normally send 2-3 to college.) Not to shabby, if I do say so myself. I think it was the BASIC and the problem solving approach we used.

Leave a Reply

Your email address will not be published. Required fields are marked *