Behind the scenes: Kotlin 3-part coding workshop
Last year I ran a Kotlin workshop for beginners and soon, with some changes, it became the first in a 3-part series. It’s been a while since I finished running the whole series, but I took notes during the process and I wanted to share the story and some of the things I’ve learnt while doing this.
A little context about the first workshop
My purpose was to help other people start coding in Kotlin as part of TECH(K)NOW Day event organised for Ada Lovelace Day in 2017.
To prepare the workshop I listed the things I wanted to take into account:
- workshop duration: 2 hours
- expect Kotlin to be a new programming language for most or all attendees
- expect different levels of programming skill
- build a simple game people are familiar with
- have something running by the end
- find somebody to help during the workshop
- make all needed materials available online and offline
After analysing several ideas I picked Sudoku as topic because everybody knows how to play it and you can make it as simple or as complicated as you want. In order to simplify things I chose to do it as a standalone app as opposed to web / mobile because I wanted to keep the focus on the language, not on the platform.
From one part to three parts
After running the first workshop I felt there was a lot of interest in the idea of learning Kotlin by building something fun, and also a shade of disappointment that it was too short. There was definitely space for more!
Again, I started to write ideas on paper and in the end I focused on these:
- keep the current workshop as the first part
- keep the duration of 2 hours per workshop and make a 3-part series
- define the features to be added to the game on each part
- have a working game by the end of each workshop
- start every new workshop from the previous completed code
The first thing I asked myself was how to split the features I wanted to add for the next 2 parts. It was fundamental to have something working at the end of each session and always build on top of the previous part.
I wrote down how the state of the game should be at the end of each workshop. For every part I decided a series of steps that were needed taking into account the language elements I wanted the audience to learn.
Preparing workshop materials
I attended many workshops and courses during the years with different formulas. It’s difficult to know what works best but I had to start somewhere. The format I chose in the end was pretty much the classic one:
- start with a short presentation describing the problem we were going to implement and how (on a high level)
- talk about the Kotlin language topics to focus on
- have a worksheet with all the steps and explanations
- provide a skeleton for the project
Once I was happy with the format I moved to the next step: splitting the Sudoku game in 3 levels of implementation from the most basic one to something more acceptable. At the end of each session you could play the Sudoku game, but you would have different limitations that were left to be addressed in the next one.
Part 1. Start from a solved Sudoku game and hide a few numbers. The user will input the missing numbers and you’ll compare the entered number with the one in the solution.
Part 2. Load the Sudoku board from a file where you have numbers from 0 to 9. Each 0 will correspond to an empty cell in your UI. The user will input the missing numbers and the board will be validated by checking that the number entered is not in the same line / column / 3x3 area.
Part 3. Add the ability to play random Sudoku games and start a new game by clicking on a button.
Once I clearly defined the limitations for each workshop I created a project and started to write the code. This means the whole implementation, iterating until I was happy with the amount of code and the topics I wanted to introduce in each of them.
Since it’s common during workshops to have audience with different skill levels you should make sure nobody feels overwhelmed. For each of the three projects I looked at the whole code I wrote and decided what parts are too complicated and not necessarily important for the purpose of the workshop. In the end those went into the base, something that was provided beforehand.
Each project was structured so that I could extract the steps that had to be implemented during the workshop. In parallel with removing those parts from the code I started to write a document to serve as a worksheet during the session. I made sure the steps in the worksheet were also provided as comments in the code.
For each part of the workshop I created 2 github repositories, one to be used during the session and the other one containing the solution in case somebody wanted to do this in their own time.
Although they could be done individually, all parts were connected. Each of them continued from the previous solution. I made sure I started with the same code, the only change was to delete the old comments and write new ones.
Below is the link to the first part of the workshop and at the end of the README file there is a link to the next part.
The only tools needed were Java SDK and Intellij Idea. I made sure everybody had the needed tools installed. Even if I wrote in the description when advertising the workshop “This is a hands-on session, you need to bring a laptop […] You need to have Java SDK and Intellij Idea installed.” I knew it was always a possibility that people didn’t do this beforehand.
I also prepared a few USB flash drives containing everything needed in case there was no internet connection. I put there 3 folders, one folder for each operating system: Linux, MacOS, Windows.
Inside each folder I had the correct distribution of the tools and other materials needed, such as the worksheet and the initial files for the workshop.
The next part contains a compilation of things I read as I prepared for the workshop and, most importantly, things I learnt after, either from the feedback I received or from the experience.
It is written using a “How to do it” tone because it’s something I use as a reminder every time I have to do something similar.
Starting the workshop
Welcome everybody and present yourself. If the number of people is small, less than 15, ask everybody to say their name and what they do. This way you’ll have a good understanding of the level of your audience. This will help you know how to explain concepts during the coding session. If you have more people, just ask a few questions and tell them to answer by raising their hands. In my case I started with “How many of you tried coding in Kotlin before?”, continued with “How many of you didn’t hear about Kotlin before joining this workshop?”. Don’t ask too many questions, limit to the ones relevant to the workshop.
Mention that it’s good to ask questions during the workshop, so people will feel comfortable doing this.
Before starting the actual coding session talk about the tools needed and have everything ready to download and install (make all links available and / or distribute USB flash drives).
During the workshop
If it’s a multi-part series and it’s not the first part, always start with a short but meaningful recap. You may have people that didn’t come to the previous part, or they may not remember where they are with the code.
On each step give the audience time to think and write code and then show live how you would do it and explain. It’s good to wait for everybody to finish before moving to the next step. If you can, bring somebody to be your assistant(s). They’ll help people that get stuck and you can continue.
You have to be mindful about the time. Be prepared for both cases:
- if you finish too early, show something new that is not part of the workshop
- if you don’t have enough time to finish make sure the materials provided contain everything needed for anybody to finish in their own time.
End of the workshop
Ask for feedback. Have a simple survey prepared with a few questions. Specify if it’s anonymous or not. I used Google Forms and made it anonymous as I felt I would receive more feedback this way.
Thank everybody for coming 🙌
Make people feel welcomed on each session. No matter if they attended or not the previous one, they should be able to continue. Make the session as interactive as possible.
Have a git repository for each session. Don’t add new code between sessions, the one written at the end of one session should be the base for the next one.
Accompany every repository with a worksheet with all the steps needed to write the code.
Make all materials available for people to use them some other time.
Ask a friend / colleague to help you during the sessions, especially if there are many people attending.
If possible, depending where the workshop is taking place, ask in advance if they can provide a whiteboard. This way would be much easier to explain concepts and answer some of the questions.
Gather feedback during the session, at the end, and also send a feedback form. Analyse everything and improve your next sessions.
Good to have with you
As I mentioned previously, be prepared with some USB flash drives in case of slow or no WIFI connection, laptop adaptors and charger .
The best thing when running this kind of workshops is that it’s always different. For example, in one of the sessions somebody asked me to write the same code in Java for comparison.
It can also happen to have questions that deviate from the original topic, but it’s great, it means people are interested and want to see and learn more.
If there is something you don’t know just say let’s try together to see how it works, or you’ll check later as it’s an interesting question. It’s ok not to know everything.