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