Ask HN: How to Teach Coding?

[moveax]

I finally did it and I get my first Trainee.

I already teached coding to internships for a few weeks. But this time I have three years to share my knowledge and grow with him.

I already checked methods and stuff online like pair programming, visualization of data flows ect.

But what I would love to know is, what has worked for you guys on both sides. Sharing knowledge and get trained.

I want to be the best mentor I can be and I want to proof that this is a thing I can do good and continue doing it the next years of my career.

So, what helped you to train others or receiving knowledge?

[srirangr]

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

[jdeisenberg]

I have never liked the “make a sandwich” task. It sets people up for failure, because the teacher can always take things literally enough to make the student wrong. (For example, when given the instructions: "Take out two slices of bread", the teacher can rip open the side of the plastic bag rather than use the opening.) Some students end up with the feeling of “If I can’t even explain how to make a sandwich, how will I ever be able to tell a computer to do anything?”

Here’s an exercise (not sure where I discovered it) that I use at the community college level: https://www.youtube.com/watch?v=meSK1rn2VbA It has the same elements of analyzing a problem, breaking it into steps, and making sure they’re in the right order; but it’s set up for students to succeed.

This exercise is very effective when you put the students in groups of two or three to work on it.

[GlennS]

I actually think step (1) isn't a good way to start unless the pupil has some prior knowledge.

Many (most?) people don't have know how to take a big problem and turn it into something they can make progress on.

You give them the lego bricks and say 'make me a windmill' and they don't have the first clue where to start. They may not even understand that programming is lego.

So, you either have to teach that first. Or, if you want to teach it later, start with a sequence of problems that have one obvious step each.

Some good approaches to attacking a problem too big to be obvious:

1. Break it into smaller and smaller pieces, then implement those pieces.

2. Bite off a small piece that you think you can do, then grow that.

3. Write down everything about it then think very hard about what are the essential characteristics of a solution.

[stuntkite]

I was going to respond with a similar list. This is close and augments my philosophy well. Thanks!

I personally teach people to code with Python. Because it's easy to get into but can grow with someone where ever they want to go. It has a strong culture of clean code and DRY, and it is fully formed with a great community.

1. Start with Learn Python the Hard Way and do it until you are frustrated.

2. When frustrated with LPTHW, move to setting up a Django website. Do the Hello World of Django.

3. I work with the person to figure out something in their life that they'd like to make a web app of and help them do a simple website with basic Django models and bootstrap (so it looks good and like the familiar face of a finished product).

4. Work with them on simple deployment patterns and looping back into LPTHW to continue rudiments.

What I'm trying to teach here is that when you're staring at a wall of infinite unknown; set yourself up for success. Taking bites out of the elephant and learning to tolerate frustration / lack of knowledge by balancing with feeding yourself success. Always try to back learning of complicated things with a process of exploring something personally relevant to you and keep a sense of play.

I try to emphasize that the feeling of unknown that they are experiencing IS the state of being a programmer, the problems just change. The scale of what you can leverage grows. But at the end of the day, the unknown is what you're exploring and if you take to the process you'll learn to be excited about that. It will still always be scary, annoying, and sometimes really fun.

[mont]

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

I think even more importantly is to encourage failure, or at least reporting it. How many times have you been ecstatic that you managed to get a program to crash differently? A lot of people are terrified of failure, but people probably learn better from their mistakes. And showing them that it's ok (even encouraged) to report what their stuck on to you means that they can potentially get a quicker solution, learn from you.

[meuk]

"No one I know ever learnt programming without making any mistakes." True! In fact, I don't know anyone who programs without making any mistake.

[moveax]

That is indeed an awesome answer. I will follow that! Thank you.

[nickjj]

That is a funny yet really good video.

Reminds me of a blog post I wrote a few years ago on how breaking down problems is the most important skill you can ever learn as a developer.

I had a similar example where I talked about tying your shoes. What seems so trivial can easily end up being hundreds of steps without even delving into really low level details like controlling individual muscles of a specific part of your body.

[amrrs]

That's an amazing video Thanks for sharing. How do you suggest to show them the impact of their work - any suggestions?

[austincheney]

I try to get people to understand that coding is writing logic. That is actually two separate skills: writing and logic. Many people want programming to be something that it isn't, possibly something glorified by games or media. That said you can generally detect potentially great future programmers without talking about any code or coding experience.

When teaching people to write code I try to get them to practice thinking about writing instructions. Actually practicing their writing skills. The important part of that is that they struggle through the thinking process of finding a solution as a series of pieces and that they communicate that solution clearly.

What I want them to avoid is them thinking about programming as lego pieces they put together, because that becomes their expectation and reality. The problem with this is that when a person limits their expectation to putting things together and they move from education to employment they tend to be really good at configuring things and really bad at writing original code.

[btown]

1000% this. Just because LEGO pieces fit together doesn’t mean they take the form of a cohesive argument. It’s actually concerning to me that there is too much focus on practical coding skills in e.g. high school, to the detriment of essay-writing and critical thinking in non-technical domains. The “five paragraph essay” is actually fantastic preparation for “defensive coding” - if you can write good counterarguments, you can write error handling code.

[atemerev]

I teach coding. Here are some of my insights:

— Remove the instrumental barriers first. I start with teaching the basics of UNIX shell, navigating the file system, processes, editing files etc. Students will move much faster if they do not stumble on basics.

— Continue with the notion of system libraries, dependencies and teach how to use system package managers to install stuff.

— Explain what APIs are and teach how to call them manually for some useful results. E.g. use curl and Twilio API to make phone calls.

— Write simple scripts: call multiple API endpoints, use variables to store intermediate results, use simple loops. I hate bash, though, so any other language will do.

— The lowest-level API is machine code / CPU instructions. Write simple assembler code to calculate something, translate it to ASCII string (explain how symbols are encoded in ASCII and Unicode/UTF-8), and package it to the boot sector / boot it via QEMU.

— Move to C, learn about data types, arrays, pointers, etc. Use some fancy GUI library for additional immediate gratification.

[irchans]

Interestingly, I learned to program in a completely different way. When I started in 1979, the computer terminal where I learned could only run BASIC. There were no directories, just BASIC. We had one book that could teach you most of the commands, IF--THEN GOTO, SET, PRINT, FOR, NEXT, GOSUB. There was no WHILE statement. I think I spent months playing with those before learning about arrays. The biggest breakthrough was finding a Star Trek game in BASIC. I was amazed at what could be done with such simple commands. After a year or two, my father bought a TI 99 4A computer and I got a Commodore 64 about a year after that. You could write assembly code on the C64. I learned about ASCII file input and output in 1982. I don't remember learning about directories until I got to college in 1983. I don't think I used any libraries before 1986. (I did use punch cards in 1982). I think the first time I saw UNIX was 1990. I don't think I saw a package manager before the 1990's after I had been programming for over 10 years. The first time I did object oriented programming was about 1994 I think, C++. I got an MSCS in 1996.

[sevensor]

It's definitely good when you can make the time and space to build up all the concepts from scratch. In retrospect, I should have done this with my last trainee. Smart person, fast learner, but so many pieces were missing. The worst thing was being deeply hesitant to do anything at a command prompt. There's only so far you can get if everything you do is mediated by a GUI. If I had it to do over, I would have forbidden IDE use for the first month. I think it was deeply damaging.

[neilv]

There's the entire field of CS Education, besides all the initiatives outside of that. There are also off-the-shelf intro textbooks, such as: https://htdp.org/

If you have a trainee in a work context, where they're expected to soon be productive in the particular tools your company uses... get them started with those tools, point them to good instructional material, give them appropriate work assignments, and give them lots of mentoring (talk with them at beginning/milestones/end of each assignment, walk them through things they need to know that aren't in the materials, find the right balance of being available for questions but also getting them comfortable finding answers, etc.), and also get them started familiarizing with your organization's stuff and examples of good practices (e.g., reading select internal docs/code, monitoring Git commits, etc.). You'll also notice things they're doing or not doing, that you didn't think to mention before, so you can give tips as you see them. And it's important to be encouraging, not discouraging, even if you're encouraging them to work harder/smarter at something.

[neilv]

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.

[moveax]

Great link and feedback.

I will give that book a shot!

Git is something on my earlier Todo list, I just introduced the existence of git at first and think we will investigate there more soon.

[BossingAround]

To teach programming is to take on the following roles:

1) Information provider - search for suitable materials. For example, if the student finds the materials not engaging, it would be your role to find different material that suits the needs of the student better

2) Problem provider - this is extremely important. It is difficult, for example, to care about loops when all the textbooks show only that--loops in isolation. Your role is to construct or find problems that the student can solve with their new knowledge. Generally, the challenges/issues should be one level above the student's knowledge, so that it pushes them forward.

3) Guidance role - it is your job to analyze the students' motivation behind learning how to code, and provide suitable path. E.g. if one wants to become a web designer, it might not be the most suitable to start with assembler. You should also course correct, e.g. when you see a web designer to be struggling with data structures, it is absolutely appropriate to make a detour into some CS territory with data structure classes.

But, of course, most of the learning does the student him or herself. You can't teach anyone anything ever. You can just be there for the student, to help them and guide them.

My 2c as a self-taught developer.

[pfooti]

This is very good advice, especially number 2. Teaching programming, especially to a trainee, is a great opportunity for project-based learning approaches. Give your person problems and tasks that are difficult enough that they have to learn something to do it, but not so difficult that they'll just bounce off of it. Much of being a good teacher is learning to quickly calibrate tasks like this.

Provide help when they need it (critically, also teach them to recognize when they need help, most novices are pretty bad at this), but don't over support (if the student isn't reaching, they probably aren't learning).

Pair programming can also be a great tool in general for learning (with you playing the role of metacognition [1] for the trainee, which again is notoriously difficult for all novices - even experts in other fields have a hard time being metacognitive in new ones). The key there is again: don't prevent all of your trainee's mistakes as they happen, but try to guide them toward noticing them and repairing them before they get too stuck. The other part of teaching that's a learned skill is determining how much struggle / wheel-spinning is productive for your particular student.

All of this is with the caveat that YMMV - people learn best in different ways, but productive struggle and real tasks are really good starting points for most (and way better than lecturing).

[chiefalchemist]

Figure out something (meaningful?) they could build in that time frame, but make sure that project entails as many "basic concepts" as possible. Something where one concept / piece builds upon the next and there's a defined end goal that they can see / imagine.

No one wants to hear "Ok. Now delete that folder and let's start over on this other concept" especially when that new concept is likely using the old one, etc. That type of (online) training annoys me.

I would think there's got to be a good book(s) on basic CS / programming concepts. Get them that book, as something they can reference / explore when you're not available. Having a mentor is great but being self-sufficient (and having your self-esteem crushed) is also an important skill.

True story. In college my advanced calc (?) prof walked in on the first day and (more of less) said, "I'm not going to teach you. There's the book. I and TA's will be here to answer questions, etc." We (i.e., the students) left that class swearing up a storm. What's he getting paid for?!?!? etc.

Long to short, it was one of the best things that ever happened to me. Up until that point all my STEM learning was taught to me. I had never imagined I could read those bloated text books and teach myself. Let's just say that for the remainder of my college career my attendance rate for my STEM related classes was cut in half, sometimes even lower. I didn't need to go to class. I could teach myself.

It might a common HN trait, but I don't think it's true for a lot of people.

[faizshah]

There’s a lot of knowledge we take for granted when programming. A lot of problems in coding come from having an inadequate mental model, so I always try to explain how code runs on the machine as my first lesson.

I’ll give an example, to an experienced programmer you can look at code and tell what sequence the lines are going to run in and what sequence the expressions will probably be evaluated in. To a new programmer this isn’t obvious and they can make mistakes by making assumptions based on the code running at the same time and having an inaccurate view of the state at different points in a program.

I also think people dont emphasize how to find solutions to problems enough. Most time spent coding is spent trying to find someone else’s solution to something and figuring out how to apply it to your code. For example, a strategy like searching on google with site:news.ycombinator.com or site:github.com is not as obvious as you might think it is. Everyone has strategies for finding libraries, tutorials, and docs you should try to share them with students.

[cr0sh]

> to an experienced programmer you can look at code and tell what sequence the lines are going to run in

Unless the code/language is asynchronous - which requires a different mindset. And/or event driven - yet another mindset.

I've seen developers struggle with both; I know when I first learned event-driven programming (via Visual Basic 3 - yep, that long ago) - it was a different thing to think about, but it eventually became second nature. Windows 3.x cooperative multitasking helped to make it clear, too).

But yeah - they have to start somewhere, and sequential processing is the standard entry point, because most people understand cause-and-effect in the real world.

Technically, they also understand asynchronous and event-driven models, too - because both are real-world things as well - but they really don't think of them that way - or at least don't use those terms (if they think about them at all). Figuring out what terms they do use for those type of things might be key in teaching them such concepts...

[rafael859]

What prior knowledge does your student have?

In my experience, what helped me the most when starting to learn how to code was having a motivating problem that I wanted to solve. Why do I care what a for-loop is if I can't see how it is even helpful? Many tutorials have examples when teaching, but I believe that the problem should come first, and act as the glue between the basic ideas that will be introduced. Then, the mentor's most important role is to guide the student through best practices, such as style and performance.

[moveax]

His father is a coder too and he is making a specific IT school here. So he comes with basic knowledge about data structures, databases and how code is build.

Yeah, real world problems are what my favorite way to teach particular ways of building things. No one wants to build the 7th calculator.

Thanks for your Feedback!

[temp99990]

I’m in a well known bootcamp in SF right now (after flirting with idea for a few years and finally making the timing work). Having hit the half way point, I would say the day-to-day format has been very conducive to learning, at least for me.

Basic structure is: -nightly readings and videos on a new concept -a homework on the readings -a quiz on the material

Next day: -a half day lecture on the new material from the previous night. -a half day of paired project work on the material.

I think the reason why it’s a pretty effective format is because it forces you to struggle on your own the night (homework and quiz force you to do something and not just read along) before some new concept is taught, meaning you’re not going into a lecture completely cold. Then in the lecture you can solidify your understanding of the material, ask questions, follow along demos, and then really have things sink in with the longer, more difficult project work that same day.

[moveax]

I never experienced a coding camp (and i don't know if this is a thing here in Europe).

But that sounds reasonable and i just made a note about this for my plannings.

Thanks for your insights.

[gorpomon]

Three years is a long time. I've taught bootcamps where I had to do it in 4, 6 or 12 weeks. Three years is luxurious.

Here are my initial thoughts:

- For a timeframe this long it's less "let me teach you" but more "let me guide you in your own learning." If you view this as only imparting knowledge I think you will burn yourself out.

- I would help them formulate a curriculum, keep them on track and make them push themselves. Anyone can learn a lot in three years, but with your guidance they hopefully learn 2x, 3x, 5x or even 10x what they would have learned alone. Ask yourself this every time you check in with them "How can I speed them up? What can I teach them now that will save them time?"

- I would periodically check in and asses what's been learned and what's left to learn. I would also reassess if the curriculum is working or needs tweaking. I would be open to changing things up periodically. Maybe one year is project based work, maybe another focuses on reading classic texts. Three years is a long time to do one thing.

This sounds really fun, good luck and have fun!

[oysterfish]

Don't teach coding. I haven't come across a discipline yet where:

1/ there's such an astronomical disparity between students 2/ where it's more of a requirement to be an autodidact.

All the good devs i know just pick up books and start reading. If you look professional devs out there, if they all taught themselves how to code, then one must wonder whether you can even produce a good coder by teaching them directly.

Instead, pointing them in the right direction on their learning path at the right time is probably going to be hugely beneficial.

I know for myself i wish i'd spent more time learning than building things. It's been useful too building, however my ratio was off by quite a bit.

[traderjane]

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.

[xenocratus]

That's very true, at least in my experience - best devs seem to be the ones who can find their way quite easily without supervision.

BUT not all people like or are comfortable with that. For example, if you've started learning programming in a rough environment, I imagine it could feel difficult or even scary. So making them feel more secure through pair programming or something of the sorts could help them ease that out.

Plus there's the benefit of efficiency - sure, they might need to learn Java or C or Python by themselves (which you could state to them), but learning to navigate through the internals of a large codebase can be quite challenging and not necessarily useful right away. Sure, you might need to face the more hairy bits of the repo at some point, but figuring everything out right off is probably not ideal - or, not always.

And another issue is process - different companies (even different teams within the same company) have different processes - e.g. pick up ticket, read description and possibly discuss with lead/QA about what the acceptance criteria is, write code, open PR, get reviews, get QA review, check code coverage and static analysis.... you get the idea

[Vanderson]

I also just had my first intern. But I also taught at the college level and have had a few employees. A few suggestions to add to the already good lists here.

1. Tell them _why_ you do something.

This helps with cognitive load while learning, and helps them overcome some mental stress when investing in new techniques/methods.

2. Provide real code examples that work, and demonstrate them.

This is analogous to hearing a song played when learning to play a musical instrument. It's really hard to convert notes to music without knowing how it is supposed to sound first.

3. Be patient and ready to describe things from multiple angles.

I noticed I was more patient with people I have little time with. The more time you spend with someone the harder this gets. So be prepared for this.

4. You are likely to be wrong, be ready to learn yourself.

Every class I taught something slightly off, or made a mistake, or simply a student had learned some obscure thing from the internet that I had not learned myself. I learned alot by teaching others, but also by screwing up in front of an entire class. Be humble, expect to be wrong from day one, and be grateful when you are taught something new from anyone from any skill level.

Note: knowledge is easily attained these days, understanding why you use one thing and not another is not as easily learned. When an old experienced codger on the internet say to do something a certain way, take it really seriously and study why, then you can pass this on as well.

[moveax]

Nice additions.

I am self-tought and i made the experience that being wrong helped me to evolve. I guess i grinded the gears of many people in bulletin boards or irc channels in the moment i came by with my naive solutions.

But getting corrections and new insights helped me to grow. This is something i want to transfer to my trainee aswell.

I'm thankful for your thoughts :)

[Razengan]

In addition to the other suggestions here:

Ask the student what they want to build or achieve.

Like if they want to make a game, or an app, then sit with them to code the simplest form of that, step by step, starting with the player data model (score/HP/ammo), then the HUD, and so on.

You may even write the first version all by yourself while they watch, accompanied by your live commentary.

Let them know that development is generally about sending messages/commands to things (APIs) that send messages to other things (CPU/GPU) on your behalf, so they can understand early on that coding is as much about SDKs and frameworks as it's about languages and platforms, and the ways of talking to/between them changes across APIs, so one of the most important skills is learning how to learn; to figure out how to dig through all the different ways of achieving the same result.

Tell them they can generally make things easier by putting in more intermediary messengers between themselves and the screen: Dev » Unity/Unreal/SpriteKit » C#/Swift » DirectX/OpenGL/Metal » iOS/macOS/Windows » App Store/Steam » Player

and they generally get more control by removing the middlemen, but if they change a layer in the chain they might need to relearn how to talk to all of them.

[chrisweekly]

Code reviews and more code reviews. In both directions. Walk him/her through your stuff, explaining "why" as much as "what" and "how". Also, give your trainee a small coding task (ideally, one both simple and also similar to something you've walked them through). Review their stuff together, line by line, providing feedback as you go. Strive for some small wins they can build on to generate confidence. If there's an opportunity to refactor, that can be very instructive too. Also, take the time to sit w/ them and ensure their dev env is in good shape so the tools don't get in the way. Linters and the like can provide solid guardrails. Also, provide guidance on how to look things up (e.g. "mdn" search prefix, and bookmarks for your preferred reference materials). Finally, since your novice developer as yet has no bad habits to unlearn, strive for best practices in everything you do together (eg TDD; in fact starting w/ tests might be the best 1st step after the dev env is set up). /$.02

[lelabo_42]

First, I noticed that I had much more impact teaching things I had done recently (even if I know the theory). So when you create your exercises, try to solve them in order to 1. check the difficulty and 2. know where your students will strugle, what are the main pitfalls you will have to explain them or give them more hints.

Second, a session should be composed of a few exercises with immediate feedbacks / rewards (something quick to code but with enough notion to understand the subject of the day). Then build the momentum toward more complex exercises. The last exercises should be a bit more advanced than the current expected level of your students.

When I was a student, I had this structure were we had a between 6-10 exercises to learn C in 30 days (even if we did not understand all of it under the hood) from nothing to pointers, circular list, object-oriented (with structure) C. I found out that even if most of the students struggle, some of them will try to solve all of the exercises. After many days, they had made tremendous progress and were capable to achieve all of them most of the days.

These students boosted the rest of the class for the next few years as we were encouraged to share knowledge and teach each other.

[amerkhalid]

I have mentored many junior developers through my career. And recently, started to train junior developers as a side gig. (Had been helping friends to get up to speed in their new jobs but wasn't charging anything for it.)

So these are the developers who already have basics of programming but they usually don't understand whole ecosystem around it. For example, many don't understand version control, server vs local env, etc. Normally, many senior developers get really frustrated when junior devs ask them about such basic concepts. I used to be like that too, however, I learned to be patient and tried my best to help them. And some of my teammates started to ask me if I can help their friends in other teams/companies.

So this is what I have learned about mentoring:

* Encouragement - Unfortunately, tech world if full of genius jerks. Many junior developers get discouraged by such behavior. A lot of time I find myself convincing them that they will catch up to senior devs eventually. Sometimes, I feel like I am teaching them how to manage their senior developers/managers instead of teaching them technical topics.

* Find out what their objectives are - Another big issue is that many developers have big egos and they would try to hide their ignorance by asking very specific question. If it's a senior developer, I would just answer the question. However, if it is a junior developer, I usually ask them what their end goal is and many times they are going down the wrong path.

* Let them ask you questions and then use search engines to find answer together, even if you know the answer.

* Code Reviews are great but you have to be sensitive towards junior developers. I usually make a small comment in CR and then meet with the developer to explain it further and to make sure they understand the reasoning completely. For example, many developers from non-English speaking countries have hard time understanding difference between verbs and nouns, and they name variables and methods which are hard to decipher. It is hard to explain that in CR but in-person much easier. Also English is not my native tongue so I also get criticised for my namings too still. So I can understand it can be hard to come up with a good variable name for non-native English speakers.

* Help them find good training material. You cannot spend hours training junior developers, so make a list of good resources to learn from and ask developers to review them. These cannot be 40 hour course, but something more narrowly focused on their current problem.

[din-9]

Understanding that we all have different mental models, and that affects how we learn. Understanding my own vs my students' helped me to get them to understand what I was trying to communicate.

[tech2]

This in particular is massive. Some people like (and work well) pair programming, others want reading materials, others yet need videos.

Just being there to answer questions or help when they have issues can be a tremendous assist since it means they're rarely left frustrated by being unable to move forward on their own.

[adrianmonk]

Logic was an important piece of the puzzle for me when I was learning. When I started my CS degree, I didn't have this, and some of the courses were extremely helpful in building it.

If you are a very math-oriented person, you might expect that people already know this. But it's not true. We are not born with innate knowledge of it.

I'm talking about stuff like basic propositional logic, maybe a little first-order logic, definitely some boolean algebra, and maybe some Hoare logic.

You might not have to or want to get too formal or hardcore with it, but it really helps to at least have some basic grounding in the subject.

Before I had that grounding, I would spend a lot of effort trying to get code working, but it was often a jumble that I couldn't sort out. The conditions in my if statements were a mess. My loops wouldn't terminate, or I couldn't figure out how to write them.

[ChrisBland]

Each person is different, honestly have a sit down with your trainee and ask how they have been successful in the past learning new skills. Some people like to read theory and understand it fully before ever putting pen to paper, others like to try and error out. If you put the wrong method in front of the person, neither of you will enjoy it.

[jerome-jh]

Remembering the very first course I received at 9 y.o. (logo with turtle) the pleasure came from seeing the actual output of the program on the screen: a drawing. Remembering my first C course at 20, whose program was a one liner designed on purpose for us to understand nothing: don't be afraid to tell "I cannot explain you that now" (e.g. why #include). Today if I had to choose a language/platform to teach coding, that would be the Arduino. Simple system, visible output, simple language although perfectly well formed C++.

[jerome-jh]

Going on with my Arduino idea: when they have enough of C you can do some assembly. You can teach interrupt handling, the source of all concurrency on a single core, in C or asm. You can do communication on an unreliable link (2 boards & LEDs), sensor conditioning. A wheeled robot may help some students "seeing the world from the computer eyes", although they may be a bit too old for that.

Of course data structures are best taught in C on a desktop. Functional programming is certainly interesting but further apart from how a modern computer works.

During my studies I even did opcode programming on antic 8085 dev boards, with a 20 keys keyboard (hex digits, reset, run, memory up/down). You can't imagine how much fun that was, akin to woodworking or pottery. That certainly grounded a number of ideas on programming, that may look otherwise mystic to students.