I’ve recently had the pleasure* to give a week of developer training in Ho Chi Minh City, Vietnam. The team was hand-selected, skilled, and motivated professional developers, and had already received three weeks of introduction training in the underlying technology of the project. I had run the same training sessions to different groups already. So the conditions were almost ideal.

However: every session took a lot longer than planned, even when I was skipping over some topics and time-consuming hands-on elements. The reason was mostly the English language.

My typically slide decks are slim, and do not contain many words. I rather use some diagrams and photos than bullet points of what I’m going to tell anyway. This means that I spend most time standing next to the projector screen and talk. I sometimes use Prezi instead of PowerPoint and jump around the presentation content. While this style gives me a dynamic and lively way to present, and seems to have some entertainment value for the audience, it did not work well with this group.

Without bullet points, the audience relies on the spoken words to understand the structure of the presentation. I had to talk really slowly and pronounced (and quite loud, with 25 people in the room) – which I tried, but I constantly had to remind myself (and be reminded) to stick to it. I still received feedback that I’ve been too fast, and that some of the audience could not really follow well.

And it’s not that their English was bad. It’s just that when you come from e.g. German (like me), English is quite an easy language to learn. But just look at a map – England and Germany are just a tiny bit apart. Vietnam however is on the other side of the globe. And so is the Vietnamese language. Just an example: the same sound, spoken in a different tone, can have four different meanings. Like I said, the group were excellent – they even had received English training. Reading and writing is not a problem at all. But listening and speaking is.

When you don’t speak a language well enough, spoken language becomes an obstacle.

So I reworked the slide deck to be more rich in text. But still, you can’t have all your content on the slides, and some of the stuff was quite conceptual. For example, I had a slide about the Arrange-Act-Assert structure in unit tests.

It was not before the end of the week were it dawned on me that me and the audience shared one language that is extremely expressive: code.

Here’s the evolution of the Arrange-Act-Assert slide:

Original version

I show a movie where the engineers first prepare the building with the explosives, add the wires, dampening mats, the works. Then the explosion is triggered, the building collapses. After that, the engineers examine that no surrounding buildings have been damaged. While the movie runs, I talk about what they’re doing. After the movie has finished, I flash up three images from the different phases and draw the connection to arranging the preconditions, running the tests, and checking the results. If questions come up, I use them to elaborate on that point a little deeper, in an ad-hoc fashion.

In a group that does not well understand English, the movie and the spoken information together easily lead to information overload. They lose track, and while I’m on the finishing line with the elegant conclusion, they still wonder why the building was razed after all.

Text-Heavy slide

The structure does no longer rely on spoken word. However, the content is still abstract and requires some explanation. Specifically, the translation of the concept into code is not laid out: does the arrangement belong into the text method itself, or is it in the test setup? What about tests that do not require arrangement? This still has to be given verbally.

Code-based explanation

I start with a method to be tested. I add the skeleton of a test method. This is augmented with verbal explanation. Then I add the method call and add a comment “Act”. The method requires a precondition to be set, so I add a line of code and the comment “Arrange”. Then I add an assertion, with the matching comment. After the code is complete, I switch to a PowerPoint that shows the just created code blocks, and adds an abstract diagram as a overlay.

This approach has the advantage that it starts with a language that the group of developers understands perfectly well: C# code. The abstractions follow after the coded example has been shown. Verbal explanation is given, but only adds to givens that do not rely on the audience’s ability to understand English.

For developers, code is the language everyone understands.

I did not have the time to rework the slide decks to follow this schema, so I tried to improvise and used a text editor to write up some code while I was presenting. I’ll definitely give some more consideration to the audience’s language skills.

———
Pleasure: Vietnam is awesome, and Ho Chi Minh City is a place that you must have seen.