Tag Archives: presentations

The Discovery Channel Test

Presentations can be boring. Talking about your work can be boring (to other people). When you’re sitting in a talk or a session that you find boring (and you can’t figure out WIIFM – what’s in it for me)… you learn less.

Although we shouldn’t have to use clickbait techniques to satisfy societally decreasing attention spans, it is easier to learn and retain information when it’s interesting. So I encourage all of you to apply the “Discovery Channel Test” to every presentation, talk, or session you contribute to or lead.

The reason I call it the “Discovery Channel Test” is that there used to be a program called City Confidential that was on all the time. Even though City Confidential was a show about murder mysteries, the first half of the one-hour show was about the city or region where the crime occurred. They talked about when the town was first settled, and key families who made the town what it is today. You heard about stories of intrigue, and challenges the town was facing today. They made the story about the town itself so captivating that EVERY SINGLE TIME I was caught off guard when they ended the first half-hour segment with “You’d never believe a murder could happen here.” Through the hundreds of times I watched this show, I was always shocked when this point came. “Oh, yeah… this is where that murder mystery happened, and we’re about to find out about it.”

Any production crew that can spend a half hour off-topic, keep me interested, and give me a dopamine burst right before the main point of the show… has achieved something great. And you, too, can achieve this same greatness when you’re talking about your tech stack or a new architectural initiative or that project you did last year that improved customer sat. Make it interesting by applying….

The Discovery Channel Test (* = could also be called The Good Podcast Test)

Rule 1: Use an emotional hook up front. Why should any of the people in your audience not leave after the first five minutes? Don’t make them guess! Tell them specifically why this topic might be interesting, or surprise them with an initial feeling of novelty or unexpectedness. Jonathan Lipnicki’s character in Jerry Maguire (1996) was great at this, with his “did you know?” questions. The dopamine surge you create with an emotional hook will keep them engaged for long enough to get hooked on your story.

Rule 2: Find the wow nugget(s). This is one of the things the Discovery Channel has always been really good at: getting me interested in things that I didn’t think were interesting to me. Remember that your projects and initiatives, no matter how cool they are to you, will be boring to other people unless you TRY to make them interesting. I try to tell my high schooler that even in the most boring classes you should be able to find some nugget, some angle, some insight that helps you see the subject matter in a way that grabs you. Find that angle for your audience, and then spoon feed it to them.

Rule 3: Use examples, screen shots, visuals, diagrams. If your presentations are full of slides with words, people will start yawning immediately and may or may not actually hear those words. You can also reduce ambiguity with examples and screen shots. For example, saying “we used Python for this project” is far less compelling than showing the tree structure of the code (or a simplified diagram) and annotating it with what each piece did to get the overall job done. Saying “we used Confluence” is less compelling than saying “we set up a confluence site at [this location] and agreed to put [this kind of information in there]” because if someone has a need for [that information] – at least they know a first place they can look for it.

Rule 4: Spoon feed the closing thoughts. At the very end, remind people what you want them to remember when they leave. Remind people why that’s interesting, and how it might benefit them in the future. Make it concrete and tangible. For example, can you give them reference material, or an infographic, or a checklist that they can use in the future? Don’t assume that people will get something out of your presentation just by attending… spoon feed what you WANT them to get out of it.

Improving the Quality of Your Writing

blacked-outMorgan and I work with students to produce written reports all the time. Sometimes, they’re working on their senior capstone project, which culminates in a formal written thesis… other times, they are working on shorter reports. Ultimately, the goal of writing is to produce an artifact that will effectively communicate a specific message to a specific audience. What people don’t as easily recognize, however, is that for this to occur — the audience has to understand what you’re trying to say.  Since we’re academics, we write all the time (sometimes well, and sometimes badly). We’re used to writing one draft, and then another, and then another… serving as our own worst critic every time we pick up the paper with fresh new eyes. Sometimes, we benefit from the critiques of an external reviewer, and when we hear what they have to say — more often than not, we say “yep, I didn’t do that part well… I’ll try again.” And then we try again and again, never really getting it perfect, but sometimes getting it close.

What follows are some comments Morgan provided to one of our students after the student submitted a portion of a thesis draft for us to review. We quickly realized that we could give almost all of our students the exact same advice. So here are some tips to help you improve the quality of your writing… and it usually starts with eliminating most of what you started with.

Let’s start with the quality of your writing. This feedback may come across as harsh, but it is not intended to be so. Please rest assured that Nicole and I have your best interests at heart, and since this is perhaps one of the last opportunities you’ll have in your educational career to get detailed, personal feedback on your writing, we feel it is our responsibility to be blunt and honest with you. This may be your last chance to really work to improve before you enter a professional setting. So you might want to brace yourself because this may sting.

Okay, here’s the bad news: your writing is shockingly bad. If I didn’t know better, I would be convinced that English is not your native language. If you were to write like this in a professional setting, you would certainly embarrass yourself and it might actually damage your career.

The good news is that you can improve and we’re going to help you. Before I make specific guidance on your draft, I’d like you to take the first stab at revising what you’ve written so far. Here are your instructions. Please follow them closely.

Do not spend any time apologizing to us, or making excuses for your writing. Everyone starts somewhere. You need to not be self-conscious, and be open to really working on getting better.

Stand or sit in front of a mirror and read what you wrote out loud to yourself. I’m totally serious about this. It may feel silly to you, but it will help tremendously. I know from talking to you that you talk and communicate like a totally normal person. I also know from experience teaching many people that it is not uncommon for people, who can have normal conversations, to totally fall apart when they try to communicate in writing. As you read your paper to yourself, imagine that you are listening to someone else read this paper to you and that it is not your own work. Trust your gut. If it sounds weird or bad, it probably is.

Every time you hear a sentence that sounds strange, put a mark on the paper to indicate that the sentence needs to be revised, but don’t make any changes yet.

Once you’ve read the whole paper out loud to yourself, go through the paper again. Read each sentence one by one and ask yourself the following questions:

  • What was the purpose of this sentence?
  • What vital information does it convey?
  • Could it be said in a much simpler, more direct way?
  • If I erased this sentence altogether, would it change the meaning or impact of the paragraph?
  • What was I trying to say? Listen to the words that just came out of your mouth when you answered that question. Why didn’t you just say that?
  • Is there anything else I could do to improve this sentence?

If the answer to questions 1 and 2 are “I don’t know” or “none” then you should delete the sentence. If you get to question 3 and the answer is “yes” then revise the sentence to make it shorter and more direct. For question 4, read the whole paragraph leaving out this sentence. If the meaning of the paragraph doesn’t change, then delete the sentence. If the sentence is still there and you get to question 5, then make any final changes and move on.

You might find that you need to revise earlier sentences based on changes you make on later sentences. It’s okay to go back.

As you do this, don’t be discouraged. Persevere. This should be tough, but I think you’ll find several things:

  • Your draft will probably be 50% shorter without losing any meaning. This is a GOOD thing!!!
  • It will feel much better and be much easier to understand, both for yourself and for other people.

Here are a couple of other pointers:

  • Don’t use an inflated font size.
  • I know for a fact that the default font size in Google Docs is not 14. Just stick to the default, which is 11. Regardless of whether this was your intention, boosting the font size makes it look like you’re trying to make us think you wrote more than you did. Since shorter is better, this doesn’t help you in any way.
  • Stick to single spacing.
  • Again, stick with the default. You can take care of formatting the document at the very end, after you know that you’ve got the content right.

A lot of this restates the feedback we give you in every one of the classes you’ve taken with us. Keep it simple. Keep it direct. Only include a sentence if it really adds something to the narrative.

Unless they really convey something crucial, leave out images for the time being. Don’t include images just to make the report “look pretty” or to take up space. Pretend you’re writing for Wikipedia. Include the facts, just the facts, and nothing but the facts. Don’t embellish.

Don’t try to make it fluffy or sound like marketing. Keep it clean. Keep it objective.

Okay, whew. I know I’ve just thrown a lot at you, but stay positive. My goal is not to tear you down, but to support you in getting better. This is uncomfortable sometimes. You are working on really amazing stuff and I have confidence in you that you can do something that we’ll all be proud of. Hang in there!

Good Tutorials and Bad Tutorials

Are you leading a workshop or tutorial at a conference? In this post, find out how to make your 1.5-8 hour session meaningful, enjoyable, and high quality.

I’m thinking a lot about how (and how not) to execute a successful tutorial session today. Why? Because I’ve spent 8 hours today in 2 tutorials, and with 25 minutes left to go, I now know that I have wasted about 6.5 of those hours. I want to save you those 6.5 hours in the analog of your life. I could have been doing some productive activity that I would feel great about – but my investment of time in tutorials has come up short. Note that all of these sessions have been about how to use software, computing, or cyberinfrastructure resources.

Characteristics of the 1.5 hours I spent well in these tutorials: I played with code that I was scared of before. I heard why certain tools, utilities, modules and packages could help me – and then the presenter helped get me over the barrier to entry. I was told what I needed to start out with (e.g. the data format, and the “substance” in that data that I would need if I were to use the software), the steps I would need to take to crack open that data and do something useful, a menu of what I might want to try later if I was so inclined, and most importantly – the “what’s in it for me” statement. I now know 2 or 3 new resources I can use, and why I might want to try them. (Doesn’t matter that I don’t have any occasion right now to use them – I’m empowered for the future.) I feel better and more confident about my skills in some areas.

Characteristics of the 6.5 wasted hours: I saw a lot of pictures about what other people’s software can do. I saw no mapping of what can be done to how to do it. I got a lot of explanations of syntax that mean nothing to me without the context of how I am actually going to use it. I heard lackluster stories about programmers in other people’s organizations. I saw long lists of attributions of who did what work, and no idea of why that is useful to me or anyone else. I see a lot of code on the screen, and yet I can’t touch it. Plus, I’ve learned so many computer languages over the past 20 years that I don’t need to know any more syntax… I know the main components are working with file I/O, processing and analyzing data, and storing and then retrieving it. Give me a “quick start guide”. This is all very impressive – these people have done a lot of work and it’s very complex – but I just don’t know what I can do with it. NOR do I know how I can help colleagues who might need to know this stuff – I wouldn’t know how to recognize the opportunity. Most critically, I don’t have any idea about the execution environment. How about you step me through a “Hello World” to give me a feel for how to run the examples?


  • Make your tutorial simple and multi-modal (pictures + examples + lecture + team activity maybe). Hands-on is good.
  • Tell people what’s in it for them; set their EXPECTATIONS
  • Tell people what they need to start with (e.g. input data) to flesh out those expectations
  • Tell people what ACTIONS they can take (what new commands can they type into their computers now??)
  • Tell people how they can learn more, and SUSTAIN their learning
  • Then let them know what they’re going to get in the end; help them learn how to EVALUATE their progress.
  • Give them something to take away with them, like a quick-start guide, or a new app installed on their laptop that they will be happy to play with when they get home.

And remember to speak up. Technical stuff can be dry, so a nice consolation prize for a dull tutorial is a pleasant speaker with a good voice.

* * *

Important Addendum: I’ve now had over 48 hours to reflect on my tutorial experience and let it all sink in. The impression that will stay with me? That the first tutorial I went to was awesome, and the second ones were not. Note that I balked from the initial “second tutorial” I chose and tried out another one with no luck. Looks like the 1.25-1.5 excellent hours in the first tutorial have now colored my whole experience of it, and I will only remember the awesome parts. The second tutorial(s) are kind of vacuous to me at this point – I just can’t remember anything about them.