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

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.

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.

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)

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.

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.

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

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.

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.

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

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

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.

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.

Good Link.

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.

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.

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.

He only can learn from this.

Thank you for your 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.

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.

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

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.

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

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.

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.

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

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!

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.

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!

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.

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

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.

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.

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.

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.

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

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.

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

Thanks for your insights.

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.

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

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.

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

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.

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

Thanks for your answer

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.

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.

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

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.

Commoncog has a nice general overview [2].

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

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.

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

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.

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.

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.

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.

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

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

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.

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.

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

We need people like you. All the best!

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.

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

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

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

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.

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!

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

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.

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?

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.

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

- Use stack to program how to escape a maze.

- Teach Functional Programming, and optional OOP.

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.

* 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

Best of luck!