About 3 weeks ago, I ‘pivoted’ my career slightly and took a job as a software development coach. There are various reasons for this which I won’t go into here, but prime among them was that I wanted to spend more time working with people and less time working with machines.
Of course, as with any career change, there’s a certain level of discomfort as you adjust from being relatively experienced and capable in one professional arena to being green, uncertain and a little kack-handed in another. Yes I’m still working with software, but education is a whole other ball game.
It’s not the first workshop I’ve done (it’s the second) but it’s the first time I’ve had really detailed feedback after the event. I thought the workshop went reasonably well but reviewing it afterwards was eye-opening not just in the things that I need to work on but the things that I hadn’t even really thought about.
How do you know if they learned anything?
When I was preparing for the workshop, my focus was almost exclusively on how am I going to demonstrate the key concepts. As such, I worked hardest at understanding the material to be delivered in the primary introductory session. What I didn’t really think a lot about was the plenary session – I think I had assumed that this would be a simple Q & A.
When I confessed this to Kay during our feedback session however she suggested that in some respects the plenary session was the most important part of the workshop. She also suggested that I should be thinking more about I can validate whether they have understood the concepts and also whether they can use them.
She suggested, for example, that using the tests from the workshop challenge to explore and demonstrate some key concepts would have been really useful, and that using Q & A sessions as a way to gauge a groups understanding is generally not useful because the people asking questions are usually those who are at least approaching understanding while those who have been lost along the way tend to remain a lot quieter.
When you’re performing an unfamiliar role in a new environment it can be difficult to put emphasis on the experience of others in the room because it’s natural to focus on your own. As such, it’s useful to have some tools to help you focus on that and to prompt you in case you lose site of it. A simple list of learning goals and things to cover might help; perhaps with some reflection I may think of some others.
Give them context and grab their attention
I put a lot of emphasis on making the demo interactive. In building the counter I asked the students to predict the outcome of the program, with the goal of making them think about the execution.
What I didn’t do very well was explain why they should bother doing things this way in the first place. One of the questions at the end which I think I struggled to answer in an articulate and helpful way was ‘can you give me an example of where you would use this pattern’. But for me, modules and closures have become such a natural way of developing that my immediate response was almost ‘why wouldn’t you use this pattern’. Which, of course, is not helpful.
Situating learning within a wider context, being enthusiastic about that context from the outset and really getting their buy in to the problem before showing them the solution can be a great way of engendering greater understanding. It can also be a great way to keep your answers relevant and to help you avoid losing sight of exactly what the learning objectives are.
Pay attention to the quieter students
I’ve already alluded to the fact that people answering questions are generally reasonably well along the journey to understanding. Something that I tried to do during the workshop to gain general understanding was use thumbs up/thumbs down with regards to understanding different ideas. Unfortunately, I didn’t do this very well.
Firstly, my gestures tended to be leading. I would begin with my own thumb up in order to indicate what I wanted from them, which could lead students to feel under pressure to emulate the gesture.
Secondly, I tended to focus only on a part of the room where there were a lot of thumbs. There was another part of the room where I wasn’t so focussed where there were fewer responses, which probably indicated a lower level of understanding. However, probably led my own need for validation I developed a degree of tunnel vision and filtered these out.
Thirdly, I didn’t really have a plan for if there weren’t a lot of thumbs up. I had prepared for the happy path only.
How could I do this better? I think directing some questions out to students a bit more randomly (as I have seen a couple of the other coaches do) to involve a wider range of students, and using the interactions not only to demonstrate a concept but validate that students have understood. Also, having additional material and a ‘backup’ plan for if the response is less positive.
Revise the basics/know your shit
This one was pretty obvious, even without feedback. I got caught out by a couple of relatively simple questions for which I didn’t have an accurate or simple answer. When you’ve been doing something for so long it can be difficult to remember the basic principles that you learned at the start, and also difficult to acknowledge the bad habits you’ve picked up along the way ‘just because’.
It’s very difficult to know all the things you think you know but don’t really know until you get called out on them, so perhaps that’s just something that will come with experience. I think the best tangible action I can take there is that, when I experience these moments, to take a few minutes to research and write about the concepts after the event. A lot of concepts I believe I understand exist only as abstract forms and shapes in my head, and writing about something forces me to examine it through the lens of language, which in turn can both expose false assumptions and help build a mental model that can actually be communicated to another.