Hacking the Mind:

(This is the transcript of a talk I gave in September 2014 at ABB DevDay in Krakow, Poland.)

The world of software development is changing at an increasingly rapid pace, leaving developers with less time to learn new tools and paradigms, and hardly any time to convey that knowledge to others. How do we convince our managers to change course? How do we bring other developers up to speed? And if things go wrong, how do we explain it to our non-technical customers without losing their trust? I'll talk about the relationship between art and code, and how we can use the principles of fiction, music, poetry and painting to present complex information to any audience without confusing or -- worse -- boring them to tears.

Hello, and thank you.

I call myself Qi. I'm a software developer, and I’m also the author and illustrator of an odd little website called “The Codeless Code”. It's a series of fables about a temple of software-developing monks and their masters in a make-believe mountain setting. The overall style was inspired by traditional Zen Buddhist lessons called koans.

The purpose of the website is to explore the world of software development in a (hopefully) entertaining way. Each week I pick some topic, like thread safety or refactoring, and I write about it in the form of a very short story.

To give you an idea, here’s an example, which I’ve written especially for this conference. It owes a lot to a traditional Zen koan from a 13th century collection called “The Gateless Gate”.

One day, the Temple awoke to discover that its databases had been hacked. The intrusion was traced to a web application that had recently been updated by a certain monk. The monk was fetched by two Temple guards to explain himself to the Abbess.

As the guards marched the miserable monk up the tower stairs, they passed old master Banzen on the landing. Taking pity on the boy, the master whispered into the monk’s ear: “If you speak in your own defense, the Abbess will think you a coward and cut off your head. But if you do not speak in your own defense, she will think you were responsible for the incident, and cut off your head.”

With those words, Banzen departed down the stairs.

Now, before I continue the story, let me ask...

Why are we here?

Most of us are here because we’re developers. And many of us became developers because we like to make things. We like to code. Some of us love to code.

We love to code, and the best part of all is, people actually pay us to code! And sometimes – when we're lucky – the code they pay us to write does really cool or really important things, and we get really absorbed in it and the day just flies by.

And if that's all our jobs were – designing and building cool things, with no deadlines, with no one making us go to meetings or give demos or figure out why the servers have suddenly started crashing, we'd probably all be pretty happy people.

But...

People are unavoidable. Coding doesn’t happen in a vacuum. We have bosses, and customers, and end-users, and tech leads, and peers, and junior developers that we're mentoring.

So you may have to communicate effectively with many different types of people, for many different reasons...

They may be senior developers who are prospective users of your open source JQuery toolkit, wondering what it does, how it works, and why they should use it and not one of the hundred other options out there.

They may be new developers on your Enterprise system who don’t yet know the ins and outs of the codebase, and you don't want them going off on a tangent and creating a mess.

They may be junior developers on a team you lead, who need mentoring on a whole variety of topics, like the importance of writing automated tests and sanitizing database inputs.

Now you can tell them what it means to “sanitize inputs”, and why it’s important, and how to do it, but if you don’t convince them, they’re probably not going to go out of their way to do it. Because no one has time to follow every “best practice”, right? Just like you're probably too busy to make sure they’re all following that “best practice”.

Which is how bugs and security holes get into that big Enterprise system. And then you have to start talking to a whole different bunch of people, who are going to be even less likely to understand what you say...

You’re going to have to tell your customers why the web application you just made a “harmless” change to was hacked last night, because someone on your team didn’t sanitize their inputs;

And you’re going to have to tell your managers why your next delivery is going to take twice as long as you originally estimated, to allow for code reviews;

And you’re going to have to tell your end-users how their personal information got compromised by the hacker, and what steps they should take to protect themselves, and how you're going to ensure that this does not happen again.

And if you’re not good at all these explanations, you may have to convince some job interviewer that they really should hire you even though you were just fired for gross incompetence.

On that note, let's return to our story...

The monk was called into the office of the Abbess, who unsheathed a sword and demanded: “Explain how you brought disgrace to our Temple.”

The monk began to profess his innocence, but remembering the advice of master Banzen, he quickly shut his mouth lest the Abbess behead him for cowardice. Yet the silence that followed only made the Abbess resolute in her anger. She raised her sword and approached the terrified boy, determined to behead him for his undisputed incompetence.

In desperation the monk's eyes searched the room for another exit, but they found only a screen of rice paper and bamboo, beyond which lay a narrow balcony and a hundred-foot plummet to the rocks below. As the whistling blade fell toward his neck, the monk was enlightened.

The monk dove under the Abbess’ blade, rolled across the room, and stood before the rice paper screen. Taking a red marker from his robe, he hastily drew a stick figure in one panel. The Abbess paused, intrigued.

In the next panel, and in the ones following, the monk drew shaky cartoons depicting the events that had occurred over the past few weeks, and how his clan had reacted to each. When taken individually, no step was in error. Yet when taken collectively, it was clear that a confluence of unrelated actions had resulted in the critical vulnerability.

The Abbess sheathed her sword, and with a wave of her hand dismissed the monk.

But when the monk reached her doorway, the Abbess gave him a swift kick in the behind, sending him tumbling down the long tower stairs.

“That,” said the Abbess, “is for writing on my walls.”

Like the monk, we developers are very often at the mercy of people who are above us in the chain of command yet understand almost nothing about what we do. It’s easy to get frustrated with those people. It happens to me all the time. But remember, you didn’t come out of the womb knowing how to code. At some point, someone taught you.

Even if you got every scrap of your technical know-how from reading books and websites, someone took the time to write and maybe even illustrate that text. They helped you to understand. They taught you.

So when you’re trying to explain something technical to people who don’t have the background you have, remember what you're doing: you're teaching. Teaching is how professions like ours gain new members, learn from past mistakes, and move forward to make bigger and better mistakes. Teaching is how we move forward. Teaching is how civilization moves forward.

And teaching has never been more important than at this time and in this profession.

Why? Why do I say that?

IT is a world of arcane knowledge, always in motion. Every year it seems we have to learn some new toolkit or new language or new paradigm just to stay current. Now, some of us enjoy this. It’s exciting. But even if you don't enjoy it, you can’t fight it. If you try to stick with only familiar and comfortable technologies, your systems can fall so far behind that no one will want to maintain them.

And here's where we enter a vicious circle. We are paid to make the world run faster, and to keep up with the changes that are happening around us... all that new stuff. But when we succeed, the new just becomes the norm, which makes space for an even newer new tomorrow, and the cycle repeats.

So the world spins faster and faster, forcing many of us swim like crazy just to stay afloat, leaving us with too little time to even learn the critical details of our own systems. And all the while, our cars and our airplanes and our medical treatments and our militaries are growing ever more dependent on a complex web of software.

This is how little mistakes become big problems. This is how things fall apart.

The only thing that keeps disaster at bay is knowledge. Who's holding everything together? The people who both know and can teach. People like you.

Teaching effectively means that we need the people we’re teaching to learn. Otherwise we’re not teaching; we’re just talking.

We need to keep our audience engaged. Interested. So how do we do that?

By intriguing them. By entertaining them. By leading them down the path from ignorance to understanding, the same path that we ourselves once went down.

Notice I said leading them down the path. You can’t just lay out a bunch of facts and expect them to draw the same conclusions, or even to care. As Morpheus said in The Matrix: there’s a difference between knowing the path, and walking the path. You need to get your audience to walk the path; to take a journey of the mind — and you usually need to do it in a very short amount of time.

The good news is, we’ve spent a big chunk of human history figuring out how to take other people on journeys of the mind.

Collectively we call it Art.

What is Art? What is the purpose of a story, or a drawing, or a song? Well, there can be several.

To entertain, usually.

To educate.

To inspire the soul.

To fire the imagination.

But for Art to do any of these things, it has to communicate, right? A story that sits unread in a drawer isn’t really a story; it’s markings on paper. A sculpture hidden away in a closet is just a lump of stone. A painting in the dark might as well be a blank canvas.

This is not music. It's not music until someone plays it, and someone hears it. So what is it?

It’s source code.

It’s meant to be compiled by a musician, and then run.

But what’s the machine that runs the code?

The brain. Specifically, the mind. The mind that hears the sounds. That’s where the sounds become music. Where they become emotion. Where they become an irresistible call to clap our hands to the beat, or to dance, or to sing along at the chorus, or to create songs of our own. Music can be a call to action. Writing, drawing, poetry, all of the Arts: we think of them as entertainment, but they can all be calls to action.

The ancient Greek goddesses of the Arts and Sciences — the Muses — were also the daughters of Mnemosyne, the goddess of memory. I don't think that's a coincidence. Art is about taking things that we remember and making things that will be remembered by others.

Art is about hacking the mind.

Art is about hacking the mind.

It’s about getting people to learn things, even when they don’t think they’re being taught.

It’s about inspiring people to do things, even when they don’t think they’re being persuaded.

Those of you who are developers: every day you use your knowledge of how machines work to get those machines to do things. This is not that different.

Art is about hacking the mind. And we’re hackers.

So let’s hack...

Like any good developer, we start by choosing a good design pattern for our task. There is a name for the Art of Effective or Persuasive Speaking or Writing: rhetoric. The Ancient Greeks and Romans developed the Art of Rhetoric with the stated goals of "moving, delighting, and instructing" the audience. Ok, sounds like what we want.

The first two steps of rhetoric are developing your logical argument and ordering your points for the greatest effect. This is how we'll plan the route of that “journey of the mind”. The starting point is where our audience is, mentally. The destination is where we want them to be.

So, for example, we want to take a junior developer from Point A, “I don’t know what you mean by sanitizing inputs, and I don’t really care”, to Point Z, “Oh My God, I just realized that my dynamically-constructed query is vulnerable to a SQL injection attack, let me fix that RIGHT NOW.” We have to plan a route that will lead them smoothly from A to Z.

It turns out, there's a perfect art form that will help us hack their minds...

I'm not talking about “user stories” here. I mean good old fashioned fiction: novels, plays, etc.

Stories are the traditional means of taking someone on a mental journey through unfamiliar territory. People love stories. We listen to them as children. Learn how to tell stories, and you can communicate anything to anyone.

This is especially true if you're mentoring your team, because you want them to understand why you believe what you believe about the right way to design and code. If you learned something the hard way, you will gain a lot of ground if you can bring that experience to life through words.

Now, I’m not saying that you should present your technical lectures as dramatic readings. But the art of storytelling is the art of conveying information in an effective, entertaining manner. It’s helpful to know how stories work at a psychological level, and how to tell stories well. What are the tricks of the trade?

Before you even start watching a movie or reading a novel, something important happened. It was so subtle you probably didn't realize it.

You decided to watch the movie, or read the novel.

Something told you just enough about the story to draw you in, to make you give your attention to the author. The trailer for the movie, or a brief synopsis. The artwork on the front cover of the novel, or the summary on the back. It told you roughly what to expect; what the genre and overall tone is. Comedy. Crime drama. Science fiction. Sword and sorcery.

In journalism – which is the art of telling factual stories – they draw readers into a story by a principle called the upside-down pyramid.

In journalistic writing, you put your most important facts up front, in the lede paragraph. This allows busy people to scan quickly down and stop reading when they've got all the details they need.

(By the way, the upside-down pyramid is used for a lot of technical talks, and it's still a good way to structure information, but it's not the best way to tell stories that will keep your audience interested until the end. I'll tell you the big problem with the inverted pyramid before we finish up with Stories and move on to Music.)

Now, notice: even before the lead paragraph of critical facts comes the thing that gets you to read the article: the headline. It sums everything up in one [hopefully intriguing] phrase:

As an artist, you have to make your art compelling, even from the outside. The same is true for technical material. Your prospective audience is bombarded with media choices clamoring for their attention. You have to get them to click your link, to attend your lecture.

For example, if the title of my talk is “Proper of the JDBC PreparedStatement API”, I would expect zero people to show up. Including me, because God that sounds boring.

But what if my title is: “How We Were Hacked Yesterday, and What We're Going To Do About It”. Same talk, but a little more compelling, right? Maybe you'll show up. At least for the first few minutes, to check it out.

At the beginning of any story, your audience's first question will be, who or what are we talking about, and why should I care? Because if I don't care, I'm out of here.

So we have to set the stage. In fiction, we introduce a setting and characters that our audience will find interesting and can identify with.

One of my favorite science fiction books is The Cyberiad by Stanislaw Lem. Here’s how the English translation starts:

One day Trurl the constructor put together a machine that could create anything starting with the letter n.

That's a great opening line. Our setting is “one day”, we have two characters (Trurl and the machine), and already there's something interesting going on. As the story unfolds, we learn more about Trurl: he likes to build things, and he makes mistakes... like us. We begin to empathize with him. We keep reading, in part, because we care about what happens to him.

You can use this trick with technical information. The setting may be yesterday at your company. The characters may be your audience, or your peers, or your prospective users, but the idea is the same: get the audience oriented, and give them someone or something to identify with.

Even hardware and software can act characters. After all, our systems are like people: they process orders, send emails, delete files, and -- unfortunately -- make mistakes... like us. Anthropomorphizing them is a neat little trick for getting an audience to care about them and even understand them better. If I tell you that UTF-8 input causes my application to freak out, then I've given you a vivid, memorable piece of information, even without getting into the specifics.

Generally, stories involve conflict between our characters and other forces. Otherwise, they're pretty boring stories. When there's conflict involving characters we care about, we find ourselves cheering for those characters and hoping they'll succeed. Confict is usually the problem to overcome.

In traditional narratives, there are four basic types of conflict: person against person, person against society, person against nature, and person against themselves. If you're talking or writing about a technological issue, there's probably an underlying conflict you can find and bring to the foreground.

-- Talking about tools for system diagnostics? That can be a dull slog for your audience. Or, you can frame it as a story of person against machine, starring the audience themselves. “It's 3 a.m. and you've just gotten a frantic call from Operations that a key system is crashing and its developers can't be reached. Everything is on your shoulders. What do you do first? What tools can help you do that? What might you learn, and what then?”

-- Trying to convince people to use your GitHub project? You're the central character in Person against competitors. What makes your Javascript widget framework better than the dozens of others out there? Well, why did you write it in the first place? Which other frameworks did you try that failed to meet your needs? How did you learn from and avoid their mistakes?

-- Trying to get your developers to write unit tests? If you frame the discussion as “you developers need to stop being lazy”, no one will listen to you. Remember that this is the struggle of Person against themselves. In cartoons they sometimes show someone with an angel on one shoulder and a devil on the other. The angel is saying You need to write unit tests before shipping your code, and the devil is saying no! you're tired, and there's a great movie on, and everything seems to work anyway. That's something we can all understand, right? Why should we listen to the angel, when the devil is more seductive? What are the consequences?

Conflict in stories will sustain a reader's attention only so far. We may be curious to find out who wins and who loses, but in order for us really to be engaged, there has to be something big at stake. Losing can't just be inconvenient; it has to be unacceptable, unthinkable.

Suppose I tell you that a woman is planning to rob her employer. What's at stake? She gets money if she succeeds, jail time if she doesn't. Eh.

But what if I told you that this woman borrowed a lot of money from the mob to pay for her husband's cancer surgery, and when she didn't pay them back, the mob said, “Ok, then you're going to help us rob the bank where you work. And to keep you from going to the police, we've abducted one of your kids.” Now there's a lot at stake, right? Suddenly it's much more compelling.

If we're trying to convince someone to take a different path than the one they’re on, then a very good strategy is to show them why the path they’re on will eventually lead to a bad bad place. If there are dire consequences of failure or inaction, we need to make those clear up front. It helps get their attention.

If we’re dealing with junior developers who aren’t security-minded, we might start with a story on “The Daily WTF”: a great site of true IT horror stories:

One of the cardinal rules of computer programming is to never trust your input … Apparently, the developers at Oklahoma’s Department of Corrections slept through that day in computer science class, and even managed to skip … Common Sense 101. Not only did they trust anonymous user input on their public-facing website, but they blindly executed it and displayed whatever came back. The result of this negligently bad coding has some rather serious consequences: the names, addresses, and social security numbers of tens of thousands of Oklahoma residents were made available to the general public for a period of at least three years…

(From http://thedailywtf.com/Articles/Oklahoma-Leaks-Tens-of-Thousands-of-Social-Security-Numbers,-Other-Sensitive-Data.aspx)

The ramifications are pretty clear. Embarrassing headlines. Lawsuits. Multi-million-dollar development contracts are lost over this kind of incident.

I had a contract at a company that built control systems for satellites. When they needed to get management's attention about a serious issue, they had a phrase: satellites could fall from the sky. That was usually all it took.

There's a principle of fiction writing: show, don't tell. If you're trying to convince your customer to push back a deadline to allow for code reviews, don't just tell them what you think -- show them what can really happen, what has happened to others. As one of my customers used to say: “Just keep us off the front page of the Washington Post.”

As I mentioned earlier, your audience's time is limited, and their attention is always divided. How many times have you come across a really cool technical article and bookmarked it to read later... only, later never comes?

In fiction, one way to sustain the audience's interest is to increase the tension with urgency. Not only do our characters need to act, they need to act now.

In our bank robbery example, it's clear the woman needs to act now. She went to the mob because her husband was dying and she needed the money now. She's robbing the bank tonight because the mob has her kids now.

Urgency propels the action. Urgency ramps up the tension. Action/adventure films are compelling in part because of the sense of urgency.

We want our technical information to be compelling, so – if it's relevant -- we have to emphasize why this is important now. Why do our developers, our customers, our managers, need to know this information now? Need to act on it now?

If you're stuck for an answer, just remember how fast the world is moving. We talk about internet time; how fast we have to move to stay ahead of our deadlines and our competitors. In our field, if we've identified a course of action, “eventually” is almost never good enough. We need to improve our security now. We need to refactor our systems now.

Now. Now now now.

If you've convinced your audience that they have to act now, their next question is going to be: what should we do?

If you're following the inverted pyramid model, the audience may already know the subject of your talk or the course of action you're proposing. If not, then this is the point where you would introduce that course of action. New coding standards. Adoption of our new JQuery plugin.

This is where we summarize the solution we're proposing, the goal we're moving towards to overcome the primary conflict and avoid the dire consequences that would come from inaction. The Ring must be cast into the fires of Mount Doom.

Undertaking this journey probably will involve some effort, so this is also where you want to talk about the additional rewards awaiting our heroes if they prevail. The Dark Lord will be destroyed! No more user-support calls from Mordor!

So then we're done, right?

Of course not. You can’t just present a difficult course of action and stop there. If you do, you’ll probably get a response like this:

When a serious problem arises in heroic fiction, the solution usually involves a long, risky journey. When a serious problem arises in software development, the solution usually involves a long, risky refactoring.

In both cases, the main characters are not going to want to make the trip, and they’ll look for every excuse possible to avoid it.

You have to be prepared for your audience to object to your plan. To ask, isn't there something else we can do? Something cheaper, or easier, or more popular?

Those are fair questions...

This is a necessary part of the journey we have to take our audience on. This is our mission as teachers. To take our audience from premise A to conclusion Z, we not only have to visit B, C, and D, but we may also have to stop briefly at B-1 and C-2, if only to show why we can't or at least shouldn't go down those roads. You might even agree that B-1 and C-2 are preferable, but are still dead ends.

In compelling stories, characters often take actions because an obstacle appeared as they were trying to achieve some goal, so now they must overcome that obstacle. A good author shows a character who may want to stay at home, but is forced by circumstances to go into the city, or to Alderaan, or to Mordor. This feels real to our audience, because life is like that. This, in turn, makes the story more satisfying.

See, when we're trying to convince someone of the merits of our application design, or our choice of a 3rd party tool, or our plan of action when dealing with a crisis, there is a natural defensive impulse to avoid mentioning risks, or alternatives we don't like, or to downplay the importance of those obstacles if they come up.

Beware that impulse.

It's the same impulse that causes an author to write a far-too-convenient “happy ending” where everything magically works out. The audience feels cheated, not because the ending was happy, but because they sensed that something was missing from the story. In fiction, we say that the ending “wasn't earned.”

So if you're not talking about obstacles, it might indicate that you really can't overcome those obstacles. That your argument is weak. Your audience will sense this.

So instead, embrace those obstacles in your plans. Discuss them, and (if possible) dismantle them. If you can't dismantle an argument, treat it as an unexplored road for consideration in a follow-up conversation. If someone points out that your plan has risks, focus on how you'll minimize those risks. It makes for a more interesting discussion, as well as a more open, honest, and convincing one.

It also helps prepare your peers (or your customers) for any difficulties they might encounter when following your recommendations. Because if you fail to consider just one alternate road, you might find yourself in a situation like this...

 

Let's step back a second and take a look at the tools that storytelling has given us so far to make our information more compelling. It turns out that these tools give us an overall structure for the journey:

We have the teaser to bring in our audience, then we establish a setting and characters that they care about, pose a problem which is our source of conflict, illustrate the consequences of the problem, give our audience a sense of urgency (now now now), propose your solution if you haven't yet done so, show the rewards it will bring, and then build a case for our long walk into Mordor by showing how all the other options are dead ends.

Once we've done these things, we can explore our solution further: how we plan to get there, how we'll mitigate all the risks along the way, and so on.

That's a lot of ground to cover!

How else can we keep our audience interested along the way?

Explaining technology is difficult in part because so many of the concepts we deal with are abstract. Software itself is mostly intangible. So how to we get an audience to understand what we're talking about if they don't yet have the background they need? Through analogy. Explain the unfamiliar by comparing it to something familiar.

Why do we call intrusive programs “worms” and “viruses”? Why does computer networking use words like “firewall” or “tunnelling”? Because these words create a useful, memorable mental image.

The Codeless Code depends heavily on absurd analogies. In one case I wanted to show what can happen to a small code base if you keep adding on new features but never take the time to refactor it. I thought, That's sort of like if you outgrew a tiny house, but instead of moving or remodelling you just stuck new rooms onto the existing ones. In the story I put the house at the edge of a cliff and had the builder keep extending it outwards into thin air, even though the structure was swaying in even the gentlest breeze.

The resulting mental image is vivid and easily understood. Notice that I don't need to explicitly say This house is unsafe: your brain will make that connection for you, and will also conclude this development practice is unsafe without me having to say it. The strangeness of the imagery and the sense of danger also helps make the concept more memorable.

That's the power of a well-chosen analogy. We get the audience's mind to do the hard work for us.

If our talk is long or our topic is complex, we're probably going to get sidetracked by questions or objections. How do we keep our audience's attention throughout? The unfortunate answer is, usually, we don't.

Attention takes effort, and we can expect to lose our audience's attention every few minutes. And that's ok, as long as we can get it back.

One way to keep reeling the audience in is to structure our presentation as a sequence of mini-stories inside the overall story. This is one reason a long novel is made up of chapters, and a movie is made up of scenes. Just as the end of a chapter is a natural stopping point where you might put a book down, the beginning of a chapter is a natural starting point.

In each chapter or scene we first orient the audience to where we are now, and possibly introduce new settings or characters. Then we introduce mini-conflicts which explore our characters or advance the plot.

For long presentations, you want the same structure. Each point of your argument, each feature of your library, is a story within the larger story. Address it, explore it, and always remind your audience of how or why it fits in with the bigger point you're making.

Now, these stories-within-the-story should not all be identical to the point where you can move them around arbitrarily. To keep your audience engaged they should form a particular overall shape...

You may have seen this diagram if you've ever taken a Creative Writing course: it's the typical three-act structure used for stories.

Notice that the action rises and falls. Even in a good adventure film, the action doesn't stay pegged at 100%. Too much excitement or intensity is actually exhausting, and irritating, and boring. It's like being shouted at for an hour. Again, we're hacking the mind, and this is one of the realities of the mind -- the brain needs to rest.

So if you're giving a long technical presentation, remember: long-format storytelling moves in waves. There's a main arc of rising and falling action, made of smaller arcs of rising and falling action. Even if you're not following the structure of a stories-within-a-story, your energy as a speaker should move in waves:

-- The peaks, where energy is high, are the places where we're describing critical details. Conflict! Consequences! Urgency! Now Now Now!

-- The troughs, where energy is low, are places where we're commenting on a point, answering a question, or maybe even just taking a moment of silence to let things sink in, and then maybe change slides.

 

But how do we prevent those low-energy troughs from going to no energy?

As I said earlier, there's a big problem with the inverted pyramid model as a storytelling structure. If you put all of the important information up front, people can tune out or leave halfway through your talk. Not good!

So if you divide your story into chapters, try not to tie up all of your loose ends at the end of a chapter. Always leave something unresolved to create tension, or to act as a teaser for some chapter you haven't reached yet.

Television shows end seasons on cliffhangers, because if they can get you to tune in for the first five minutes of next season's opening, they can probably keep you around for the whole episode, which (if they're smart) will set up the overarching conflict for the next season.

Ask yourself as you write or speak: if I were in the audience, what would I want to hear right now that would keep me in my seat for just a bit longer?

Something else that keeps us in our seats longer is being entertained. Remember, this is one of the goals of rhetoric: to delight the audience.

Little doses of humor in a long presentation are like hits of caffeine. They wake us up. Because humor, by its nature, is unexpected. Humor catches us off guard.

Humor is difficult; you have to know your audience. But done well, humor can dispell a somber or tense mood. Humor can make your audience more receptive to what you're saying. A shared joke connects us. And when we all laugh together, even for a few seconds, it humanizes us. Laughter breaks down the social barriers that divide teacher from student, employer from employee, consultant from customer.

Don't be afraid to take yourself a little less seriously. This guy wasn't.

Of course, there's one very simple way to avoid losing your audience: Keep your stories brief.

We live in the Age of Information Overload; the Age of Distraction; the Age of the Sound Bite; the Six-Second Video on Vine. If you want to crawl inside your audience’s head and stay there, you’ve got to be as small as possible.

If you ramble on and on, if you include too much detail or irrelevant information, then your audience’s attention will wander and they’ll start checking their iPhones, like I’m betting some of you are right now.

(It’s ok; we all do it.)

“Brief” does not mean “lacking in information or effectiveness”. There's an art form called six word stories. Here’s an six word science fiction story that's positively brimming with existentialist mystery:

When giving technical information, stop and think: Does my audience really need this piece of information right now? Or does it distract from my point? Is it an essential stop on my journey, or merely a side-road?

Edit yourself.

Trim your stories down to the bone.

Brevity.

Before concluding I’d like to mention what I consider to be one of the most successful technical-education sites in existence: Randall Munroe's XKCD. We've been talking about sanitizing database inputs, so I thought I'd let him have the last word.

For clarity I've only shown the last two panels, but really that's all you need. This is a masterpiece.

It’s brief.

It’s humorous.

It’s visual.

It teaches a lesson.

It doesn’t overexplain; it lets the audience do the mental work.

It’s approachable even by people who won’t understand it, and yet intriguing enough that they will ask to have it explained to them.

This is teaching. This is also Art.