Speakerline

What If Shakespeare Wrote Ruby?, by Adam Cuppy
#alllevels #personalgrowth #keynote-worthy

Abstract

Talk Description

Did you know that Shakespeare wrote almost no direction into his plays? No fight direction. No staging. No notes to the songs. Of the 1700 words he created, there was no official dictionary. That’s right the author of some of the greatest literary works in history, which were filled with situational complexity, fight sequences and music, include NO documentation! How did he do it?

In this talk, we’re going “thee and thou.” I’m going to give you a crash course in how: Shakespeare writes software.

Notes

It’s easy to draw the correlation between a stage production and an application: both have a creator and spectator; both, are expected to follow a predefined script (or text); and both, have a set of players, who all have a role and responsibility. The commonalities between a piece of performance art and digital art are also seen in how we (as Rubyists) and they (as users) perform in a dance of “accumulated expectations”.

A play, musical or any other live show, is an act of vanity without the presence of audience: laughter, hope, pain, sympathy, empathy, etc.. This feedback loop, impacts the performance: giving the show a unique life. The same symbiotic relationship between creator and spectator is all so prevalent between the engineer and the user. As creators, we build an experience. That experience is presented to a user and from that point, we, as creators, have to account for their reactions.

So, why does that matter? How can we build better, more reactive software that responds intuitively to the user’s “reaction”. What design patterns exist in the live performance relationship that can influence a deeper more core level experience, rather than just deliver content?

In this talk, I’m going to hit on the psychological and situational similarities between putting on a show and building an application. I’m going to identify the core components of a successful theater production and what we can use that to influence predictive, responsive, appropriately reactive and flexible software (art).

Edit proposal