I am currently 4 weeks in to my data science bootcamp at Metis. As a former teacher, I often find myself thinking there has got to be a better way to teach this stuff. Our instructors give us a lecture covering a subject like logistic regression or database management and afterwards we are sent off with a set of problems to practice our new acquired knowledge. Often there is confusion from the students about how complete the problems. While the instructors are there to help, there is an expectation that students just work to figure it out.
This idea that you learn to code by trial and error seems to be a widely held belief among many programmers. I heard this from my girlfriend, who is a web developer, before the program began and I have heard it many times since then. Is it true though? Is coding best learned through just figuring it out, or is there some other way we can approach this to design a better curriculum? We don't use this approach when teaching student how to do basic math, so why do we use it for programming?
Now I don't know exactly what the process should be for learning how to program, but I believe there are certain steps that can be taken to make learning how to code easier. I've come up with three things bootcamps can do to make sure students are as successful as possible when learning how to code.
Teach students how to read documentation.
"Look in the docs." This is a common response that I receive from fellow students, instructors and friends when I asked them a question about how to do something. This is often because they don't know the answer themselves, but also because the documentation can provide you with a lot of helpful information. When I began looking at docs though, I just saw a wall of letters that reminded me of the "The Matrix." I was intimidated by all of the jargon that was unfamiliar to me. Even when I am able to find the a function that I am looking for, there is a list of parameters a mile long that confuse me again. With some time I have been able to demystify documentation a bit and learn to read it, but I feel that this process could have been sped up more. Since I'm still learning I'm not sure how to do this, but I think if I had a clear process to use when approaching documentation, I would be better able to answer my own questions instead of relying heavily on others.
Checks for understanding.
As an instructor is presenting some material, how does he know if the students actually understand? Many times when we are teaching a subject we think, "Nobody has raised their hand to ask a question and most people are nodding their heads, so they must be right with me." We might even throw out an "Everyone ok?" to confirm this idea, but this is not enough. Even when people think they understand a concept, they often don't know what they don't know. So instructors should have breaks in their presentation to ask the class a question or work through a problem. This doesn't have to be a long thought out problem, but just something that forces them to apply the concept in the presentation to something outside of what has been discuss. For example, "Give another example of where you can use this function and explain why you would use it?" Also, don't have one person shout out the answer, but give time so every student can write down their response and then call on random students to answer the question. Doing this will increase the length of any presentation a little as you have to clarify misconceptions or reteach something, but at the end the presenter will be sure that everyone actually understands.
Focus and Repetition.
Photographs by NASA on The Commons.