Ask HN: How to Teach Coding? | Hacker News Reader

Ask HN: How to Teach Coding?

322 pointsmoveax121 comments

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?

View on HN

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

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.

Sounds like this make a sandwich exercise is rather good for understanding the issues with gathering software requirements; it confronts the students with creeping requirements, before they even know how to code.

Coding should probably be taught with a background of requirements that are precisely given in terms of the abstractions that are being used in the code. So that is to say, the problem itself doesn't have to be something abstract (like a number-theoretic computation); it can be connected to something in the real world. But the representational mapping from that domain to the computer should be established by the teacher, so there is no irrelevant fumbling about the requirements.

In the case of the sandwich, we should provide a procedure which somehow takes the slices of bread out of the bag. Similarly, we provide all other necessary procedures, and only those procedures are to be used. Then we eliminate questions about the detailed requirements about what those procedures themselves do, like can the bag be ripped, or does the removal have to be tidy.

A good domain for teaching coding might be game playing (cards, etc). People understand that the objects used in games are abstract, and that certain details do not matter to the game, like the exact shape of a rook in chess or its precise placement within a square. It could just be the letter "R" in an 8x8 grid of characters (with "r" being the opposite color).

Symbolic games are basically a form of mathematics that is instantiated in the real world whose abstractions people readily understand. Moreover, they have a point (to have fun), so the "why are we doing this" question is settled.

That video was super-helpful. I believe he is a CS instructor, and his methods are easy to explain and understand, unlike a lot of class that just rush the students into learning bunch of technology before really learning how to think like a programmer.

Also there's his follow up video where he solves the puzzle (https://www.youtube.com/watch?v=z5VKyKvgyRs). Another helpful video is him teaching how to go through a program by hand, using pen and paper (https://www.youtube.com/watch?v=9Ahejeuasf0)

The whole point of the exercise is for the teacher to do it in an unexpected manner. The exercise is about established structures and constraints, isn't it?

The point being "I can't even tell someone how to make a sandwich without establishing the platform we're building on". If you start a python app writing in assembly or Fortran then (in general, you pedants!) it's not going to work.

If you do the same exercise with cooperative people then you don't normally emphasise the point because they do a lot that's not clearly defined, and that hides the point about defining the parameters and metrics you're working with.

Thank you for sharing this video. It can be more helpful for novices than the flat-out adversarial approach of "I'm going to mess this sandwich at every possible step to show you that you need to be precise".

I've found that learners will succeed when they are able to answer affirmatively these two questions: "can I do this?" (self-efficacy), and "do I want to?" (motivation).

The robot scenario with a handful of commands is preferable compared to the "make me a sandwich" task in both respects, because failing badly at even getting bread out of the bag (say) can destroy both self-efficacy and motivation.

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.

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.

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

I have to second this comment. I think it is also important to stress the activities after the failure is also important. ie reporting it at earliest, proactive in helping to contain its impact, conducting a lesson learn etc.

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

I know Chuck Norris

Chuck Norris doesn't program. He stares at the computer till it does what he wants.

Of course that's programming, it's Telepathic Declarative Programming. And I suspect that with the rapid improvements in neural interfaces[0], we'll all be utilizing this before long.

[0] https://www.nytimes.com/2019/04/24/health/artificial-speech-...

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

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.

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

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.

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.

Another good writing task for programming is to write down a recipe (properly). However, to do it off-the-cuff would mean you need to know how to cook - so maybe not the best example.

Something that could be done is describing the task of making coffee, or a sandwich, or describing your entire morning routine.

Focus on teaching the details - let the students try it first without any prompting other than telling them to try it. Then select one at random and go over it showing where certain details are missing.

For instance, they might say "I brush my teeth, then I get in the shower" - but what they really did was "brush my teeth, turn on shower, wait for a particular temp, until that temp continue brushing teeth, when temp is reached, stop brushing and get into shower".

Of course, even that isn't detailed enough (do they still have their clothes on? maybe those should be removed before getting into the shower?) - but it would show how you have to think in such extreme detail for programming, plus the whole "control logic" and "logic flow" of such a description.

Recipes are like this too, but knowing how to properly write one does require cooking knowledge, which many people don't have. But everyone (usually) has the experience of "getting ready for work" or something similar...

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.

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.

I learned how to program BASIC in the early 80s from magazines, when program source code was printed out and you had to type it into your computer verbatim. At some point, you switch from being a typing drone to trying to understand what you were typing.

The worst part was when there were bugs in the printed source code. If you didn't know how to fix it, you had to wait until the errata showed up in a future issue of the magazine.

Similarly enough I went from BASIC to Pascal to C. Actually I tried to go from BASIC to C, but that was a bridge too far due to my lack of visceral appreciation for structure. At that time, Turbo Pascal was a god-send as a development environment - crazy fast, decent editor and library all in one tiny thing. In some sense, I owe any advancement in CS to that tool.

So did I, but we live in 2019 now. The optimal path for productive coding looks different these days.

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.

Yes, that’s what I do — forbid the use of IDEs (they only become indispensable for large projects, and we don’t do anything large-scale yet).

This is an excellent gamified CTF to learn the ins and outs of UNIX command line: http://overthewire.org/wargames/bandit/ . I usually require my students to reach at least level 10 to pass, and everybody liked it so far.

Nice, i got hooked up the same second i started and needed to force me stopping.

Good Link.

That looks fun! I'll run through it myself and see what it covers.

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.

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.

This is a good idea, we have to build so much swim-lane-diagrams, why not including him.

He only can learn from this.

Thank you for your feedback

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.

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.

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

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.

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.

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

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.

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!

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.

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.

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!

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.

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.

it is still fragmented. you can't point to a definitive source for "how to be [x] developer". you can just give them a roadmap at best.

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

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.

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

I would also add that it's important to learn that what you are teaching now may be considered an anti-pattern down the road. Or that the framework de jour is going to become tech debt in 5 years.

So it's really important to distinguish between long term viable fundamental skills/techniques from current best practices.

A specific example of this is I started using javascript a lot, then Prototype.js then jQuery came out (which did not litter the core objects with protoype inheritances, which is better...) and now back to vanilla js now that the browser incompatibilities are minimal. The only long term viable skill here is coding in general, and vanilla js, everything else was a fad of sorts.

Have fun teaching, I really enjoy this part of my work.

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.

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

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.

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.

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.

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.

Wow, thank you two. That's something i experienced before with my internships. One learned better while solving some atomized questions and the other one learned better in live coding sessions.

I am glad that i will start with only one Person here and i can focus on how he learns :)

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.

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.

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

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.

If I could teach my younger self:

1. Stop theorizing.

2. Write lots of software.

3. Learn from your mistakes.

https://blog.codinghorror.com/quantity-always-trumps-quality...

Success comes when there is nothing left to learn from failure. Fail faster to learn this sooner.

I would only agree with the caveat that someone experienced should read your code, comment on it and improve on it.

I spent years slowly learning how to be a better developer, on my own. If someone had been there early on to tell me: "this is bad because X", I would have progressed twice as fast.

Programming at its core is very easy, building maintainable software is much harder. Knowing what to avoid only comes with experience, but much of that experience can be quickly transferred to you from someone who already has it.

I have seen classes full of disinterested kids learn by:

1. reading algorithm flows 2. following changes in variables for C code 3. drawing their own algorithms 4. implementing those in C.

repeat for a whole semester.

in the end, those who are really interested will pick up tooling and go ahead by themselves.

I am lucky that he already have those coding basics and wants to learn. And i experienced in his intership that he came back the other day and said "i tried this at home, how could i do this better" and was all open for suggestions ect

Long time ago at uni I used to give paid coding sessions to fellow students from IT facoulty (I myself could not make it to study on IT as I was not super star in math/physics which is requirement where I live, but I was passionate about coding and self thought and playing with code since 13). They was coming to me with their assignments in various levels of advancement so we was going through whatever they already had, salvaged whatever made sense and explained why other parts was of no use. Then we completed assignment together with proper explanation where things come from. I often heard this: 'you just start writing' and my answer would often be 'data structure is the fundation, I want to test different ideas so I can land at the best of my ability as soon as I can'... This was nice time in my life where I had no clue about maintainability and quality of code :)

On another note I remember watching video on youtube where someone said that for them programming is solving a puzzle. This resonates with me as solving puzzles is something you enjoy, programming should be something you enjoy and not just use to make your living...

Teaching is about learning together. Once you start teaching it opens up a whole other dimensions, where you look at problems from the other persons perspective, and you really need to have in depths knowledge in order to explain something simply. So don't think of it in terms of you teaching him, it's more like him teaching you how to become a better developer.

Awesome, I already thought about that this will be a task I can learn a lot from too.

Thanks for your answer

I completed the MIT and Harvard introduction to computation courses on EDX. I did it for fun, but both turned out to be truly inspiring on the subject on how to teach CS.

It depends on what you’re teaching though. If it’s bringing a new hire up to speed what works best for us is to give them access to a portfolio of how we do things and let them hack away at a problem on their own. If they have questions we help, and their mentor makes sure they aren’t stuck and afraid to ask.

The sad fact is that 95% of our learning curve is figuring out how the damn toolset is used, and it only 5% of what’s hard is actually programming. I’m sure it’s different if you’re a PhD at google, but in our shop we rarely invent new CS concepts, so it’s mostly about learning how to make tools work. We’ll get people who know JavaScript and .Net who have no idea how to deploy it on our IIS servers, or how to setup the config file so only a specific AD group has access to a specific API, stuff like that. I’m not sure where it all went wrong, but it did.

sounds like you have a lot of programmers and little system engineers / 'devops' engineers. in my opinion it's a different kind of person who can fight environmental details into working with some programs (i.e setting up some environment / server and getting everything tested / deployed) than a person who can write the thing being deployed. Generally i think both have very different information to their disposal. Someone who makes a life out of tying things together, will know a lot of these 'things' he ties together, like ldap/ad,dns,okta,random_api_xxx,etc. where a programmer might know just as much sorting algorithm as and methods to make efficient linked data structures as this other person knows different apis and python modules...

What good is a developer who can’t deliver outside of a debugging/development environment?

I mean, I get what you are saying, but who can afford people who are that specialised?

A lot of places. The role of "devops" not withstanding, develment vs operations is one of the first distinctions to specialize in.

Yes!

I've found the most valuable thing is often good, uncluttered examples. Docs are often focused entirely on the API's but don't have enough to show you how to use them, and Google/SO can be a rabbit hole of examples that are overcomplicated or misleading.

"Try something like this" (with comments) goes a long way.

So much of being a beginner is not having been exposed to patterns and techniques. They need to fill our their toolbox, and in doing that, make sure to walk through what the code does and why, since nobody benefits from cargo-culting.

Let's see, also...

1. Teach interactive shell and debugging early. It's life changing.

2. Make sure to assign them entire projects. The fastest way to burn out a beginner is give them a series of small tasks in code they don't really understand.

3. Chill out on code review. Limit yourself to a few suggestions for each PR. If you offer two suggestions and rationale, they might say "aha, that makes sense" and remember that. If you offer 15, nothing will stick.

Wow, thanks for your answer.

Point 3 is something I haven't thought of yet. During reviews I pointed on some issues, not every. But that was never something I had a specific reason for, I was just focused on what we want to learn in this lesson.

I will keep that even more in mind now.

1. Know your skill tree and teach using it.

2. Start small.

3. Allow plenty of mistakes.

4. Resist the temptation of always showing a better way, best practices, or rewriting the trainee code.

5. If you use magic, explain it without magic first.

6. Setup tooling yourself, even on the trainee's machine. No time to waste with that. This must include a good IDE, with a good linter.

7. Auto format all code, no time to waste on style linting and formatting advises.

8. Git is hard. Don't forget to explain it again and again in details, dev is just not code.

9. Testing is hard for the beginners. Write the tests for a while. Nobody can learn it all at once. Forget TDD for 2 years, this requires a lot of experiences.

10. Force regular feedback. They won't come to you. Don't ask what's wrong. Go to see. And be nice.

I taught a Python course to people with humanities and non-technical backgrounds. The thing that helped me was to understand what was going on in their heads when I said things like 'array' or 'datastructure'.

Those of us that have written a lot of code take these mental structures for granted; we easily manipulate them in our minds to discuss things. People that are new at this will literally have no mental model for concepts embedded in datastructures and algorithms.

Every subject has to get around this; I struggled with this when trying to move from single variable functions to vector valued functions. The most annoying thing as a student is having an instructor talk at you and not to you.

The lessons should be straight forward tutorials that builds something relatively functional. This builds practical knowledge of capabilities and motivation. Then you teach theory to some of the basics as the practical knowledge grows. Then more complicated abstract theory as they progress.

As a teacher, you minimize roadblock time. Not eliminate, minimize. Let a student flop around like a fish to debug for a while and before they suffocate, you point out the problem. Also, answer questions or provide different strategies with their pros and cons.

If I can teach a crayon munching marine to dev this way, I’m pretty sure 99% of the human population that wants to dev can learn that way too.

Constant practice and small achievable goals definitely help.

If you don't keep practicing, you'll never see the value in what you're learning and you'll quickly get fed up. Additionally you'll start encountering road blocks during your practice and you'll start becoming eager to learn if there's a better way to do things.

Small goals make learning more enjoyable. If you set out to make a MMO online 3D game from the start, you'll never do it. But if you make yourself a to-do list app, word/numbers/guessing games, a note-taking app, you'll enjoy these small wins and more importantly will be eager to improve them.

A great strategy in teaching a subject is connecting it with something the pupil already knows and finds interesting. This reference or association makes it meaningful and can motivate them to learn more by themselves.

You can show them what of a superpower programming really is, now they can sense, process and affect things that are normally out of their reach. Let them create a thousand files, read an API, create a bot, crash the system and blink an LED.

They can automate many processes and solve new technical problems or create something entertaining. Maybe a new small website. Or a mod for their favorite game.

Teaching Tech Together[1] is an incredible resource for learning how to structure lessons in a way that makes ideas stick. Highly recommend.

Commoncog has a nice general overview [2].

[1]: http://teachtogether.tech/en/ [2]: https://commoncog.com/blog/teaching-tech-together/

There's a lot of great advice here, so I'll just add one more thing. Don't let them get too caught up on tools and "setups". Sometimes beginners will expend hours just tuning their IDE. Use something like repl or just any text editor. At our bootcamp, we created our own platform to host Jupyter Notebooks, the improvement has been huge: https://notebooks.ai

Don't teach them coding, teach them how to build things with code. I do this daily for a living (https://cleverbeagle.com).

The speed at which I see people pick up concepts is much faster when focused on writing code to implement an idea they have. "I want to build a real-time feed like Twitter" is a lot more concrete than "I want to learn websockets."

Real teaching is exploring, discovering, inspiring, reminding and pointing in the right direction. Not so much imposing a ready-made system of thought on others. It takes experience, and discipline to get to the point where this is possible without egos crashing the party one way or the other.

Someone said that finding good teachers is difficult, and that's true from my experience; but it 's a Sunday walk in the park compared to finding good students.

True, he have to learn himself. But giving that directions and insights is something that makes me happy.

Well after reading your message, i just hope to stick in the "good teacher" category soon.

My feelings say i found a good student who wants to learn, so i have a rock solid base here.

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

Start with thinking about what it actually is you aim to teach. Are you trying to teach someone the ability to work on a web application in a particular language, or are you trying to teach them how computers work so they can work on anything in any language?

Once you've identified your goal you can work backwords from there to what your trainee already knows.

Coding is largely a ruminative effort. The process itself is difficult to transfer directly, it's mostly mapped through communication.

Encourage their effort and guide them on their own learning path.

Learning is a two way street. For every concept that is new to them that they bring to you, discuss it with them and find something new for you to learn.

Teaching is one of the best ways to learn.

Although there is a significant number of Negative Nancies here I believe it can be teached but, even though I know it won't be a popular outlook, I see it like learning/teaching blacksmithy. Sure there is a theory, like which metal to choose, which degree to cook and which hammer to build but theory gets you so far. You need to show how a sword is actually done.

The concepts of programming can be learned from the noosphere easily, the resources are there to learn but good practices are not. A teacher should pass these as well, in addition to "what is a variable" etc. stuff. And like any course, if the student doesn't actually work on the stuff on his free time it is worthless - another analogy can be a guitar course here. No matter who your teacher is, if you don't play it at home willingly... you won't be able to learn how to play guitar.

My 2 cents...

Critically, think about what actually worked for you in your learning. And help your trainee have the same experiences.

I have found that many new teachers to get things across by sharing insights they had only after they understood a subject. But that high level understanding is the result not the cause of mastery.

Try and constantly keep track of where the edge is of their comfort zone, and suggest adequate steps away from it in terms of work to be done.

Help them grow by venturing into unknown terrain when the time is right, show them the path when they are lost. Give feedback when work is done to help them stay on the path.

This is my advice for someone who didn't success as a software engineering major in University but ended up making a career out of it anyways.

Focus more on the concepts and less on the syntax. Have the student make up their own syntax for the concepts. That will verify they know the concept.

I am of the opinion that you don't teach anything, it's the person that learns something.

So, I'd go for what others have already mentioned. Learn about the person, how they are, how they learn better, what are their interests.

Find something they like and enjoy, so they are motivated in learning.

Be ready and available to answer questions and adapt to their rhythm and needs.

Prepare materials and different options so they can chose their path as they go.

Facilitate them changing their mind, going back and forth, making their own mistakes.

In my case, for example, I learn by doing, and pair programing with somebody helps me a lot, but other people might prefer having a theoretical background first and will want to read a book before diving into coding.

EDIT: adding paragraphs for clarity

It depends. What is the situation? You've mentioned internships so I am guessing it is business? What is the end goal?

I am far from a programmer but what I have learned has been through exploration. Here's a web page. how can I make a userscript to get rid of that nag screen? (I know I can use a popup blocker or something but I'm trying to learn) I want to make a little browser addon. let me find one that does something similar and look at the code. Search for the particular problem and find answers.

From the comments below it sounds like this person is farther along than that (probably farther along than me) but I think learning how to find answers is one of the best life skills.

Well, he has the basics like data control structures, database usage, a little bit OOP. I think the missing link is how to build real world processes with it.

I'm sure we will find basics that are missing and will have to fill that with knowledge, but we have a good starting point.

By what you said above, don't underestimate yourself there. Building scripts that touch real things to make it better working for you (and others) is a great step on the journey to write good code! Thanks for your feedback :)

I'll refer to the talk [0] from last congress about the german sibling of the high-school version of MIT's How to Design Programms [1]. It's about teaching a functional-first style of abstraction with a _very_ rigorous structured approach to writing the design. I wish I'd started with HtDP instead of Pascal/Delphi (later Java), but it's the best approach I see if one wants to quickly be able to start a project of non-trivial complexity without it ending in a horror show of technical debt and/or frustrating bugs one doesn't even know how to analyze/tackle. If a slightly above average (1-2 sigma IQ, aka 120+-10) 6th grader isn't scared of the complexity, it should be possible to rely on the urge of curiosity to get said child to continue being teached by oneself. While I applaud the use of Racket for this teaching, it unfortunately scares off many who believe that companies prefer code-monkeys who can hack stuff together within Python's ecosystem. I know that, with some connections, it's easy to start with these functional skills in a company that has tasks that are suited for this approach, as well as senior engineers with some functional skills (enough to grasp what the new hire created). A good manager can let someone with no industry experience work on a well-defined component that takes 1~3 weeks to design and implement, with next to no micro-management. It only works though if the new hire is skilled in designing software, which HtDP has as it's main goal (it's even in the title). I'd hire a newbie self-taught with HtDP after testing stochastically to verify that he/she actually worked and understood all of it with just one 1~4 day in-office real-world task to test if the learned things compose into actual wholesome software design skills. I'd not like one who learned Python on his/her own and now has 1.5 years full-time experience designing&coding Python. Not without some specific testing to judge the quality of their design skills, which btw. is a far harder test than randomly sampling concepts of HtDP with short excercises similar to those in the book itself, followed by the mentioned few-day practice test. HtDP gives me the confidence to assume these few-day results scale to projects that take months, after just about .5~1 year of experience with projects that take a few days to weeks each.

[0] https://media.ccc.de/v/35c3-9800-how_to_teach_programming_to... [1] https://htdp.org

The best trainees I had were the ones who trusted me.

Sometimes it is hard to make a point about counter-intuitive procedures, like writing tests and assembling tests datasets, or setup logging, or ensure that dev tools are properly setup, before jumping into the code. It requires a leap of faith.

I had the best results when they were willing to take this leap of faith, so my suggestion would be to start by building trust.

As a trainee, I was willing to trust my mentor only when he showed effort in trying to understand my strengths and my limits. It never worked if they did not sat down with me with a "let's talk".

How much experience does your PFY (trainee) have ? and are they doing an Aprentiship?

Yeah, it is a 3 years apprenticeship.

He already has some knowledge because he visited an IT focused school here in Germany and his father is a coder too.

So I don't need to explain loops, or if statements and can go a bit further in logic and processes

People have good answers, here is my 2 cent opinion. (1) Accept that not everyone can be good at programming (as many other things). (2) Do your best. Also learn what not works for what type of people.

We need people like you. All the best!

I'm not able to answer all your comments right now. But i want to let you know, that i read all of them and i love your feedback.

Up to this moment i learned that going with real world examples is the way to go. Since i work in a software department of a real world company and mainly code Inhouse solutions, i am sure that i can provide a lot of them.

Beeing available for Questions and Feedback and provide Learning Material and doing sessions about technology and patterns, before they are needed to solve a problem is the next thing i noted down in my plannings.

I am very thankful for all the Feedback and can't wait to get more!

It depends on the student.

Don't make assumptions. Observe and test them frequently. How you should teach them will be driven by this, and nothing else.

Btw, I ran a tutoring company for 8 years with over 6k tutors.

Awesome. Yeah i can not assume that everyone is an autodidact and teaches himself.

I will follow your suggestion.

Well, over 6k tutors sounds like you found ways to guide people successfully through the process.

My Question about this is, was peer-programming a standard tool, or just plain code-reviews?

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.

Here is the lesson I gave a friend at a bus station waiting for a bus. First explain how a computer works in very basic terms because most people don't know. Don't assume they know how a cpu, how memory, or their screen works, even basically. They know none of that. Assume they think a computer is a magic black box.

Then using the same terms you used to explain how a computer works, sort an array.

I have little experience with teaching but here are my 2 cents: What I observed is that at some point any new developer grows in ego and starts to question. So it's better to absent from teaching and let your pupil do something incorrectly on their own - if they fail they will learn a lot more than when being instructed to do something properly right from the start.

Once they've got their feet, make sure you continue to offer thorough and critical code reviews until they're well settled.

In addition to the myriad wonderful sources of online learning. Such as The Coding Train and Lambda School. I recommend an intro to the nascent discipline of "Product Design". Ideation, creative problem solving, and learning to iterate user feedback loops are very much indeed teachable skills. Best of luck ;)

Has anybody found that, while coding is simple super to us, your less fortunate friends who are actively stuck in career paths like bartender/waiter/laborer with no path out don't find it as simple?

Do you guys think coding (low level, junior frontend developer type stuff) could be taught to anybody?

It could be taught to most people, but aptitude correlates with enjoyment - if they don’t get joy from creating things, or they don’t enjoy spending time in a world they have to use their imagination to fully see, then they will probably never learn to code. I don’t know if you can get people to enjoy these things if they don’t already by the time they’re 25 or so. Everyone is naturally either more cerebral or more somatic, and environment can affect this balance, but once the brain is done developing there’s not much that can be done to change it. In my experience, somatic folks take a lot less readily to software and try to figure out a way to avoid figuring out the actual problems.

Learn how to speak english really well!

"One size fits all" is what you're looking for at school but you have the luxury of only having one person to mentor so they are a good person to ask first! They will tell you about their learning experiences, what worked and didn't work, etc.

some guy told me to learn assembly. most valuable tip ever :d. on a more serious note, for me personally, programming is 'easy' to learn as long as you have an interesting project to work on. none of my 'mentors' ever sparked that interest in me as they always gave very generic excersizes or projects to practice in. It's a good idea to try and find what this person has an interest towards in programming, even if they might not know it themselves yet. creating that initial spark will drive them to learn more eagerly / efficiently. Like learning anything, if you enjoy it / have a good motivation, in any case it will go better.

This is what I did. Extremely time consuming but does the job pretty well. https://www.youtube.com/watch?v=DpIkP4OUlkY

“If you want to build a ship, don’t drum up the men to gather wood, divide the work, and give orders. Instead, teach them to yearn for the vast and endless sea.” - Antoine de Saint-Exupèry

We built https://learnruby.bigbinary.com/ to introduce programming concepts using Ruby.

- Teach what a stack is, and its first-in-last-out principle.

- Use stack to program how to escape a maze.

- Teach Functional Programming, and optional OOP.

I am trying to self-learn to code from a quite some time now, couple of years to be exact.

Can't really tell objectively how is my process going because my end goal is to be able to sit down imagine a thing a code it, not even close.

I get some concepts a lot better because I am constantly going back to the basics and start over, but still I struggle on low-level real world examples or mid-level problems from websites like codewars and etc.

Here is my advice to you. Make real world examples. What I mean by that, don't make a tutorial how to do a calculator or a weather app or something like that.

Instead, after each new concept or lesson that you make introducing something new about coding, create real life scenario examples with a minimum of 10 examples that your students needs to code. For example make them write 10 different functions that do something in different situations, and niches - business related function, pet related function, vegetables related function, cars related function, water related function and so on.

Why? It is very hard for a new person to grasp the concept of coding, most of the courses and tutorials do that - this is a function, they give you an example with function a + b that returns the sum and that's it. So when you are a complete beginner then you struggle to figure out a function that can applied in complete different situation like a function to sort a music playlist.

By proving different scenarios from the real world for your students and break it into small chunks after each new concept and lesson, it will be easier for them to understand better how you can use this skill in the real world. By making them repeat it with different examples will help them memorize it faster, and recall the solutions when they see something similar that they need to do.

Why this works in my opinion? I live in a small country and in high school I had to learn English. The teacher made us write every single new word that we were introduced to in our notebooks, like minimum of 30 times. Not only that helped to memorize the words and their right way of syntax but then you get to start using them in a more complicated sentences.

My English is far from perfect but I haven't taken any addition classes and it helped me a lot so far.

After all you are also teaching a language, with which you communicate with the computer, I think you can take a look at different disciplines and apply some really good practices to make you a better code teacher.

This of course is from my personal perspective like a super beginner that try to do that in his free time online.

Best of luck to you.

For beginners, programs that output graphics are motivating. I have developed a browser-based programming language and environment that makes this easy.

https://easyprog.online

Make it fun. I've taught millions.

I don't think programming is suitable for teaching. Everyone who is good learned it by himself.

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

Getting acquainted with git could be a suitable task for him. Acquiring that skill should pay of well for him. These two links might be a good start: http://gitimmersion.com/ and https://jwiegley.github.io/git-from-the-bottom-up/

Best of luck!

Reply on news.ycombinator.com