Creating “Reducing Enumerable — An Illustrated Adventure”
How I created and illustrated my conference talk for Southeast Ruby 2018.
In August 2018 I gave a talk at Southeast Ruby, a fully illustrated one at that, about the adventures of Red the Reducing Lemur and his adventures through the land of Enumerable.
Southeast Ruby is returning in 2018! We had so much fun last year that we decided to do it again. Join us August 2-3 in…southeastruby.com
So of course my badge needed a few lemurs on it as well:
After the talk, I’d had a lot of questions about how exactly a talk like this came to be.
So what exactly goes into an illustrated talk? What type of pre-work is involved? How do you decide narratives, voices, characters, and other thematic elements and tie them all together.
Well that, dear reader, is what this article is about. Welcome to the wondrous land of Lemurs in “Reducing Enumerable — An Illustrated Adventure”!
The Core Technical Concept
To give the talk, I had to have a core technical concept that I was targeting, something solid that could be built on. Late last year, in October, I started a series called “Reducing Enumerable” which had gained a lot of attention:
One of the lesser understood functions in Enumerable for many Rubyists is reduce . It’s just the thing we can use to…medium.com
This article came from a desire to help people understand reduce, one of the most misunderstood Enumerable methods in Ruby, and with that an idea clicked.
What if I happened to give each of those functions a cartoon representation to explain this topic? In the past I’d had luck with teaching with cartoons, so why not upscale it to a conference talk?
Lemurs had been a long-time animal of choice for me, so I decided to use work I had already done on a draft version of “An Illustrated Guide to Ruby” as a base:
Now that idea came from a certain lucky stiff, who was the very reason I came to know and love Ruby in the first place. His Poignant Guide to Ruby was my start, and I wanted to capture some of that whimsy again and use it to teach a new generation.
If by whatever chance Why happens to read this, know that you made a difference to this programmer and an entire generation.
So we have a technical concept, great! …but unless we manage to get a compelling story to go with it, it’s not really a part of the talk as much as a last minute addition to look pretty.
The idea I decided to pursue was one of a student learning from their master, and going on a grand adventure to learn from others. I believed, and still do, that it’s an important message to go out into the world and find people to learn from.
Some of my best connections and friends have been people I’ve known and respected in the community for years before spending time with them. Whether that was learning or just talking, I felt it important to convey that feeling I’d had while learning myself.
Now, because of the way the Ruby community is, and because of my early influences, I had a love for whimsy and fun. That meant I wanted people to enjoy, to laugh and cry, and to feel like they’re really in a story book following along with Red’s adventures.
Whether or not I achieved that is not my statement to make.
The first step of preparation involved a lot of pre-planning. That means outlines written in markdown, scrawled on whatever paper happened to be within unfortunate reaching distance of my hands at the moment.
It didn’t have to be pretty, it just had to convey the general flow of the story as it was to go along. Several index cards were lost in this process, but eventually a semblance of an outline began to take form.
After I had a semi-decent idea of what the talk would involve, I started to storyboard it, a practice I’d picked up from watching videos on animators from some of my favorite shows growing up.
This helped me visualize the story as it was to progress, and get a good idea of the flow of it. I used index cards so I wouldn’t be tempted to go into too much detail on the sketches, as they were only really meant to convey rough ideas.
The faster they were done, the faster I could move on to fleshing out and giving life to other areas of the talk.
To the Sketchbooks!
For those who don’t know me, I’ve been sketching random cartoons for years, so I’m most comfortable with a pencil and a sketchbook. So that’s where I started.
It was time to translate some of the story board into full-sized sketched (2H / HB pencil) images that I could ink (Copic Multiliners), color in (Prismacolor Premier Alcohol Markers), and scan (Canon Printer / Scanner).
This had been my process for most of the “Illustrated Guide to Ruby” images, but it was a bit slow and didn’t really scale well in terms of scanning likely several sketchbooks worth of illustrations, cleaning, and toning them up in Photoshop.
Digitizing on an iPad
That was about the time that I had had the time to try out an iPad Pro with an Apple Pencil. I wasn’t remotely comfortable with it, and sketching on the glass surface always threw me for a loop.
The thing that convinced me otherwise? Adobe Illustrator Draw.
Create beautiful, scalable vector designs on your iPad with Adobe Illustrator Draw and sync your design across Adobe…www.adobe.com
You see, not only could I use photos of my sketches as a base, I could also export art created in it as a vector or Adobe Illustrator format.
That meant the illustrations would be clean, sharp, and most importantly: they would scale to whatever size screen without visible loss to the audience.
So I grumbled for a bit and decided I was going to learn this tool and how to properly draw on an iPad. The benefits were too great to ignore, and maybe with enough practice I’d get good at it.
After a while of experimenting, I was starting to get the hang of it:
…and do you want to know what the kicker was to all of this? Illustrator Draw gave timelapses as a form of export:
That meant that not only would I get vector art, but I’d also have the ability to show how it was made.
Syntax highlighting in normal code is completely based on keywords, rather than concepts. While teaching an abstract concept, this would do very little to aid the message, so I decided to try a new format: conceptual highlighting.
Each distinct concept would get a distinct color.
- Yellow for our original list, and each of its iterated values
- Red for the accumulator, our new list
- Orange for a new accumulator value
- Green for our joining operator to add things to the new list
- Pink for functions to be called
- …and blue for other code elements
One of the elements of presenting I had learned from some of my colleagues at Square was to use selective highlighting. This meant to gray out sections of the code you weren’t currently focusing on, to draw attention to the areas you were.
So each code example would be broken down into concept-highlighted blocks while I addressed each section.
The unfortunate part is that this had to all be done by hand as far as coloring, but a worthy sacrifice for the amount of clarity it gives while teaching concepts.
Going a bit Overkill
You see, the bad part about finishing early is you always want to add more.
…and I certainly decided to add more. I was having so much fun with it that I decided to keep going and working on illustrations, adding better transitions and hammering down concepts.
My talk was better as a result, but the core of it was ready over a week in advance. I’d saved my slide deck at various points in time as distinct files so I would always have something to fall back on, should I have gotten carried away.
It turned out I had, so some images were indeed left out of the final product as a result. I’d like to think I’ll be giving this talk again some time in the future, so I get a chance to show the rest of the slides just waiting to be polished up.
Voice of the Lemur
Now, speaking of overkill, I decided that since this was a storybook tale, the characters needed voices. Distinct voices at that, the audience had to be able to tell them apart.
What I don’t mention though is that I decided on committing to the voice acting bit mere seconds before I started into it. I’d figured that I’m already going all in on this talk, a bit more wouldn’t hurt, and it certainly paid off in the end.
Do note the voices were pre-done, practiced, and annotated throughout the notes to give me hints on which exact character I was portraying in the moment.
I will say those who watch the video of the talk (to be released later) will be amply entertained with Indigo, the master of Select.
Easter Eggs Abound
What fun would a talk be if I didn’t sneak in a few easter eggs? I decided to (with permission) sneak in a few famous Rubyists. I won’t say which ones, you’ll just have to watch the talk to find out.
By the Numbers
So what did this talk end up weighing, when all was said and done?
The talk contains 41+ illustrations of 8 lemurs, spanning 137 slides to be delivered in 30 minutes. The talk itself took just over 135 hours to prepare, and honestly?
It was worth every minute.
I hope you’ve enjoyed this journey into “Reducing Enumerable — An Illustrated Adventure”!
Would You Do it Again?
It was a ton of work over two months to get this talk done, but that being said? Yes, yes I would.
In the end I learned a ton about illustration, especially digital, which will help me with future projects. Taking a bet on using a new tool to prepare the entirety of the illustrated content of this talk was a bold move, but the results were worth it.
When I was learning, I loved the sense of whimsy and fun in the language. I’d like to remind the community of just that, and what made us love the Ruby language in the first place.
I hope to see you all at the next illustrated talk some day in the future, but in the mean time I hope to give Reducing Enumerable a few more runs.
It was a blast!
If you find yourself impatient, the slides are available here including most of the speaker notes. Be forewarned it’s a large file (~250m) and I have a habit of improving some of the lines during the presentation.
This talk ended up going to RubyConf as well, you can see the video here: