I’m a good programmer, but I know many programmers who are much better than me. They are kissed by God, while I learned the trade by working hard. They did not read more books than others, and they didn’t memorize all design patterns. They just write an amazing code in any programming language. They easily pick up any language, library, or a framework. People call them 10X programmers, which are mythical creatures who look like us but are 10 times more productive.

But most of these 10X’s can’t share their knowledge with 1-5X’s. Moreover, some of them have hard times passing technical job interviews themselves. They just can’t explain what they know clearly. But I can. When I explain, people get it. I know this based the feedback I receive on my books, conference talks, blogs, and training classes. Let me share with you how I make myself clear.

If you present at the conference, don’t assume that some people in the audience already know some of the materials you’re about to present. Never ask, “How many people already know X?”. You are here to explain X, Y, and Z, and the description of your talk states that you’ll be explaining X, Y, and Z. Would you change your presentation of the fly just because 20% of the audience already know X and 10% know Y? I wouldn’t. It’s not fair to the rest of the audience, and you’ll get 70% of unhappy people and poor ratings of your presentation.

If you use slides during your presentations, they should contain a minimum of text. No need to be Steve Jobs and have one line per slide. Three-four bullets per slide are enough. A short code fragment per slide. If you need to show a large code fragment, split it into 2-3 slides explaining them gradually.

And please, please, please use a clear background on your slides. Any fancy background steals the slide’s real estate and destructs the audience. Typically, I use a plain white background and my twitter handle in the lower right corner.

And please stop using slides with faces of movie stars “saying” something about the subject of your presentation. And those video clips or animated GIFs should be gone as well. I know, you’re trying to be funny, but video clips won’t help in this department. Find another way. Have you ever heard something like, “It was a very well done presentation because the speaker included so many funny video clips in his slides”? Neither did I.

Timing is important. If you are a rookie presenter, rehearse your talk to see how much time you need. If you managed to fit your talk in 30 minutes, you’ll need at least 40 minutes during the real show. I don’t need to rehearse any longer but use the formula “2 minutes per slide”. In my talks, a 40-minute presentation means about 20 slides. It’s a rough estimate, and you should come up with the formula that fits your style.

If you don’t use slides and prefer live coding, you must prepare other materials that people can use after your talk. It looks so cool when a presenter is coding in front of the audience! But then the presentation is over, and what the audience is left with? Sweet memories? Prior to the presentation, make all the code samples available for download, and only after you can perform a live coding on stage. I know one excellent presenter who never uses slides but always gives supplementary materials to the audience. His name is Venkat Subramaniam, and you can check his website to see how to prepare code samples.

Don’t rush. If you have 40 minutes for a talk or a class, don’t try to spill on the audience everything you know. Stick to the subject and deliver what was promised.

Explain things right before using them. While teaching a programming language, framework, or a library, don’t cover the syntax constructs unless you show their use in scenarios that are easy to recognize. Try to find practical use cases where it makes sense to use these constructs. Unless you are teaching programming of complex specialized algorithms, your audience is interested in solving similar tasks, for example:

– Reading writing the data from a file or a server
– Displaying the data as a form or a table
– How to layout the UI
– How to cache and reuse the data
– Performing the task in parallel or concurrently
– Dealing with asynchronous code
– Avoiding race conditions
– Splitting a monolithic app into modules
– Lazy loading to minimize the user’s wait time
– Build tools to minimize the size of the deployment bundles
– Inter-communication between modules or components
– Implementing a handful of design patterns
– Object-oriented vs functional programming

If you prepare code samples illustrating some of the above tasks, people will be able to easily recognize some of their daily routines and compare how things are done in the software they use today vs the software you are teaching.

Don’t foobar the audience. “Let’s say we have this function foo() that created an object Bar”. Foo and Bar may not be easily understood by the audience. This is better: “Let’s say we have a function that calculateTax() and the class Person”. Examples must have an easy-to-understand meaning. Even this annoying ToDo list app is better than foobar.

If you are given a limited time, reduce the scope but explain things well. For example, if a conference offers a 40-min slot for each session, and you need more than an hour for covering your subject well, split your session proposal in two and ask for two slots.

Don’t let that smart guy from the audience steal your presentation. I always get a person in the audience who’s deep in the material of my talk. You know who am I talking about. Yes, that guy! He already knows the subject, and possibly better than you. If he asks a question that requires 5 min to discuss, spend 30 seconds to say “We can discuss it after the talk”. Most of the audience is not interested in hearing this discussion, and those 3 people who are, will stop by the podium after the talk.

Don’t explain two new things at the same time. A code sample must be focused on the subject of the explanation. For example, if you want to explain how to retrieve the data from the server for the web page, do not try to also explain how to make the data look pretty by applying CSS. Concentrate on making an HTTP request and showing the “non-pretty” data. When you’ll be explaining styling, don’t waste your time explaining how to make requests to the server. Show how to make a hard-coded data pretty. One step at a time. After explaining each concept or technique, show how to apply them together.

A red flag. It’s five minutes into the presentation, but the speaker is still talking about himself and his achievements. Stand up and leave. Attend another presentation because this one won’t get better. This presenter has not much to say on the subject and is simply killing time.

Re-reading your materials is a must. Each time you re-read the text you’ll be making it shorter. As someone (Blaise Pascal?) put it, “If I had more time, I would have written a shorter letter”. I have certain training classes that I teach over and over again, and I know my slides by heart. Still, before each class, I go through my slides and remove some text or simplify visuals.

If you’re preparing the materials for a workshop, always try to follow your own instructions putting yourself in the shoes of the student. Remember, it’s a new software for them. Is each step is clearly described? Split the step that requires long explanation into two or three steps, but keeps the explanations short.

If you prepared the workshop instructions a year ago, are you sure that they are still valid with the newly released version of the software you teach? You don’t want any surprises/fixes in the middle of the class.

Have a Plan B for a slow or non-existing Internet connection at the conference venue. Don’t even think of saying “If Presentation Gods will be good for me…” They won’t because you’re not special. Think in advance about running your presentation without the Internet connection. Then Presentation Gods will show up and your talk will go well.

If the audience would be using their own laptops, write clear pre-requisites for the software that has to be pre-installed before the class. But still, arrive in the class early because one of the guys may arrive with a corporate laptop that has only Internet Explorer 11. Have you explicitly requested the latest version of the Chrome browser or assumed that everyone has it? Assumptions are your worst enemy. Feel free to replace Chrome with whatever software must be pre-installed for your class.

And now comes the main advice… If you’re running a live training class to a relatively small group of people, closely monitor the eyes of your students. If they remain glassy, re-explain the topic until you see that aha-light in their eyes. Just asking if they have any questions is not enough as some people may be shy to admit that they need more time to understand the topic.

If you’ve read this far, you might be thinking, “You teach me to teach, but show me the money! Show an example of your teaching where you explain complex stuff in a simple language.” Will do. Here’s my free online book that explains Java programming to kids and their grandmas. And this is my free video course on Java programming for adults.

I hope you found a useful thing or two in this article. It may not make you a good explainer overnight, but if you will apply these rules consistently, you’ll start getting compliments on your presentations, teachings, or writings!