Time for a disruption in learning

If you are learning a new technology by yourself, or if you are a manager wanting to elevate your team, you need to be part of the change.

It's been almost a full year now that I've been teaching technology to apprentice developers at Nashville Software School. Out of this first year, I've learned just as much as the students, except my learning has been about teaching. I've been teaching things to people for many years, but in an unofficial capacity. Now that it's my profession, and my students' livelihoods are dependent upon how well I do my job, I'm using every bit of research, experimentation and creativity I have at my disposal to my advantage.

I've learned a tremendous amount, but this article is about the one thing that I've discovered that accelerates learning by an easily observable amount: team projects.

Out with the old

Believe it or not, the idea that technology learning should be a team sport flies in the face of the preconceived notions of how it has been learned for decades. Perhaps it's just an obsolete legacy from the past 30 years of learning about computers and software development. It was mostly a solitary journey.

You decided to open the programming book.
You figured out all of the commands.
You decided what software was going to be written, and how to write it.
You decided on its design.
You put in the research to find novel ways to manipulate the language.
Even if you got a CS degree, how successful you were still depended largely upon you.

This worked for a while. Everyone I knew up until three years ago had a very personalized, unique story as to how they learned to write software. The problem, however, is that this process has too many prerequisite factors.

Adequate access to a computer.
Adequate access to learning materials.
Enough leisure time to devote to learning.
Encouragement from family or teachers to pursue it.

Even if all these factors are in place - which they aren't for many people - it was still almost completely left up to the individual to learn the material.

In with the new

Now that I have the ability to try different, direct strategies to help my students learn the material, the results have been eye-opening. Here's one example.

In the first couple of weeks learning front end technologies (HTML, CSS and JavaScript) I have a project I call Chatty. It's a project to build a very basic implementation of a team collaboration tool called Slack. The students use their new-found skills in DOM manipulation, event handlers, callback functions, and CSS to write their very first single page application (SPA).

In the three cohorts before the current one I'm teaching - Day Cohort 11 - this exercise was an individual project. It was also a slightly different exercise, because it was individual. I actually made it significantly harder for Cohort 11, and converted it into a group project.

"The benefits of learning in a team environment quickly, and forcefully, emerge."

When I discussed the project, and sent them on their way, I anticipated giving them the majority of two full days to complete the project. In the past, that's how long it had taken in the past. Even after two days, the work had never been completed except by a small handful of students.

After about 6 hours, my teaching assistants had just completed, what we call, a walkabout to check in on all the groups. To my astonishment, the feedback was, "Um, they're all pretty much done." I then did a walkabout to see, in more detail, how far along each group was. When I got back to the main classroom, I had to sit down with my TAs and develop four new bonus criteria that I considered to be highly challenging for the level of instruction that the students had received to that point.

Even with the bonus criteria, the majority of the teams were still done before lunch on day two of the project.

After teams are done presenting their projects, I always spend time asking for feedback about the project and the teams so that I know how to modify it, if need be. Every time there is a group project, I get 100% positive feedback. Students learn where they are weak and where they are strong. Because of that they learn what steps they need to take in order to get better. They learn about the importance of collaboration by making mistakes.

The benefits of learning in a team environment quickly, and forcefully, emerge. Left to their own devices, students quickly become frustrated and their ability to learn diminishes. In a team, they are more open to asking for help, more receptive to receive help, and more willing to provide help.

Now, there are occassionally downsides that you need to be aware of. There will be a few students who don't put in the effort and let their teammates do all the work. This rarely happens, but it does happen. You need to be constantly checking on the teams as they work, and make sure you question each teammate directly as to their comprehension of the concepts. If you find a teammate far behind the others, you have one of two choices.

Pull that student aside to work with a teacher assistant, or yourself, to get their skills where they need to be.
Ask the team to stop progress temporarily to ensure that everyone on the team understands the material.

It's up to you to determine which one is appropriate. If a student is truly far behind and cannot help the team without serious effort, option #2 often isn't the best choice, because the other teammates lose momentum, and that can cause frustration.

Balanced teams

Most importantly, they build each other up. I take care to ensure that each team has a variety of skills in its makeup. This way, each person has something to learn, and something to teach. This is crucial, and must be taken into account when learning happens.

If the team is comprised of people who are too much alike, less learning happens!

It's hard to believe, but even if three strong developers are all on the same team, I have found that there is less progression in their skills because there is nothing challenging them. Likewise, if all the teammates are ones that are struggling and have large gaps in basic comprehension, they all learn less. Having just one student who has advanced comprehension results in significant learning for the whole team.

Strategies for the future

If you are teaching software development, individual learning still has to happen, obviously, and individual comprehension still needs to be measured. I do that through no-stakes quizzes in the first 50% of the course. This tells me where the students are, individually, on comprehension of the fundamentals.

However, individual learning should be the minority of how a student learns. Right now, I'd say the ratio between group projects and individual projects in my curriculum is 60:40. I strongly urge students to enhance their knowledge individually after class and on the weekends, when they have control over when they can enhance their comprehension. However, when they are in class, group projects will dominate.

Classroom

Develop a group project for each major topic you teach.
Break students into groups of 3-5. Two students on a team leads to personality conflicts too often. More than five on a team becomes too unwieldy for apprentices to handle.
Individual projects should be worked on both while in class, and outside of class.
Make the individual projects align with the groups projects so that their individual comprehension can help the team, and vice versa. This helps tremendously with their ability to reflect and elaborate on the concepts.

Professional development

Never send just one teammate to a conference or training session.
Establish clear objectives for what should be learned at a conference and have your teammates work on a feature of your product, or even something different using the knowledge they acquired as soon as they return. Even if it won't make it to production immediately.
Whenever possible, if you are investigating a new technology, do not put just one person on the task. Find two people of fairly equivalent skill levels, but different strengths on the task.