Mobile development is hot, and attracts the interest of both entry-level and experienced developers alike.
At some point in your mobile development career, you’ll likely be asked to share your expertise with others. If you’re not a teacher, the task can be quite daunting.
Am I advanced enough to help others?
How can I choose a topic that’s appealing to a wide range of people and skill sets?
What if my talk is boring?
I have given a series of talks at the Boulder iOS Meetup, Boulder Solid State Depot maker space, and Boulder/Denver Women Who Code Meetups. Here are the lessons I learned in giving talks and teaching workshops. Hopefully, they will help you.
My strategy follows from basic principles: each audience member or student has a different interest in understanding the material and a different skill level they bring to the table. These talks are not in mandatory classroom settings, so it is important to keep the participants engaged. You can do this by customizing the talk, asking questions before the presentation, observing responses during the presentation, and by not just reading slides.
Talks are the simpler case, because each participant can passively draw what s/he wants to obtain from the experience. However, you should still try to determine a level of understanding and interest in the various topics, so you can adjust the presentation on the fly.
For example, my own particular interest is the intersection of hardware with iOS devices. This combines electronics hardware with software development, so hardware is a big part of my speaking. However, many software engineers listening to talks are 100% pure software people, and do not know anything of hardware. In a CoreBluetooth talk, I designed a very simple custom piece of hardware (indeed, something I just threw together with parts laying around my lab). As the Boulder iOS developer meetup is very skilled in iOS development, hardware was my big issue for customization. Therefore, I devised a list of questions relevant to the electronics of the talk. In an audience of about 40 people, I asked, “How many of you…”
- Have heard of Arduino (all hands go up)
- Have heard about Bluetooth 4.0 Low Energy (all hands)
- Know what signal modulation is (about 7 hands go up)
- Know about analog-to-digital convertors (3 hands)
- Know about pulse width modulation (2 hands)
- Know what a Darlington pair of NPN transistors is (1 hand)
Based on this information, I discussed hardware for about 10 minutes and software for about 40 minutes (regarding CoreBluetooth). In the end, I had a bunch of positive feedback from people with an electrical engineering background who were really happy that software was presented to them in a way that intersected with their expertise. A lot of software people were also happy to learn about hardware in their own realm of expertise. Some of the 100%-software developers (more about them later) thought 10 minutes of hardware in a 50 minute talk made the talk hardware heavy. In contrast, when I gave the same presentation to people who were hardware oriented, I spent a fair amount of time explaining Objective-C syntax (this was not a problem since they comprehended the hardware aspects virtually instantly, and also understood the fundamental design patterns seen in the software API virtually instantly as well).
By workshop, I mean leading people through a tutorial to do something basic in the platform you’re discussing. These are more challenging because attendees usually want to actively participate. Therefore, you need to do something to keep people engaged. This is a balance between not boring the advanced students and helping less experienced students get satisfying results.
I have seen the following three types of experience in my talks and workshops for the Women Who Code Boulder/Denver:
- Non-technical people learning development as a technical discipline for the first time. Perhaps they have already experimented with some other software development, but not to a great extent. They may need extra assistance (preferably, from another participant in the workshop) to get very explicit step-by-step instructions to understand the logical process of software creation. This is a great opportunity to introduce students to new ways of thinking, which is something I personally enjoy.
- Technical people, such as (non-computer) scientists or (non-software) engineers who aren’t necessarily programmers yet, but who have the sequential and logical mindset that lets them analyze and learn things like programming quickly. Perhaps they even have some scripting experience in computational science or engineering settings. Physics and math are typical sciences for which software developers have affinity, but don’t discount the logical lessons taught in other sciences such as biology and chemistry. Physical chemists have a significant math background from quantum chemistry and statistical mechanics, and even computational chemistry. Biochemists have to know a lot about step-by-step procedures that happen in cells, and often have knowledge of algorithms for computational biology tasks.
- Software developers coming from other environments that are not mobile. They can be quite experienced in their respective areas of technical expertise. Objective-C, Cocoa, iOS, battery and network performance optimization, and mobile development user experience design can be new to them. For these people it is best to be prepared for questions in the format of “Why do (or don’t) you do X in iOS?” if you can. Also, for people who have lived 100% in the software world with languages that are designed to insulate them from hardware specifics, learning hardware-specific optimization techniques can be a new experience.
Similar to talks, you should try to come up with a list of about three or four questions to which people can answer “yes” or “no” with raising of hands, so you can determine a baseline level of experience for the audience. Then, you adapt.
Trying to keep everyone in all of these groups occupied can be a challenge. There are a few tricks I use to keep this manageable. First, I make use of screen zooms and repeat directions two times during a workshop. Second (and luckily) one of the best ways to engage someone in the learning process is to get them teaching, and I have found that my students generally enjoy this.
Also, paying attention to subtle cues of body language can give valuable insight into how people are progressing. For example, cues you can look for include:
- Squinting closely at the monitor with a quizzical expression: these people probably need help.
- Leaning back in their chair, with hands off keyboard looking at me: these people are ready for the next step and remain engaged.
- People without a computer open but still watching me and others in the room: these people are spectators, but remain interested and engaged.
The people who are ready for the next step can often help the people who are lost. For those truly lost, you can step in, but this drags the presentation time along and is something I try to avoid. In addition, if you ever get the opportunity, it’s a great advantage to have a teaching assistant for every four students in iOS workshops.
Reading slides is B-O-R-I-N-G
In my talks, I try to invite audience participation. For example, in the Bluetooth talk, I had someone hold the device for a demo, and someone else run the demo app (scary for me the presenter, and the audience can see that, and it adds suspense).
As an example, for the workshops, I used a whiteboard to explain concepts of memory management, ARC, and retain cycles.
This instantly perked the audience up.
Also, whiteboards allow you to create a shock absorber of sorts, where you can adapt information directly for a particular audience.
Basically, the essential lessons I have learned from all these teaching experiences is:
- Know the core essentials of the material you are discussing inside and out.
- Keep extra information surrounding that core in the back of your mind to add or subtract according to your audience.
- Don’t just read slides. Get the audience working with each other. Get in front of a whiteboard. Have someone else drive your demo, if you are brave 😉
Update, 21 July 2014: Kelly at kiodev.com gave a presentation to the Women Who Code Meetup in Denver about Google Glass development. I personally attended and enjoyed the talk. She posted here ideas on giving a good talk and referenced this “Mobile DevelopMent Presentations that Engage Audiences” in her blog post. It is great to see that this post helped someone else give a talk!
For more insights, please subscribe to our email list at the bottom of the page (under the comments)!