3 ms·

This post very eloquently expresses what I've believed for a long time as well. It really hurts me to see newbie programmers in first year classes going throu

This post very eloquently expresses what I've believed for a long time as well. It really hurts me to see newbie programmers in first year classes going through Java, writing getter and setter methods for a monster Object Oriented cash register or something. The code is spread across 40 different functions in 10 files, each function containing at most 5 or so lines of code. I'm sure it is a nice starter code for an amazing cash register application that can potentially scale to thousands of lines of code correctly, but it is not the way to teach programming. What a disaster. I've made my own set of tutorials in the past on programming (see the set at http://karpathy.ca/phyces/tutorial4.php http://karpathy.ca/phyces/tutorial4.php, though this set is for intermediate students who are already familiar with coding). I've always felt that coding should be taught in context of doing something concrete, not just by itself. Snippets of code without the whole don't mean anything. I also take a somewhat extreme view in that I think that game programming specifically is the best way to teach, because making games is engaging and students learn all the programming only as a by-product. Once they are comfortable with the basics, they should be introduced to progressively larger code bases, and at some point it becomes obvious why Object Oriented paradigms, for example, are a good idea. As a last point, I think Udacity recognizes this as well and shares a similar philosophy. Notice their first two classes: "How to build a Search Engine" and "How to build a Self-driving car", not "101: Computer Programming", with Chapters 1. Variables, 2. Control flow, etc.

ilovecomputers 15y ago
I tutored a friend who was in those OOP, Java, Intro to CS class. It was her second class of the series and she was so overwhelmed by all this stuff that was made for professional software engineers, that she just dropped that class. It wasn't mainly the courses fault that she left, she also forgot how to conjure up loops and how to use them, but knowing the professor she took last quarter (he likes to weed out people by making the class difficult) I can't really blame her for not having the enthusiasm to retain such information. I was in her shoes before, so I was very familiar with the "blank page" syndrom she was going through. This "sink and swim" teaching mentality has to go. It seems like from this thread and the article that we are getting a better idea of how people like to learn programming. Let us actually put effort into teaching this way.
- pullo 15y ago
  I agree. 'sink or swim' has been the technique of preference in academics for many years. I would think it it is the same for any discipline (electronics or chemical engineer). may be the fluid abstractions used in learning software make it much harder to train people?
scott_w 15y ago
I completely agree. When my friend and I were teaching ourselves how to develop software, we would write simple games. We went through a process of learning the basics of C, Python and Java by writing Scratchcard style games. It was simple enough conceptually, and it covered all the bases you needed. The summer before I started university, I wrote a text based version of Minesweeper in Java. It helped build up my knowledge and confidence in using Java to the point that I skipped all my programming lectures in first year, and breezed the exams. That did annoy a few people, who didn't see the work I had put in, and just assumed I had it easy.

ilovecomputers 15y ago

I tutored a friend who was in those OOP, Java, Intro to CS class. It was her second class of the series and she was so overwhelmed by all this stuff that was made for professional software engineers, that she just dropped that class. It wasn't mainly the courses fault that she left, she also forgot how to conjure up loops and how to use them, but knowing the professor she took last quarter (he likes to weed out people by making the class difficult) I can't really blame her for not having the enthusiasm to retain such information. I was in her shoes before, so I was very familiar with the "blank page" syndrom she was going through. This "sink and swim" teaching mentality has to go. It seems like from this thread and the article that we are getting a better idea of how people like to learn programming. Let us actually put effort into teaching this way.

pullo 15y ago
I agree. 'sink or swim' has been the technique of preference in academics for many years. I would think it it is the same for any discipline (electronics or chemical engineer). may be the fluid abstractions used in learning software make it much harder to train people?

scott_w 15y ago

I completely agree. When my friend and I were teaching ourselves how to develop software, we would write simple games. We went through a process of learning the basics of C, Python and Java by writing Scratchcard style games. It was simple enough conceptually, and it covered all the bases you needed. The summer before I started university, I wrote a text based version of Minesweeper in Java. It helped build up my knowledge and confidence in using Java to the point that I skipped all my programming lectures in first year, and breezed the exams. That did annoy a few people, who didn't see the work I had put in, and just assumed I had it easy.