Teach Software Engineering Students to Listen to Each Other

Teach students to talk so they will listen and hear each other

I have a hard time resisting second hand book shops. Happily, my family supports this obsession. We especially like thrift stores, and charity shops, as their prices are quite good. 

I’m often looking for fiction for that bedtime read to wind up the day, and also look for books that I can use to support my teaching. This means I’m looking at lots of books. Pausing, picking them up, putting them back, wondering if it would be useful, or just be added to the stack of books waiting to be read and used.

Last summer in the US we were hitting all the thrift stores, which are huge, and finding lots of things. One that I found early on was a newer edition of one that I knew I had. I wanted to re-read it, and it would be a good holiday read.

A book on helping students talk to each other

I know. You want to know how this applies to students. It is all the same. This is the beauty of the book. The chapter have lots of examples, and you’ll quickly see that these all apply to students too. Actually, if you apply this to everyone, then you level up as a person in general.

The book was How to Talk so Kids will Listen, and Listen so Kids Will Talk. Yes, it’s a book on childcare. Yes, and the lessons it teaches you work with ALL people. This is why you should find a copy to read too. Given that it was first published in 1980, and the ‘revised edition’ was published in 1999, and the ’30th anniversary edition’ was published in 2013, you can easily find used copies for cheap prices. The one I found this time was the 30th anniversary edition, which had sections by the author’s daughter on what she thought of this, and how she used its approach with her kids.

This will show you how you and the students can acknowledge each others’ emotions. You will also find ways for them to improve their cooperation. While we don’t punish students, you will also find discussions of alternatives (carrots) to use instead of punishment (sticks). It also talks about how help them grow their autonomy, so they can become more independent, which is also good for students. Importantly, while it talks about praise, this can be considered in the context of feedback, which students always need too. Lastly, you’ll find a section on roles, and you can show them how roles change.

Look at some specific examples

The goal for you is to teach students to talk so they will listen and hear each other. Once they do this, things will improve. Too often they talk past each other.

Acknowledge emotions

People often ignore each others’ feelings: ‘How can you be tired, you’ve slept over eight hours?’ A better approach is to acknowledge their feelings: ‘You are growing a lot, and all the new stuff in class can seem overwhelming at times’. All this takes is some active listening. Teach students to listen to each other, and not formulate a reply while the other person is still talking.

Software engineering often focuses on the science and engineering. It ignores that it is people, who are collaborating to build these products. People have feelings, so we need to teach students how to work with them, instead of avoiding them.

Gain cooperation

People need to cooperate in order to achieve bigger goals. It can be hard to gain as people have their own agendas, and might feel their time would be better spent on other things. We also get tired of saying “don’t”, or “did you …” as we check for compliance.

I’m sure you’ve overheard students blaming each other, threatening various actions, and calling each other names too as they argue about why something hasn’t happened in the team. We can avoid this scenario.

Teach students to clarify why cooperation would be useful between team members. Teach them to explain why the draft is needed sooner Get them to fix assumptions. Point out why their cooperation helps themselves, and the team.

Show empathy

Students will also be upset at times. Their work is lost, or must be redone due to a mistake. People like to blame someone at this point. They might also look for redress to fix the situation. While it might feel better, it is not usually helpful.

Students need to learn collaboration for whatever they want to do after graduation. We can teach students alternative ways to gain cooperation within the team. Tell them to share their disappointment when things aren’t done as planned, and highlight the effect this has on the team. Tell them was expected behaviour was put into the team charter or agreement instead: For example, maybe the team agreed that members would ask for help if they got stuck.

If a team member is persistent in their non-cooperation, then the fellow team members can point out the options to the student. For example, if you keep turning up late to meetings, then you have these options: You can either let us know as soon as possible, so we can reschedule, or we can carry on without you and tell the course organiser, and you can do the resit.

This is an extreme one, so hopefully it doesn’t come to that. A better option might be for the team to discuss with that late student why they are late so that they can problem solve some potential solutions. This is the empathy approach, which I try to encourage most often. Talk to each other, find your constraints, and find solutions around those.

Encourage autonomy

Software engineering teams often double-check their ideas on the ‘next steps’ with me before proceeding. It’s ok when they’re starting out, but over time I worry if I’m helping them too much.

Instead of telling teams what their next step should be, you can guide them in generating the options from which they can decide what to do next. You can also set up classroom sessions where teams talk to each other and compare notes with their progress. Students consistently rate these as a high-value activity.

Help students learn to do feedback

People often say ‘congratulations’ or ‘great job’ on social media when people post achievements. This is nice, but not always helpful to the other person. A better option is to say what you like about the achievement. For example, ‘congratulations on the new role, I imagine the interview rounds were challenging. We should get together to talk about those’. In other words, describe what you see that was good.

Encourage your students to do this with each other too in their teams so that they gain experience sharing what they appreciate. This will also help them later when they need to describe various outcomes when applying for roles.

Changing roles is good

Student teams like to specialise roles. There is the frontend person, someone doing the backend, and the database specialist. This works, but I always wonder if the database person wishes, just this once, they could do some javascript on the frontend, so they get some experience there.

Having a specialist on a team creates two problems. First, the team will tend to defer to the specialist, which is ok if the specialist is that, and not just the person who knows a bit more than the others. Second, that person is now a constraint on the team, as the team passes all relevant work onto that person. The person is now a bottleneck.

A better approach is to have others also learn this specialist subject so that anyone can help the specialist. They don’t need to become specialist, but they can help reduce the workload. Similarly, the specialist can help other specialists and broaden their skills too. A good team should be mainly generalists with a few specialists as required.

By doing this the specialists learn they can do other roles too. The generalists also learn that they can do some specialist skills too. It’s a win for everyone.

Go find your copy of the book

I encourage you to find a copy of this book, read it and add its ideas to your teaching so that you can teach students to talk so they will listen and hear each other. In case you think I’m mad, I’ll also point you to Jeff Attwood writing about this book on his Coding Horror blog. This is probably where I first read about it too. As he says ” If you ever need to deal with children aged 2 to 99, stop reading right now and go buy [this book]”. I agree. You can thank us later.

---