Teaching Newbie vs. Experienced Programmer

I sometimes have the opportunity to mentor individuals with learning R in my workplace. Typically the person who I'm working with has some experience with programming, so I try to relate R concepts to what they may already know from previous experience. However, now I'm working with someone who has no experience whatsoever with programming. I'm finding it a little bit more difficult to teach because I easily overlook very fundamental CS concepts which I don't even realize a complete novice may not understand (e.g. what is a variable/package, assignment of values to variable, etc.). Can anyone speak to the challenges of adapting teaching style to individuals with different levels of experience?


It's definitely a challenge. I teach a course within our Masters program that is designed for people coming from non-technical backgrounds, most of whom have never programmed before. Key points that I think I've learned:

  • You have to teach about the emotions involved in programming. That gives students permission to have emotions and to have frustrations, and to share them with you (so you can help with the concepts). So I talk about "conversations with a literal idiot" (ie the complier/interpreter/commandline), and I talk about how frustrating and hopeless most error messages are. I also outline a reasonable range of time to spend on problems (since novices don't know). Finally I talk about "the pain you are feeling now that you'll later recognize as learning". Mostly I orient myself to "building technical self-efficacy" rather than teaching programming per se.

  • I have them practice searching for help. We discuss the difference between documentation, examples, and tutorials. We look over some stackoverflow threads and talk about how hard it is to know whether something will help you, mostly I encourage them towards tutorials by talking about tone ("look for something that speaks to your level, don't spend time on materials targeted to others, skip anything that starts with "R/Python is like Java, but ..."

  • We go slowly, slowly. And I avoid giving them options, it's always tempting to say "Well you can do it three ways and here are the trade offs". Talk about overload! I require them to use the syntax and techniques I've taught, rejecting other syntaxes or methods which they almost always obtain via copy/paste from Stackoverflow.

  • I try to separate flow and logic from syntax. That's hard, but I do a lot of paper and pen worksheets or even physical exercises in the classroom to highlight overall logic. I reach for physical metaphors as much as possible.

  • Syllabus is here (it's Python and SQL focused, so probably not too relevant) it has links into tutorial material, scroll down to "Schedule". https://utexas.instructure.com/courses/1189186/assignments/syllabus

  • In the future I intend to use the visualization first approach, to get people feeling competent as soon as possible. That's what the Data Science with R book does that I like (and the DataCamp courses as well). I also intend to swap to tidyverse (in part because of the alignment to SQL and in part because that's what I personally use.

I'd love to hear other's strategies.


This sounds like an awesome challenge and a great way to level up your teaching skills! I'm always happy to talk more about various methods, but here's a short list of some of my "go to" favorites:

Backwards Planning
Determine what you want this person to know (content) and be able to do (skills) at the end of your time together. From there, breakdown the skills and content into their smaller component parts until you get to what seems like a reasonable base unit of knowledge/skill.

I tend to backwards plan for a given amount of time (an overall vision for the entire learning period - usually months), and then backwards plan into increasingly smaller units - generally down to two or three objectives within an hour-long session.

Vanderbilt has a good overall explanation, as well as templates.

If you're really interested, you can invest in the "Understanding by Design" texts as well.

Baseline Assessment (informal)
Use probing questions to figure out what the person already knows. This is an area where empathy goes a long way - you want the learner to feel supported, and not awful for things that they don't know. I try to develop open-ended questions that can get at some of this - so for example, instead of "do you know Excel?" I would ask something like "tell me about a project that you've done in Excel." This will help you get at some of the underlying areas of knowledge - as well as assess gaps in knowledge.

Checks for Understanding
Related to the above, checking in regularly to see if someone understands content/skills can help facilitate learning. Try to avoid yes/no questions like "does this make sense?" in favor of open-ended questions like "what questions do you have?"

There are a lot of great resources on developing question-asking skills. The University of Chicago has a great summary.

I, We, You
This is hands-down one of my favorite ways to teach - essentially it's "I do, we do, you do," which guides the learner from direct instruction to guided practice to independent practice. For example:

Direct Instruction

  • Show them how to install and load a package in R, while talking through what you're doing.

Guided Practice

  • Work through installing and loading a package in R, but ask them to provide guidance. You could say something like "OK, we've typed 'install.packages' - what's next?"
  • Then do it again where you're typing, and they're giving you each step and telling you what to type

Independent Practice

  • Then hand over the keyboard and have them do it on their own, while you provide guidance as needed

(I/We/You is covered pretty thoroughly in Doug Lemov's Teach Like a Champion 2.0)

Get comfortable with wait time
We have a tendency to want to fill the space between asking a question and getting an answer, but when you ask a question, people need time to think and process. It's OK to wait five or six seconds while they think about it, before providing guidance in answering the question.


I'm definitely going to give the "I, We, You" approach a shot. Thanks for the suggestion! I had never heard of something like it before, but I can totally see it working.

My initial approach typically resembles what you describe as "Backwards Planning", but I don't think I always execute it perfectly. Anyways, I think it's most natural, but it may not always be the most effective.

1 Like

keep us posted on how it goes!

Reviewing how to find answers via sources like SO is a great skill to teach. Teach a person to fish instead of giving them the fish

1 Like

If the individual is a non-technical person surrounded by programmers, or in an environment where programming is the norm, the learning process can be short wired inadvertently by trying to get them to achieve "perfect" at first.

I think Hadley sums it up well here. i.e., if they have no programming experience let them write poorer code than you might do (within acceptable boundaries) at first. And then look to optimise and make more efficient, learn additional concepts and thoroughly understand what is happening.


I second everything @jessemaegan said. Based on my experience, I would also add:

  • Get real data. Find 2 datasets that reflect the kind the learner will need to be able to work with- one for you as a demo, the other they will work with to generalize what you demoed (the I/we/you piece). Using built-in datasets can work as a start, but for totally new beginners these can be a lot of magic up front: Where does this data come from? How do you know where to find it? Where is this data stored on my computer? When I edit the data in R am I changing the underlying dataset that I pulled from?

  • Code together. Let them see you make mistakes and get error messages. When I was new, I watched a total pro programmer write code alongside me and he had to try like 5 times before getting one function to work- forgot to close a parenthesis, mis-specified an argument, etc.- and it was so refreshing to see all those error messages and he just powered through them! I tell new learners that I want to inoculate you against panicking when you get errors.

  • Teach how to use help docs. It is really important to learn how to use these, especially for folks who aren't familiar with packages, functions, and arguments- break those down by looking at usage and arguments in the help docs. In general, teach people to use RStudio and the tidyverse packages the way you use them, which typically is interactively, making mistakes, for example: using ?read_csv then figuring out how to use a new argument or override a default argument.

  • Think about a spiral curriculum. It is tempting to teach packages/functions linearly, one-at-a-time, but really you can always circle back to reinforce what you have already covered and expand on that, getting deeper into a given package or function as you go. This is the way @hadley's Data Challenge Lab goes.

  • Resist the urge to drive. Try not to take the wheel from them! That is the fun part :wink: It can also help you see what is confusing, like understanding that the first argument before the first %>% is always a data frame. I coded one-on-one with students last quarter and I realized that this was confusing, so I started saying "data frame first, data frame once" when we use the pipe and that helped us move forward.


UPDATE: Unfortunately, after meeting with this particular person once, he has not come back to me to seek assistance. It seems that he has resorted to other methods. (Hey, sometimes Excel is good enough to get the job done.) I think that all he wanted was a couple of plots with his data for a one-off project and wasn't really interested in any kind of long-term learning.

I'm not sure whether or not to consider this a failure. I suppose it can be difficult if the student doesn't have a sustained desire to learn.


1 Like

Here is my 0.02$ about teaching people new to R. First, don't teach R like it is a programming language. Teach them to do things in R first like the statistical analysis package that it is. Munge data, make graphs, analyze data, etc.. The reason for this is that you have to give them a reason to stick with learning R and answer the question "What's in it for me?" The first thing I learned in a corporate training class I took was that adults will not learn something new unless it is in their best interest to do so. Showing them how learning R can make their lives easier will do that. Plus, most people do not want to, or need to, become R programmers, but R users. An R user knows enough to analyze data. An R programmer is someone akin to a software developer. Mixing the user and programmer roles is the mistake that most people make when helping people use R.

Second, if you are going to teach programming concepts, then teach people how to break down a problem into programmable chunks first. This gets skipped a lot and it is why people have such a hard time with programming (Including me. No one in any of the CS classes that I took in college taught us how to break problems down first before coding).