Ask HN: How to Teach Coding?

1. Tell them what to do but do not tell them how to do it. (Just give a few pointers otherwise they'll be lost.)

2. Give them a playground to fail - Offload any non-business critical tasks and let them make mistakes. No one I know ever learnt programming without making any mistakes. Immediately tell them about best practices and how to avoid such mistakes in future.

3. Show them the impact of their work - There's nothing more motivating than seeing the impact of one's work.

4. Build curiosity - Answer as many questions as you can answer. Admit when you don't know any answers and start looking it up on the web right in front of them. People pick habits by looking at their superiors.

If it's absolute beginning to programming, this video is a great way to show how difficult it is to teach a machine to do something and how clear instructions can help get things done: https://www.youtube.com/watch?v=cDA3_5982h8

Another suggestion: If they're a team member, treat them as such. When there's things to review, like a design document, include them as a reviewer, even if they're brand new and have no experience.

At my last long-term consulting arrangement, I helped hire and onboard a developer who was a new college grad (who'd had military work experience, but in a different STEM area). Because the team was growing, we needed some lightweight process tweaks, and I decided to involve him as a peer in determining those tweaks. (Secondarily, I didn't know what his military experience had been like, and this new role required him to be comfortable speaking up.) On a couple of occasions, it would've been easier for me, had I declared myself benevolent dictator on the decisions, but I think the peer treatment from the start worked out well for the process, and set a good cultural tone.

With regards to peer-programming, or code-reviews, I don't think I could comment. Personally I am a firm believer in test it, and see what works.

This is the main benefit of 1-1 teaching. In a class room setting you can, and perhaps should use "recommended techniques", but 1-1, just do what works for your mentee. Anything you read about benefits of peer-programming or code-reviews is just an idea, which you should be able to verify very quickly with your own student. This trumps everything you might read.

You might find one method works better all the time, or you might find one works better in some situations.

If I may elaborate: What I believe you are teaching your student, first and foremost, is the ability to observe themselves.

In fact, you may never need to "teach" them anything, if they begin to understand the difference between good and bad, better and worse, themselves, they are well on the route to becoming an autodidact. You do this through testing - not just formal tests, but simple questions too. Your aim is to develop the questioning ability in the student themselves.

I like to think of these analogies: A painter's ability to see is the foundation for their ability to paint. A chef's ability to taste is the foundation for their ability to cook. Both the eye and the palate can be trained.

It's possible that the state of education, documentation, and general programming know-how was so bad and fragmented before and so almost everyone had to rely on some self-learning.

Teach them using Scheme and some other language, but begin with Scheme.

* explain what a variable is and how to create and assign a value to it

* explain what a list is

* explain what a lambda is

* explain and show if else loops...

* explain what a closure is

* show them how to build a struct out of closures

* explain what a class is

* show them how to build a class out of a struct

* explain what an interface is

* explain what a module is and why it exists

* now show your trainee another programming language

* point out that the other language contains more or less the same building blocks as Scheme

* talk about how to format code

* explain a bit the command-line

* talk about basic patterns, like builder and singleton

* talk and show how some pieces of code could be written in different ways and why one solution might be "cleaner" than another

* read some code on the internet together

* do an excursion to databases (sqlite)

* point out what your trainee knows and where he could study topics by himself further

* show them some tools you like and some other popular tools

* talk about what kind of languages, frameworks different programming disciplines a.k.a. dev-stacks are being used today (this is important to get a rough overview, as beginner, you don't know what you don't know)

Don't:

* throw a million buzzwords at your trainee

* don't try to be neutral, be opinionated about the topics/technologies you teach and tell your students why you think/act in a certain way

* don't teach a topic by going through every point in existence (this approach takes long and is confusing as hell, because it mixes too much information targeted at different skill levels into one stream of unsorted information - doing this is a major failure)

* don't do math (math is a sub-field, it is not needed to understand how-to program)

* don't show off that you are smarter by throwing too complex problems or solutions at your students

* don't reach for the limit, a relaxed mind is capable of more