React GraphQL Academy teaching method

A teaching method encompasses the principles and methods used by teachers to enable student learning. For a teaching method to be effective, it must take into account not only the nature of the subject matter, but also how students learn.

At React GraphQL Academy we train people from all over the world who have different social and cultural backgrounds. For some of them, especially the ones with a more traditional education, our method might feel uncomfortable or even wrong. This article is aimed to explain our method and where the value lies.

This article has two parts. The first part describes the three main categories of problems we’ve encountered following our teaching method. What type of learners tend to face those problems, and some tips. The second part explains the six principles of our method.

Lessons learned from teaching over a 1000 developers

We’ve been collecting feedback from our trainees since we started teaching React in May 2016 to professional developers. We’ve identified 3 main categories of problems when teaching new tech following our prIinciples to our audience.

1- Collaborative environment, or what I like to call the pair programming paradox.

Feedback from trainee:

There was not enough pair programming in the training, it didn’t feel it [the training] very collaborative.

We always encourage doing pair programming during our training. I start by asking who knows what pair programming is. On average more than ⅔ will raise their hands. Then I ask who believes it is good practice. Most of them will show their hands still. Then I ask, how many of you do it at work? Less than ⅓ on average will show hands. Then I say, I’ve got good news, we can all do it now. The paradox is, many people believe it’s good practice, but they don’t practice it even when they have a chance.

I’ve noticed that developers who are very experienced and are not used to doing pair programming will prefer to work on the exercises on their own. Less experienced developers tend to be more willing to try. Another factor, besides the work experience, is the type of education the trainee had in the past. In my experience, trainees that come from “learn-to-code bootcamps” tend to be more comfortable with learning in collaborative environments. There is also an individual factor, how open-minded someone is towards trying new things. Whatever the case, we can encourage and motivate people to do pair programming, but in the end, it’s a personal decision.

Tips:

• Don’t feel judged if you think you know less than the group. Some people might feel put on the spot doing pair programming in the course. People attend the course to learn, not to judge. Also, you might know less about a given topic, but then you might know more about others.
• Don’t be afraid of making mistakes in front of others. They’ll be likely to help you. We all make mistakes, just on different problems.
• If you are a bit skeptical about doing pair programming, give it a try, it might surprise you positively 🙂
• When pairing, please make sure you swap the driver / navigator roles at least after each task. This helps keep both people engaged even if one is quicker.

2- Discovery versus instruction

Feedback from a trainee:

I think some sessions become too (in my opinion) instructive.

Feedback from a trainee:

I wish less guessing what would be the solution.

Discovering is how kids naturally learn. Sugata Mitra’s research (video above) shows us that kids can teach themselves. If kids can do it, why shouldn’t developers be able to do it too?

We believe that technology changes so quickly that it gets difficult to keep up with it. We think that the fastest and most effective way to learn is by getting the right balance between discovering by ourselves and being guided. We also believe that building software is a discovery process in itself. Therefore, one of the skills we try to promote in our training is the ability to effectively solve new problems.

Tips:

• I’ve observed that those who tend to feel uncomfortable following a discovery approach are the ones who tend to need to practice it the most. If you feel it’s not working for you, try to be more open-minded and creative without judging the outcome.
• I’ve also observed how this discovery learning approach can be counterproductive when trainees get lost or blocked for too long. If you feel you’re not making any progress in an exercise for more than 10 min, reach out for help. Coaches are there to support you and guide you. You should not feel confused or frustrated.

3- Lecture versus programming

Feedback from a trainee:

I wish more theory before the exercise.

Feedback from a trainee:

The split between instruction and programming was not quite right in my opinion. Ideally each 3 hour session would involve 2 hours of programming.

Some learners prefer more theory, some others prefer more time programming. The goal is not to find the right balance that works for everyone, because probably there is not such a thing. I think the point here is to communicate where our training stands so trainees can make an informed decision before joining the training if it feels the right course for them.Tips:

• If you are used to a very traditional teacher-centered approach, which situates the teacher in the primarily “active” role while students take a more “passive” one, you might prefer longer lectures and fewer exercises. As a trainee, we encourage you to take an active role in the course whenever you can. If you believe your main learning methods are listening, reading, or watching rather than doing, then our courses might not be the best fit for you.
• If you prefer a complete student-centered approach where you take full control of your own education, then our courses might not be the right fit for you either. Our coaches are experts and authors with carefully designed learning objectives to be delivered. They are meant to facilitate and not to instruct. Nevertheless, if what feels right to you is a more self-directed environment we recommend you to apply to Recurse Center.

Our principles — where we stand

Learn by doing

We want developers to code/ do as much as possible in our training. But we can’t efficiently start doing without prior knowledge. We strive to get a balance of 1 hour lecture + QA for every 2 hours of in-class exercises. For us in-class exercise is not only programming but also pair & group discussions, and any other activity that makes trainees interact to work on the learning objectives.

This doesn’t mean we always lecture for one hour and then after trainees work for two hours. Lectures can be broken down and intercalated with exercises. Our lectures typically don’t explain everything trainees need to know before doing an exercise. The goal of our lectures is to set the ground for effective problem-based learning in the subsequent hands-on exercise.

“Learn by doing” is considered part of an approach to education called discovery learning which is very in alignment with how our academy teaches.

Collaborative learning

Pair programming is one of the best collaborative learning tools for developers. It enhances the learning experience because it forces both people to explain what they do and how, rather than just doing. This helps reduce the time a person can be blocked trying to figure something out (I have seen many developers struggling a lot before saying “I need help”), come up with different approaches, increase motivation and engagement, and consolidate new skills. By doing with others we get more input on what you are doing.

Progressive curriculum

Each class on our course covers a single topic, and builds on previous classes so that we can cover increasingly specialist material as the course progresses. As such, the whole course needs to be taken as a whole, rather than as a drop-in clinic. The curriculum is designed by industry experts, to balance coverage of those topics that we think are necessary to become an expert in the field, with those extra topics that learners commonly want to learn about, or appreciate being taught.

Open-ended problem versus closed-ended problems

A closed-ended problem is a problem that only has one solution leading to one answer. Closed-ended problems are easier to automate, for instance, this exercise. We think these types of problems don’t necessarily resemble the complexity of building real-world software. We use and recommend closed-ended problems to build certain foundational knowledge, but we think they are not enough for our end goal: to build developer expertise.

We believe that expertise is built effectively by solving complex problems with multiple solutions. Therefore, we prefer our trainees to work on open-ended problems. A critical success factor to this approach is that it must be assisted, and that is the case in all our courses.

Mentorship and guidance

Coaches guide trainees to help them think of the best way to approach and solve a problem. We are focused on promoting developer self-reflection, and critical thinking as opposed to prescribing solutions. Coaches make recommendations and explain the rationale behind the recommendations, then trainees choose. Sometimes learners want a simple answer: “what should I do, A or B?”. The answer typically starts with “it depends”. One of the coaches’ key jobs is to understand trainees’ problems and to make sure trainees understand the pros & cons of each approach recommended, depending on the case.

The mentors’ role in discovery learning is critical to the success of learning outcomes. Learners must build knowledge through examples, practice and feedback.

Get it right in the end

We think that we can learn a lot from how second languages (English, Spanish, etc) are acquired in order to teach new programming languages or styles (Functional Programming, Declarative Programming, etc).

“Get it right in the end” is a technique for second language learning in the classroom. It’s the opposite of the traditional “get it right from the beginning” approach, which explicitly teaches all the rules and concepts before students start using it.

We think learning is an iterative process where we constantly refine our mental models. “Get it right in the end” is very aligned to our idea of doing as early in the learning process as possible. The way we implement this technique in our courses is:

• Learners start doing before they know all the concepts. They build knowledge by trying things out, interpreting docs, and asking questions.
• Coaches give corrective feedback.
• Coaches recap and formalize the concepts learned at the end of the session.

You can read more about this technique and others for second language acquisition in this book.You can also check out some of the authors’ ideas in the following short video:

Feedback, Feedback, Feedback

These are the principles that guide React GraphQL Academy, because we’re passionate about teaching, and we really want our students to thrive on their learning and further career. But ultimately we try to be flexible and to take into account each of our students’ learning needs. This is why the feedback of our courses is overall very positive, and why we’re becoming leaders in the market of React and GraphQL teaching. If you take a course with us, we encourage you to give us feedback: your opinion is very important! We appreciate that and will use it to evaluate changes and make improvements in our courses.

Originally published at https://reactgraphql.academy.