Or: What is this Espresso thing, and why is everybody doing jigsaw puzzles?
There were a couple of challenges to overcome, though. One - rather minor - challenge was finding a project name for our initiative to marry the new framework to the trivago Hotel Search. Project names often appear sort of random at first, and our name, “Project Espresso”, is no exception. However: An espresso is small and strong, as is our framework - admittedly, still somewhat random. But not totally. Our large Italian developer and product owner community loved the name, obviously, which made it a good choice after all.
However, there was a much greater challenge ahead: The new framework demanded a radically different development approach compared to the status quo. It is a lot more functional, a lot more modular, and it is component-based. This required developers to re-think and re-learn a lot of what they had practiced and known so far.
From the beginning, we thought that face-to-face training was important. We planned for a series of five workshops, during which participants would get some hands-on experience using the new framework. Since we did not want to hold workshops with 40 attendees, we limited participants to 6 to 12 per session, and held each workshop multiple times.
Also, we wanted to keep the workshops reasonably short, so we tried a dual approach. We prepared screencasts that everybody could watch at their own pace before the respective workshop, so that the workshops themselves would not turn out too long, and could instead focus on repetition and practical exercises. This method allowed us to keep the workshop sessions to one hour each.
Originally, we planned for 26 screencasts of three to ten minutes each (bite-sized, similar to what egghead.io does). However, since they turned out to be very time-consuming to prepare and create, and since our teaching team comprised only four people who could work on the curriculum only part-time, the number of screencasts was later reduced to 15. We complemented the self-produced screencasts with publicly available ones. For example, since our framework uses Redux internally, we referred course participants to the excellent Redux screencasts by Dan Abramov. Why should we reinvent the wheel, after all?
Producing screencasts had several benefits:
- Screencasts are asynchronous, so people can watch them whenever they want, and as often as they want.
- They will always be available to new developers without requiring a mentor’s time.
- The engineers who produced them gained valuable technical and educational experience, so they were presented with an additional growth opportunity.
Teaching talent discovered
Speaking of growth opportunities: We intentionally got young, talented developers involved in teaching activities. In fact, one of these developers had just joined the company a few weeks before. Others were quite surprised when we asked them if they could hold one or two workshops, and worried if they would be up to it. In all cases, though, we reassured them that they would do fine, and we were right. Eventually, they did a great job and appreciated the feedback we gave them on how to become an even better teacher.
Problems of the one-track approach
I mentioned above that our one-track approach lead to certain problems. Most obviously, some people were slightly bored during the workshops, while others were struggling or slightly overwhelmed. This was to be expected given the different skill levels we faced. However, a considerable source of frustration was something we had not anticipated: ES6 familiarity, or rather non-familiarity. We had been using ES6 language features in our code base for several months, and we had offered workshops and presentations on ES6 a while back. However, by far not all participants were exposed to, let alone wrote, ES6 code on a regular basis. Moreover, the ES6 workshops had been optional, and even if a developer had attended them, she might have forgotten a lot in the meantime due to lack of practice. In an attempt to remedy the situation, we injected small bits of ES6 recap (like an explanation of the spread operator) into the course material. Since time was short, however, these small bits could not fully fix the issue.
Since we made people give up familiar ways and enter into unknown territory, and because everybody is busy and has already a lot on their plates, the Espresso teaching team thought it would be good to have a small gift to say “thank you” for the time and effort our participants invested. Ideally, it should be somewhat funny, creative, not entirely useless, and inexpensive. Also, the giveaways should indicate the participant’s progress in this workshop series - since we were planning for five workshops, we wanted to be able to split each gift into five parts.
After some thinking, we decided to create a custom-made jigsaw puzzle that we would hand out bit by bit, from left to right. It had a large heading “Project Espresso Certification Puzzle” on it, and “Level 1” to “Level 5” labels from left to right, with pictures of (mostly) celebrities with an espresso cup.
There are a lot of online services where you can upload a picture and get a jigsaw puzzle of it. The cheapest one we found offered a preview like the following, with a 3x5 layout:
We thought: “Great! Five workshops, five columns of puzzle pieces. Only 15 pieces in total, that’s easy to split!” So we went ahead and ordered 40 of them. What could possibly go wrong, right? Delivery was quick, but then: Surprise! 112 pieces per puzzle!
And no, they did not arrive in finished state, as the picture might suggest. What on earth was going on here? How could we have missed that? I checked on the vendor’s web site, and indeed: It did say that the puzzles consisted of 112 pieces each. But it did so on a page that was displayed before I had entered the order process - that was where Google had taken me, and I had not skipped back.
What to do? Since the first workshops would soon start, we decided to just go with it, split the work among the teaching crew as well as volunteers, and have jigsaw assembly sessions.
However, even the group sessions could not handle the huge load of puzzles. Since trivago is a big family that extends beyond the employees, even some of our kids jumped in and helped out (they were curious and bored, anyway ;-) ):
During one of the puzzle sessions, there was a second big surprise. Naïvely, we expected all the individual jigsaws to be identical, so we started out putting the different parts in paper envelopes labelled “1” for the leftmost part of a puzzle, “2” for the following part, etc. However, my colleague Radovan thankfully noticed that each jigsaw was cut differently. In other words, you could not combine part one of puzzle A with part two of puzzle B, because they would not fit together. We had to make sure that whoever got part one of puzzle A would in the future also get part two of puzzle A, and also parts three, four, and five of puzzle A.
The bad side of this discovery was that it invalidated part of the work we had done so far. The bright side was that the new labelling scheme we used instead was more personal, with a participant’s name (or nickname :-) ) on each envelope (if you don’t know who Pistenprinz is, check out his site):
Together, we finally managed to get it all done, and to put all the pieces in their correct box or envelope. However, before we could hand out the first puzzle pieces, we had to store them in our lockers, which looked pretty funny sometimes:
All in all, I think the puzzle part made the entire project a little more fun, and showed people that we appreciated their effort. Some participants put them up on their desks for everybody to see.
Our teaching initiative in numbers:
- We held 15 individual workshop sessions so far, spread out over roughly two months. Workshop rounds four and five are yet to come. However, these will be deep-dives into the technology, and will be optional for non-JS developers.
- Around 40 developers took part in total, making it the largest teaching initiative in our department so far.
- 15 self-produced screencasts accompanied the workshops (~90 minutes of material).
By now, several of our developers have successfully used the new framework to power some major features of our core product, and we have seen some impressive gains in memory and performance. We will keep you posted as we gather more data.
Maybe the biggest learning from the teaching initiative is: If you ask people to give up their expert status for something they are unfamiliar with and insecure about, then you better go out of your way to encourage and motivate them, eliminate frustrating experiences as far as possible, and help them succeed in hands-on exercises. Introducing a new framework, and even a new development paradigm, is a large change that needs careful management, and should not be approached lightly. Just because you are excited about something does not mean everybody else is. Keep that in mind and approach the people you want to learn from you with some humility.