Show, don't tell

This post was published on April 6, 2023

This blog post was published earlier in my (now defunct) weekly newsletter on February 7, 2023.

Today, I’d like to talk about something that happened in a recent training session, and that -in hindsight- was an example of something I’ve been slowly learning over the years.

While we were covering the material for the course, and going through the various exercises, I started to notice that people struggled a little with doing the exercises. They understood perfectly fine what they were supposed to do, it was just the actual ‘doing it’ that was hard for them.

Now, my typical course or workshop includes plenty of code examples, plus me explaining what the code actually does, both at a high level, e.g.:

“In this test, we’re creating and sending a REST API request, and we inspect the response and verify its status code”

as well as at a more detailed level, e.g.:

“This method adds the required authentication details”, and “Here’s where we set the HTTP method used when performing the request”

However, for several people in this group, and, in hindsight, in other groups as well, that wasn’t enough to make them ‘get’ it. All the information was there, technically, but somehow, it just didn’t ‘click’ for them. That changed, though, when I asked them if they would like me to complete the first exercise for them, sharing my screen, talking them through every step I took to complete that exercise.

After they had seen me do it, as opposed to me telling them how to do it, they suddenly seemed to ‘get it’ and after that, they did much better on the rest of the exercises. Result!

Later, after the session was over, I started thinking about what just happened a little more. I’m fairly certain that confidence played a big part here, or maybe the lack of it in the participants. They let me know beforehand that they never worked on API automation before, and that they didn’t have a lot of general coding and programming experience, either.

So, suddenly, they were faced with not one, but three things that were new to them:

• Testing of and automation for APIs
• Object-oriented programming
• The library we used to write our tests, and more specifically its syntax / DSL

That is a lot to take in, indeed. In hindsight, this should have been obvious to me, but this just goes to show you that even as a trainer, there’s plenty of things to learn!

Showing them how to actually approach an individual exercise, break it down into small pieces, talk them through each line of code I wrote, each method I invoked and each variable I created, helped them a lot in grasping what they were required to do. Again, they already knew what was asked of them, but they needed a little extra push on how to do that.

Also, they saw me struggle and make mistakes as well (hey, I’m not perfect!), as well as looking stuff up on the Internet, which I think helped build their confidence, too, seeing that even people with years of experience still don’t get everything right the first time, and don’t know everything yet. It was definitely a good lesson for me, and a reminder that I should do this more often.

So, even though my training courses and (the more technical talks) already contain a fair bit of live coding and hands-on exercises, I’m going to focus on those even more, doing even less talking and fewer slides, and more hands-on demos, examples and exploration. Once again, that’s where it will start to ‘click’ for most people, and that’s when and where the learning really and truly happens.

Show, don’t tell.

I’m looking forward to practicing this further in future training sessions, talks and webinars.

"