When I was in grad school, my friend Chris and I took a Comparative Languages class together. Essentially, we were to learn about many different programming languages and their relative merits.
Incidentally, Chris and I both went through undergrad together but never really interacted. Then in grad school we wound up doing a project together and became fast friends. Many of my evenings over the year and a half of my master’s program were spent hanging out at his place.
In any case, we were told to team up, and each team would choose a programming language. We would then give a presentation to the class about that language. Chris was already a fan of Perl, an older workhorse of a scripting language popular among Unix users. He had heard good things about a newer language, called Ruby, which billed itself as a successor of sorts to Perl. I agreed, and we began research.
We both quickly discovered an absolute love of the Ruby language. Some craftsmen have their favorite tools; instruments which for whatever reason fit well in their hands and fit well into their method of working. For us, Ruby was that language. Our minds were blown at how we could do so much with this little language.
We knew our presentation skills were our weak point, but we were both excellent coders. Since Ruby was a language designed to quickly build software systems, we decided we would embark on an extremely challenging task: we would write our presentation in Ruby.
All of it.
Most people use a program like PowerPoint to build a presentation. The more academic and techie people might use a LaTeX template like Beamer to do the job. We decided we would write our own presentation software, in Ruby, and then do the presentation using our own software!
To make a long story short, we did it. For my fellow developers, this also meant we could embed a Ruby interpreter in the presentation software itself. Essentially, we could add a textbox to any slide where we could type a Ruby program. This program would them be run by our own software and the results output to the screen. So we could demo sample Ruby code in the middle of our presentation without switching away from our slides.
I realize it sounds like I’m tooting my own horn a bit, but it was utterly brilliant.
We also needed to have a handout. I had the idea, what if we just print out the source code for our presentation program and use that as our handout? It would demonstrate how few lines of code we used to build this program!
Ultimately, it worked! I believe our professor’s feedback was roughly “your presentation was mediocre at best, but it’s so impressive that you wrote the software yourselves that I have to give you an A anyway.” A little galling (I thought we did slightly better than mediocre), but basically mission accomplished.
For the technically curious, I managed to find the source code for this presentation engine. It’s old and creaky and (as of this writing) still barely works, though it prints out quite a few alarming warnings about how it’s not going to keep working in the future. I put it on Github here.
The moral that I learned from this exercise is “play to your strengths.” If you’ve been given a task in an area you’re weak, redefine the task so it uses an area you’re strong instead. It won’t always work. But sometimes, inexplicably, it does.