

Ask HN: how do/would you teach programming? - jamesjporter

We see a lot on HN about teaching yourself to program. What about teaching others? I'm TAing an introductory computational biology couse at my University, and tomorrow I'll be teaching a group of students, many of whom have never programmed before, the basics (MATLAB specifically). Its been a few years since I was in their shoes and its difficult to put yourself in the mindset of the very beginner. I'm sure others here encounter this problem, even if its just trying to explain basic programming concepts to coworkers, family, or friends. So HN, what advice do you have for teaching / explaining programming to complete neophytes?
======
lsiebert
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.

------
ragatskynet
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 :-)

------
caw
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.

------
anywherenotes
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.

------
lsiebert
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.

------
buddym
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.

------
Marske
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!

------
athiercelin
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.

------
zenbowman
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.

