Ask HN: how do/would you teach programming?

At my company, because of the lack of OS X/iOS devs, we developed a while ago several training courses. We made different ones, web, cocoa, cocoa-touch and they all work. With prerequisites (none for web, object oriented programming for cocoa*), we can have devs ready in 2-3 week even if they never touch these techs before.

The secret is simple: Incremental Project-based training.

Create a set of 5-10 projects which all: 1/ put in direct action a theory point. 2/ take advantage of previous acquired knowledge. 3/ leave the student learn on his/her own.

GL.

I've always found that while creating a "hello world" app does show the very very basic idea of "type in code and see something happen" a better way is to get them started on the idea that they can actually create something.

I'm not sure about MATLAB but I do know there are some very basic and easy tutorials on how to make a Sudoku for example.

The best way to teach others anything is to get them excited about the subject, when they are, people tend to naturally invest more time and effort into learning more about it.

Hope it helps and good luck teaching!

From my own experience of learning to program, teaching and learning from others, something that I've seen to be very valuable is choosing any project, doesn't really matter what and just working on it. It doesn't have to be something new or sophisticated, just something big enough that you can immerse yourself into and build out over time. A project I worked on as a teenager was building a paint program (hardly innovative or new) but it was a big enough a task that I could work on for a while and on the way learn to incorporate other people's code, use books to deepen my knowledge, constantly add improvements and show my work to others. This was 15 years ago and I still remember so much about that program. I enjoyed building it and learned that I liked programming and from there began moving to more complex things. This may only be applicable in specific cases or for a younger audience, but I just wanted to share.

Projects, projects, projects. In my opinion people need to have successes to get going. "Hello Worlds" and theoretical stuff is useful of course (well, not just useful, you need that!), but I saw many people learning to code without actually solving problems. People, who knew how to do things but never had a real success other than some smaller homeworks. These people could never meet with problems they need to face when developing real applications (version managements, logging, or even getting answers from the Internet).

I would suggest the same as the others wrote before - teach some theory, create a few simple stuff with them, and let them learn :-)

Is this a semester long course? Since you're teaching computational biology it sounds like it'd be similar to the engineer introduction to programming with Matlab that I had to take my freshman year with no programming experience. It's probably going to run like this:

Tomorrow you'll be introducing how to get Matlab installed, and basically how to get running. No one did this before hand except for 2-3 kids. You'll do hello world, then make a helloworld.m file and half the class will be confused. If you can add 2 numbers, make a variable, and concatenate a string I think you'll be in good shape.

Remembering back to my intro engineering class, loops and specifically arrays are the hardest things to get in an intro programming class. It's "omg hard" level for them right now, even though Matlab does a bunch of the heavy lifting for you. While loops, for loops that increment by more than 1,and do-while loops are where they might struggle.

One of the most fun things we had to do for a project was using Matlab to manipulate audio files. Speed up, slow down, or make the tracks louder or softer. You can also do mixes using it. It's all array operations and then they can save the result to a file. I still have my quadruple speed mp3 on my computer from a 7 years ago.

For me the best is when something gets taught by writing simple programs. I don't like long abstract concepts, but rather keep it short and practical. I don't know Matlab, but lets say you're teaching 'C'. 1 - hello world 2 - program to add two hardcoded numbers, display result 3 - program to accept two numbers, and write out result (same as #2, only process 'argc'). 4 - program to write 'hello world' to file. 5 - program to read entire file into memory (hard-code buffer size to be big enough), and write it out to screen between '(' and ')'. 6 - something with a while loop, possibly reading any sized file, and printing it to screen line at a time, prefixed with line number 7 - for loop perhaps finding sum of all numbers between 1 and 100. 8 - some basic functions 9 - etc., one small step at a time.

That's what would work for me. People who are smart are going to pick up on what you're doing and get ahead. People who aren't so smart won't get too lost.

The last thing I would say, is not to assume audience knows anything. For example, I would stay away from writing a checkers game - there are different ways to play it, people will argue, some maybe never even played it. Chess would turn off some people right away. Keep problems simple.

Edit: local college, not logical college.

Hi. I volunteer at my local college as a Computer science Tutor.

Your teaching applied programming, so I would, unless it's a requirement, avoid most discussions of how things work, beyond the fact that the programming language is a way to write instructions that get the computer to do something.

I'd emphasize that loops, if/else, comparisons, boolean logic, arrays etc, are all composable, and you can build really complex things with them by combining them, just as you can build really complex equations by combining simple mathematical functions.

Then get them writing functions. I'd introduce them to a function the first day, and explain that code is broken up into functions, because they are composable, testable, reusable, and allow the writer to focus on getting a specific task correct.

Get them printing stuff the first day, and reading input in from a file, not just a keyboard. These are essential for any scientific work. I'd provide ways to read in files of different formats... I'm not sure what computational biology generally uses, but you might want a csv and a plain text file.

I'd then do if/else which lets you talk about boolean logic.

Teach them about nested if statements.

Then I'd move on to loops and arrays.

Teach loops tied to arrays. They are almost always used together anyway. Teach multi dimensional arrays as arrays of arrays, generally gone through with nested loops.

Post useful code for them to download and read, with comments on what each line does. Challenge them to modify it to do something different but related. Talk about how to debug code.

Talk about binary searches... I'd mention them first as a way to debug code, then introduce them later.

Show how to write function to find a minimum value in an array. Matlab probably has this, but show them it, because the fact that you initalize the comparison to first element and start comparing with the second, and not just initialize to 0 or something isn't obvious. I often see people have this issue.

show how to write a function to exchange values, if that requires a temporary variable in matlab.

show them how you can put those functions together and make a simple sort.

The truth is that for most actual things they will do while working, until they understand MatLab well enough to write their own stuff, they will be googling code and modifying it, so get them in the habit of reading code to understand what is going on, and modifying it.

Teach them to comment their code. Teach them to try to think about the steps involved before they code too much... try to get them writing down what they are going to do, and implementing it.

Oh and finally, have them write code, and then review it, or (easier for you) peer review it. Getting comments on code helps more then merely copying other's styles, because then they learn why you would do something.

Oh... New Programmers suck at estimating project completion time. I mean this, it's bad.

They will procrastinate, often unintentionally. Of course you can warn them, and give them lab time in class, but that may not be enough, so plan for what you will do about late assignments.

I know one teacher who always gave specific deadlines, and then moved them on the due date, just to get people to start working earlier. Even that wasn't entirely successful.

I'm teaching programming to an 8th grader now as part of an inner-city mentoring program sponsored by my employer. He seems to be picking it up pretty well, in my view the key is not to overcomplicate things. Pick a language with a REPL, teach them the substitution model, and show them how to teach a computer to do things.

I've taken a fair amount of inspiration from the SICP lectures by Sussman and Abelson. If you are planning on teaching people to program, they are worth a watch.