All developers require a Developer Relations Programs to follow the “3 C’s” – Community, Code and Content. To this list of C’s I also add a few of my own: Collaboration, Continuity, Cooperation, Communication, Caring, Celebration, Civility, Consideration, Clarity, Conversation and Curiosity. In surveys, during conversations, in emails and as the most commonly asked webinar question, developers tell us that Code is King! Even though we provide documentation for SDKs, APIs, libraries, frameworks, systems and applications, the ultimate documentation is the source code itself. The Computer History Museum (CHM) collects the source code for great computer software programs and systems. Do you want to download the source code for MacPaint and QuickDraw created by Bill Atkinson? You can download them both and you can read the story behind the software too! I love what CHM is doing to preserve the source code artifacts of our industry’s history. Developers tell Evans Data that source code examples, sample projects and tutorials are some of the top requirements for a successful developer relations program. So, the question is, where should you put your sample programs so that your developer relations program members can find it, download it and use it?
Developer Relations – where to put your sample programs, tutorials and source code?
There are several places that Developer Relations programs put there source code. Some programs keep their code on their own servers (ftp or http access), some put code in public repositories and others put their source on code hosting sites. There are many sites to choose from including: Amazon S3, Microsoft Azure Storage, GitHub, SourceForge, DropBox, Cloud Forge, Box, CodePlex, Google Drive, Assembla, BitBucket, ProjectLocker, and LaunchPad. Most of these sites support the leading source code version control services including Subversion, Git and Mercurial. Some of the hosting sites will also provide additional tools and services like defect tracking, deploy/install, security scanning, and license compliance audits. Several of these sites are popular places to put open source software projects allowing the developer community to collaborate and enhance the sample code. Some of the sites also provide APIs (GitHub Developer for example) for you to automate interactions, search catalogs of entries, access control, and more. Other developer programs place source code on sites to make it simple to distribute and update the code. Most integrated development environments and programmer’s editors support pulling sample code from repositories.
Where do you put your Developer Relations program and products sample code?
Send me an email and tell me where you put your developer relations program code.
David Intersimone “David I”
Vice President of Developer Communities
Evans Data Corporation
I have given thousands of presentations to tens of thousands of developers in person and online webinars. It’s been great to be able to create and present a broad range of technical sessions, keynotes, webinars, hands on labs, briefings, etc. It’s also an honor and a privilege to talk and listen to developers while showing them new technologies, architectures, methodologies, compilers, frameworks, libraries and tools. One of the most important things that we can do in our developer relations programs is to help educate our members. Meeting and geeking with developers is always a shared experience for me as I learn as much from developers as I present to them. Sometimes I have the luxury of attending developer conferences and meetups and learn new, cool tech from other developers. What makes a great tech session? What do developers want to see and hear from a developer relations evangelist? Here are a few of the Developer Tech Session best practices, observations and ideas that I’ve learned over more than 30 years as an evangelist.
Giving a Great Developer Tech Session
Developers have told me what they look forward in a technical session. Developers are not shy or quiet. They will also tell me when one of my presentations didn’t live up to their expectations or doesn’t cover the topic.
- Have a clear session title, description, agenda, timing, prerequisites, use cases, expected audience (who should attend) and expected session outcomes (what they’ll see, learn and walk away with). Ensuring that the session information is clear and focused will set the stage for a satisfied developer audience. Of course there will always be a few developers who won’t read the session information in advance of your presentation.
- Developers want to learn cutting edge methods, technologies, architectures and best practices. Make sure that your presentation is as technically exciting and interesting to you as it will be for your audience. It’s always fun to be able to show cool products, cool technology and cool demos.
- Have more source code than slides. Developers love to look at code and dislike slides. My good friend Charlie Calvert would refuse to use a slide application and would instead put bullet points, images and notes on HTML pages and use a browser for the non-source code parts of his presentations. If you need to have a couple of slides, try to keep them to a minimum: title slide, agenda slide, an architecture slide or two and a final Q&A slide with your contact, short URL to your a blog post for your presentation and source code download information.
- For source code, make sure your development environment or programmer’s editor has a large clear font. For source code I use Lucida Console font with 14 point size (or higher if you are presenting in a larger room). If you are using an IDE also configure it with a “Source Code Only” layout option. If you are giving a webinar, use 1920×1080 screen resolution (your developer audience will have multiple high resolution monitors on their desktops). If you are giving a live presentation, know the size of the room, display your desktop with code and walk to the far reaches of the room to see if you can read the font.
- Prepare and practice, practice, practice for your developer technology presentation. Doing this will help you avoid some of the challenging demo issues, configuration settings and timing problems for your session. There is always the possibility that you will be hit by the “demo beast” and have to remark “that’s never happened before”. A mysterious bug or crash will also have happened to every developer attendee in the audience. Problems, hopefully only one, will show that you are human.
- Developers love to see and listen to a dynamic presenter. This doesn’t mean that you should run around the stage, crack jokes, rant, rave, wear goofy hats, etc unless they are relevant to your presentation. Your audience audience will enjoy your session when they see that you are really excited about the topic, technology, tools, projects, source code and techniques.
- Arrive early for your presentation, check the setup and configuration (especially if you have multiple computers, servers, devices and internet connections) and make one last pass through the slides and demos before you start your presentation. It’s always good to make sure that something didn’t change since the last night. Remind yourself to talk clearly, loud enough for the room and slowly (especially if audience members don’t speak the same human language as you, thankfully all programming languages and most libraries/frameworks have English keywords and function names). If you have consumed too much coffee, Red Bull, Mountain Dew Code Red, 5 hour energy drinks and other high octane beverages, take care to not over rev during your presentation.
- Turn off all of your popups, notifications, Skype, emails, alarms, screen savers, sleep/hibernate modes and other operating system and apps that will disrupt your presentation. Developers don’t want to read all of your instant messages, calendar alerts, etc. You probably don’t want them to see confidential information, meeting reminders, messages from your family either.
- Control the audience during your presentation. Don’t allow some attendees to take you and the audience off topic (they can come up afterwards to ask their specific questions). It’s okay to take some questions along the way, especially if your presentation has logical transition points. If you are going to cover a topic later in the presentation, gently reply to a questioner that patience is a virtue and what they are asking for is coming up soon in the presentation.
- Did I mention to show lots of source code? You can never explain the source code enough to a developer. It’s okay to type in code during your presentation. That’s what we as developers spend a lot of our time doing. This also helps the audience follow along and kibitz with you on typos and alternatives. I believe that it is also acceptable to open prebuilt projects as long as you explain the project and walk developers through the source code. It’s also okay to have snippets of code ready in a notepad, especially for some longer and complex code sections I doubt that they whole audience will sit there and watch you type in thousands of lines of code.
A Few Final Bits of Advice
If you are going to use some slides and other visuals here are a few additional bits of advice.
- Take care with your color sections for fonts. Some audience members may have a color vision deficiency for red, green or blue. I had presenter training early in my evangelism career and was introduced to Mr. “Roy G Biv” (Red, Orange, Yellow, Green, Blue, Indigo, Violet). For text color selections choose one from Roy and one from Biv. Green, Black, White and 50 shades of grey are okay to mix in.
- If you need to include Slides in your technical presentation – you should read Guy Kawasaki’s “10/20/30 Rule for Powerpoint“. Visuals can convey so much more that text for most slides. If you have to have bullet points with words, try to use the 4×4 rule – 4 bullet points with 4 words max each.
- Have a blog post availalble in advance for every presentation you give. Make sure there is an easy to remember ShortURL for your blog post. With the blog post you can provide links to additional information, resources, sample code and some of the questions asked during your session. You can always update the information omn the blog post for days, weeks and years after the presentation takes place.
- Give the audience your contact information including email address, twitter handle, SkypeID and blog URL. If you take the time to present and your audience takes the time to attend, you will be just at the first step in a mutually beneficial relationship.
Do you have other Technical Presentation advice?
Being a developer relations evangelist or team member is a great thig. We are on this software development and technology journey together. I love getting your presenter and attendee ideas and feedback.