28,79 €
Mehr erfahren.
- Herausgeber: Packt Publishing
- Kategorie: Wissenschaft und neue Technologien
- Sprache: Englisch
A collection of in-depth conversations with leading developer advocates that reveal the world of developer relations today
Key Features
- Top developer advocates reveal the work they’re doing at the center of their tech communities and the impact their advocacy is having on the tech industry as a whole
- Discover the best practices of developer advocacy and get the inside story on working at some of the world’s largest tech companies
- Features contributions from noted developer advocates, including Scott Hanselman, Sally Eaves, Venkat Subramaniam, Jono Bacon, Ted Neward, and more
Book Description
What exactly is a developer advocate, and how do they connect developers and companies around the world? Why is the area of developer relations set to explode? Can anybody with a passion for tech become a developer advocate? What are the keys to success on a global scale? How does a developer advocate maintain authenticity when balancing the needs of their company and their tech community? What are the hot topics in areas including Java, JavaScript, "tech for good," artificial intelligence, blockchain, the cloud, and open source?
These are just a few of the questions addressed by developer advocate and author Geertjan Wielenga in Developer, Advocate!. 32 of the industry's most prominent developer advocates, from companies including Oracle, Microsoft, Google, and Amazon, open up about what it's like to turn a lifelong passion for knowledge sharing about tech into a rewarding career. These advocates run the gamut from working at large software vendors to small start-ups, along with independent developer advocates who work within organizations or for themselves.
In Developer, Advocate!, readers will see how developer advocates are actively changing the world, not only for developers, but for individuals and companies navigating the fast-changing tech landscape. More importantly, Developer, Advocate! serves as a rallying cry to inspire and motivate tech enthusiasts and burgeoning developer advocates to get started and take their first steps within their tech community.
What you will learn
- Discover how developer advocates are putting developer interests at the heart of the software industry in companies including Microsoft and Google
- Gain the confidence to use your voice in the tech community
- Immerse yourself in developer advocacy techniques
- Understand and overcome the challenges and obstacles facing developer advocates today
- Hear predictions from the people at the cutting edge of tech
- Explore your career options in developer advocacy
Who this book is for
Anybody interested in developer advocacy, the impact it is having, and how to build developer advocacy capabilities
Geertjan Wielenga is a developer advocate who promotes Java and JavaScript as a speaker, writer, and trainer. He graduated from the University of KwaZulu-Natal with a degree in social science and a postgraduate degree in law. Geertjan has worked in Austria, the Czech Republic, and the Netherlands for firms including Sun Microsystems and Oracle. Now a senior principal product manager at Oracle, he advocates the open-source projects Apache NetBeans and Oracle JET.Sie lesen das E-Book in den Legimi-Apps auf:
Seitenzahl: 839
Veröffentlichungsjahr: 2019
Ähnliche
Developer, Advocate!
Conversations on turning a passion for talking about tech into a career
Geertjan Wielenga
BIRMINGHAM - MUMBAI
Developer, Advocate!
Copyright © 2019 Packt Publishing
All rights reserved. No part of this book may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, without the prior written permission of the publisher, except in the case of brief quotations embedded in critical articles or reviews.
Every effort has been made in the preparation of this book to ensure the accuracy of the information presented. However, the information contained in this book is sold without warranty, either express or implied. Neither the author, nor Packt Publishing or its dealers and distributors, will be held liable for any damages caused or alleged to have been caused directly or indirectly by this book.
Packt Publishing has endeavored to provide trademark information about all of the companies and products mentioned in this book by the appropriate use of capitals. However, Packt Publishing cannot guarantee the accuracy of this information.
Acquisition Editors: Dominic Shakeshaft, Jonathan Malysiak
Project Editor: Kishor Rit
Development Editor: Joanne Lovell
Technical Editor: Saby D’silva
Proofreader: Safis Editing
Indexer: Pratik Shirodkar
Production Coordinator: Sandip Tadge
First published: September 2019
Production reference: 1270919
Published by Packt Publishing Ltd.
Livery Place
35 Livery Street
Birmingham B3 2PB, UK.
ISBN 978-1-78913-874-0
www.packt.com
"I dedicate this book to Bob Gembey and Rick Tersmette, who started my journey in the technology industry, in 1996, when I had no idea what I was getting into and no way of knowing how interesting it was going to be."
Contents
Introduction
Introducing the Author
How to become and how to be
Scott Davis
Introducing Scott Davis
The advocacy versus evangelism debate
Scott's path to advocacy
Getting up on stage
Scott's hot topics
Moving away from pure programming
When technical glitches hit
Travel management tips
Changing your mind about tech
Ted Neward
Introducing Ted Neward
The value of attending conferences
Being headhunted
Ted's advocacy journey
Finding a developer relations job
The downside to developer relations
The dilemma of authenticity
Being put on the spot
Sally Eaves
Introducing Sally Eaves
Sally's advocacy work
The power of blockchain
Making tech solutions relatable
Sally's views on authenticity
Kirk Pepperdine
Introducing Kirk Pepperdine
People who are suited to advocacy
Kirk's style of advocacy
The increase in conferences
Using psychology to solve problems
The advantages of being independent
Kirk's experience of technical glitches
Juggling family life
Suffering from burnout
Rabea Gransberger
Introducing Rabea Gransberger
Rabea's ideas for talks
Attending conferences
Running a user group
Knowing when to retire a talk
Freedom at work
The qualities of a good talk
Receiving feedback on your talk
Dealing with technical glitches
Knowledge gained from conferences
Rabea's view of developer advocates
Encouraging more people to attend conferences
Laurence Moroney
Introducing Laurence Moroney
The importance of job titles
How AI is developing
Fear of AI
Working for a large company
Empathy when advocating
Tips for new starters
Scott Hanselman
Introducing Scott Hanselman
Scott's path to Microsoft
Handling the bad headlines
Achieving a work-life balance
Scott's areas of interest
Not knowing an answer
Heather VanCura
Introducing Heather VanCura
Heather's path in tech
Connotations of "evangelist"
Heather's ambitions as a young person
Variation in the role
Challenges faced by women in tech
The fear of not knowing enough
The pressures of the job
Connecting through social media
Matt Raible
Introducing Matt Raible
Choosing a job title
Matt's career path
The qualities needed for advocacy
The social side of conferences
Not being confident enough
Technical difficulties during a talk
Successful talk titles
Matt's stage outfits
Knowing when to stop
Tracy Lee
Introducing Tracy Lee
Helping companies
Developer relations as a service
Tracy's conference topics
The rise of developer relations
Simon Ritter
Introducing Simon Ritter
Getting into developer advocacy
Competition in the advocacy sphere
Comparing advocacy to evangelism
Navigating technical failures
Simon's advice for young people
Being authentic while working for a company
Simon's demo ideas
Travel adventures
Mark Heckler
Introducing Mark Heckler
Becoming a developer advocate
From engineering to advocacy
Mark's talk topics
Diversity in tasks
Negative aspects of advocacy
Quitting your job
Honesty about bugs
Handling unexpected questions
Jennifer Reif
Introducing Jennifer Reif
Jennifer's introduction to advocacy
The appeal of developer advocacy
Consuming information
Jennifer's average day
Ethical considerations
Being an introvert
Managing technical failures
Jennifer's tips for young people
Venkat Subramaniam
Introducing Venkat Subramaniam
Developer advocacy and students
Venkat's motivation
Solving a problem
The importance of user groups
The fear of not knowing enough
Venkat's conference topics
Ivar Grimstad
Introducing Ivar Grimstad
Ivar's ideal job
Finding success
Difficult questions
Managing controversy
Making use of Twitter
Regine Gilbert
Introducing Regine Gilbert
Regine's career path
Different avenues in the IT industry
Accessibility awareness
Regine's future projects
Tim Berglund
Introducing Tim Berglund
Debating job titles
How Tim got started
If you don't want to be a conference speaker
Requirements for being a developer advocate
Tim's tips for progressing to advocacy
Being open about bugs
An average day for a developer advocate
Taking a break
The progression of developer relations
Career options for developer advocates
Ray Tsang
Introducing Ray Tsang
Ray's path to developer advocacy
The appeal of advocacy
Managing jet lag
How Ray prepares for a talk
Where to go for information
Battling technical issues
Honesty when doing a demo
Tori Wieldt
Introducing Tori Wieldt
Tori's day-to-day work
Knowing your audience
The right personality
Having the confidence to get started
When to talk about competitors
Disagreeing with your company
Andres Almiray
Introducing Andres Almiray
Talking to developers
Andres' conference topics
Developer advocacy's recent growth
Experts in your audience
Travel advice
Arun Gupta
Introducing Arun Gupta
The spin doctor comparison
Requirements for success
Allocating resources
Arun's experiences at large companies
Tips for getting started
Josh Long
Introducing Josh Long
Josh's introduction to developer advocacy
Making an impact
Criticizing competitors
When you disagree with your company
Conflict between developer advocates
Josh's busy travel schedule
Spreading yourself thinly
Trisha Gee
Introducing Trisha Gee
Raising the profile of developer advocacy
Trisha's advice for aspiring speakers
Being involved with open source
Advocacy and spin doctoring
Remote working
Burnout in the industry
Travel difficulties
Using social media
Trisha's areas of interest
The career path for advocates
Bilal Kathrada
Introducing Bilal Kathrada
Encouraging young people
The risk of burnout
Baruch Sadogursky
Introducing Baruch Sadogursky
Developer relations conferences
Personal qualities needed
Caring too much
Baruch's hot topics in tech
Mary Thengvall
Introducing Mary Thengvall
Mary's background
Advice for young people
Mary's podcast
Answering difficult questions
Avoiding burnout
Yakov Fain
Introducing Yakov Fain
Yakov's job title
Getting leads from conferences
Speaking honestly on stage
Traits needed to be a good speaker
The problem with live coding
Yakov's motivation
The ideal job
Patrick McFadin
Introducing Patrick McFadin
The growth of developer advocacy
Building a personal brand
Patrick's route to developer advocacy
Proving your worth
Career development
Reza Rahman
Introducing Reza Rahman
Defining developer advocacy
Facing an ethical dilemma
The knowledge needed to advocate
The problems with social media
Reza's core message
Adam Bien
Introducing Adam Bien
Keeping things simple
Being independent
Adam's route to public speaking
Getting project requests
Bruno Borges
Introducing Bruno Borges
Developer relations as a strategy
Winning the fight in companies
Starting your advocacy work
Jono Bacon
Introducing Jono Bacon
The history of developer communities
Making a connection with revenue
Other Books You May Enjoy
Index
Packt
Landmarks
Cover
Index
Introduction
Introducing the Author
Geertjan Wielenga was born in the Netherlands and moved with his family at an early age to South Africa. That was because, ironically, his father was appointed by his church as an evangelist in South Africa, just as his son was to become an evangelist, though of a very different kind, over the course of his career in the software industry.
After completing his university studies, which were focused on political science and legal studies, Geertjan left South Africa in 1996 with the intention to travel for a year before resuming his direction in the legal domain. However, he soon found that he needed financial resources to sustain his travels and found himself editing and proofreading technical software manuals in the Netherlands from May 1996 onwards. A series of technical writing stints followed, in a variety of software organizations in the Netherlands, followed by several years in the same domain in Austria and the Czech Republic.
In Prague, he worked for Sun Microsystems from 2004 until its acquisition in 2010 by Oracle. He wrote documentation for NetBeans IDE, while writing and delivering training courses on the NetBeans APIs. He traveled all over the world introducing large organizations to the benefits of building their enterprise software on top of the NetBeans Platform. With the takeover by Oracle, he became a product manager focused on the enterprise JavaScript ecosystem and increasingly specialized in Oracle JET, which is Oracle’s free and open-source JavaScript toolkit for frontend user interface development.
His enthusiasms in the software domain have concentrated themselves around the open-source ecosystem and in unlocking the resources that large vendors have for supporting education and open-source ecosystems.
Over the years, he’s also informally engaged a number of developer advocates around the world in conversations around their profession, which has led to this book, which he hopes you, the reader, will benefit from and that it will inspire new developers to broaden their perspective on interesting and fulfilling ways of working in the information technology industry.
How to become and how to be
For years, I've been walking around with a growing set of questions to ask the many friends I keep running into on the stages of tech conferences around the world. An example is "How did you get started on the journey that brought you here?"
Inevitably, that journey can only have been uniquely inspiring, since the people you see on the stages of tech conferences, or hear about working behind the scenes to create content to share technical knowledge of various kinds, can't have taken a degree or followed a developer advocate course, because those degrees and courses don't exist or to the extent to which they exist today, they didn't exist at the time these journeys began.
Developer advocacy, broadly referred to as "developer relations" today, is new. Those who practice it have fallen into it in one way or another. And, just as the processes and theories in the world of programming have evolved over several years as programming itself has become a more generally accessible profession, so too the ideas underpinning developer advocacy have come to the surface gradually over time.
This has been as a result of the work that developer advocates have been doing out in the wild using their own initiatives.
Aside from exploring these areas, I've also had a range of questions up my sleeve around the day-to-day existence of people who find themselves in this role. In the modern world, the concept of getting up at a set time and going to an office where work is done until a set time is increasingly less common.
That is even more the case for the inherent itinerancy of the developer advocate's lifestyle, which is frequently precisely the reason for choosing it or for sticking with it in cases where the choice was not so explicitly made. For those interested in or even less aware of this profession, the various ways in which a life can be lived is also something that I wanted to explore.
A third set of concerns I've had for years, and that I've bothered many with over beers at conferences around the world, relate to the ethical dilemmas of the developer advocate role. Though every role inevitably has its own dilemmas, those connected to developer relations are particularly specific, since the role itself is not so clearly defined. Where does your allegiance lie? Clearly somewhere between a community and a company, but where exactly? If the answer is that it shifts from case to case, how can the humble developer advocate understand the path to take? At the same time, many developer advocates don't have this dilemma or intentionally eschew it by working independently, which brings its own set of challenges.
I've been collecting questions around these themes and when I met Dominic Shakeshaft from Packt, who told me about a series of books being put together around interviews in the tech domain, it was clear that I finally had a channel through which these themes could be developed.
The book you're holding is the outcome of a lengthy process of working out questions, discussing them with Dominic and his team at Packt, sounding out developer advocates around the world, and finally, recording interviews with them. The team at Packt, and in particular Joanne Lovell, worked the interview transcripts into coherent discussions, while Kishor Rit managed the process and Jonathan Malysiak rounded off the work and helped to guide the project to its release.
To be perfectly honest, I worked on this book simply to answer questions for myself and to find out how others in this domain struggle with the questions that I've personally been struggling with. Just like the vast majority of those I interviewed, I kind of stumbled into developer advocacy by chance and have wondered where it is that I've stumbled into and how to understand the world in which I've been working since the mid-'90s. In that sense, this book is not a collection of interviews at all; rather, it is a collection of conversations with myself, with each conversation bouncing off a different developer advocate, in some shape or form, while I reflect on a set of questions that are of concern to me at the time of the conversation.
There was a time, not all that long ago, when you would choose a profession in your teens or early 20s, study in that direction, and then work in that domain, in one way or another, all your working life.
In today's economy, that is far less the case and millennials have no problem switching from one domain to the next, or from one service platform to the next, without much concern for what they'll be doing next year or in the next decade.
Flexibility is becoming, to the extent that it hasn't been already, the norm. In this sense, the role of developer advocate is interesting in that those working in this field have already been working in the flexible-millennial way over the last few decades. One could argue that it is a profession whose time has come. It is a profession for our time, for now, while those engaged in it come from a generation slightly previous to that.
Underpinning each conversation that I've had in the context of this book is passion and enthusiasm. A framing that was suggested initially by the publisher was that of "spin doctors," that is, the central questions to be dealt with in this book would have been "Who are these people? How honest are they really? Are they pretending to be one thing while actually being another thing?"
I fought quite hard against this framing, since in my experience, everyone involved in developer advocacy is genuinely authentic and simply wants to share their enthusiasm and the hard-fought knowledge that they've acquired around a tech domain. The questions for me, increasingly, became "How can these people be so passionate? Where does that come from? How do they sustain that? Isn't it amazing that knowledge sharing can be turned into a profession?"
Somewhere underneath the conversations in this book, everyone appears to be asking themselves, in wonder, how it can be that they're being paid to have fun and to share that fun experience with others.
It is enthusiasm that drives all of them, whether they're working independently or for a company of one form or another. They're mostly a little bit concerned that when their employer, if they have one, discovers how fun their working life is, they might be given other less enjoyable work to do. Essentially, everyone in this book is a child-like explorer of a tech domain. Many domains in tech are not explored or are badly explored.
The people in this book are tinkering on the edges of new worlds, expanding them, documenting them, sharing them, and generally enthusing about them.
Another aspect is that of communities. Rather than working in isolation when exploring and extending a tech domain, the people in this book derive and sustain a large degree of their enthusiasm from working together with others, in many cases even being involved in establishing or leading developer communities. That enables all kinds of people, with every imaginable personality trait, to find a valid place in this world.
An interesting discovery for me has been that a lot of developer advocates consider themselves to be introverts. If you're regularly standing on a stage in front of hundreds of people, how can you possibly be an introvert? Well, consider that a stage with a lectern to stand behind, and all the people at a safe distance, simply interested in listening to something that you're passionate about, can be a very inviting place to be for an introvert. Also, of course, developer advocacy is far more than standing on stages—many involved in this field write blogs, articles, and technical tips and tricks, while also holding communities together through behind-the-scenes networking and interactions.
I'd like to thank everyone involved with this project at Packt and all those who took the time to engage in the conversations that make up this book. Several others could also have been included, of course, and hopefully there'll be more books around these themes where those not involved here can be included.
For example, there could be a book of conversations with the people who set up tech conferences. Why do they do it? How did they get started? What are some helpful tips and tricks? Another interesting angle could be people involved in driving open-source projects. What's the current state of open source? What has worked? What hasn't? How do you engage new people and keep them engaged?
Books of conversations can add new layers of authenticity to a topic. Reading the actual words about the experiences of those who live them brings unique insights and has the potential of conveying more deeply what it is that moves people to do the things they do and live the lives that they live.
With this background, I hope the conversations that follow will explain and inspire and maybe entice the reader to in one way or another get started or deepen their involvement in authentically sharing knowledge in general, though in particular around tech, which is so central to our lives today and inevitably will be in the future too.
Scott Davis
01
Advocacy is something that you feel compelled to do.Scott Davis
Introducing Scott Davis
Scott Davis is a web architect and principal engineer with ThoughtWorks, where he focuses on innovative and non-traditional aspects of web development. He was also the founder of ThirstyHead, a Denver-based training and software development consultancy, where he became convinced that having the freedom to be honest about a product was the only way to speak about it with real enthusiasm. Scott has written a number of articles and books about web development and over the past 10 years has built a reputation as a hugely engaging keynote speaker on developer advocacy. Find Scott on Twitter: @scottdavis99
Geertjan Wielenga: To begin with, do you consider yourself to be a tech evangelist or a developer advocate, or something along those lines?
The advocacy versus evangelism debate
Scott Davis: We could spend our entire conversation simply unpacking the politics behind those two phrases. I prefer "advocacy" over "evangelism" because it implies a more measured, thoughtful, and nuanced discussion. But I can appreciate the passion behind evangelism, and my speaking style has been compared favorably to a "pastor in the pulpit" more than once.
For most of my professional career, as an author, teacher, and speaker at software conferences, I've tried to focus on advocating free and open-source tech.
I like lending my voice and passion to projects that may not have large corporations behind them.
Geertjan Wielenga: But wouldn't you say that in the term "evangelism" there is something about enthusiasm that "advocacy" might be missing?
Scott Davis: Since I'm not being paid by a corporation to talk about its products, I definitely have an honest, heartfelt fire in the belly for what I choose to talk about.
The first time I spoke at the Great Indian Developer Summit in Bangalore, India, one of the attendees went up to the conference organizer after my talk and said, "I don't remember his name, but be sure to invite back the speaker who has hair like a lion!" I love that! Admittedly, I do roar about standards-based development and open-source solutions quite a bit; it's an apt comparison.
On a related note, it's interesting that what works well on stage (having an outsized personality and a booming speaking voice) works less well for pair programming. You don't want someone who is boisterous and loud as a partner; you want the power dynamic to be far more balanced. Ideally, you want to pair up with someone who listens more than they talk.
Geertjan Wielenga: Would you consider the term "spin doctor" to be applicable to you at all?
Scott Davis: We're really drawing a fine line here. I think developers, generally speaking, tend to be averse to that kind of marketing spiel. "Marketecture" is the unflattering portmanteau of "marketing" and "architecture" that we use to describe disingenuous tech solutions.
We've all heard stories about key architectural decisions being made between a sales rep and a vice president or chief technology officer (CTO), out on the golf course. True or not, when a tech stack isn't the right solution for the problem at hand, it simply doesn't smell right, and no amount of persuasion will convince you otherwise. It's not the job of the sales rep to point out a product's shortcomings.
"Once you lose that authenticity, it's really hard to win it back."
—Scott Davis
I think that, for developers, authenticity is really crucial to the message. I'm a long-time Apple fan, but I'm not an apologist. There was a recent scandal where Apple was accused of intentionally slowing down older legacy phones. The technologist in me can say, "Oh, so Apple is slowing down phones to protect against aging battery issues? That sounds plausible." The suspicious skeptic in me says, "No, Apple is slowing down older phones to make the latest model seem more appealing." The truth is probably some combination of the two, but once you lose that authenticity, it's really hard to win it back.
Geertjan Wielenga: Have you ever actually worked for a company and promoted its tech?
Scott Davis: I haven't. I've interviewed a number of times with a number of different companies for roles like that. I've had lots of opportunities to be a "product evangelist," to use that phrase.
One of the things I bring up in those interviews is "hey, are you okay with me saying good things about the competition? Are you okay with me talking about rough spots in our API or our product?" I think those questions are crucial to my credibility as an advocate.
Mostly, the response is "are you kidding me? No, you can't say nice things about the competition! No, you can't point out the shortcomings of our product!"
Not being able to speak honestly about a product would mean that I was failing as an advocate. Here's a hypothetical example: if I was a product evangelist for MongoDB, I would want to be able to say, "I really like MongoDB. I've been through the training. The software is good. It has great professional services and support, but it's purely a server-side solution. There isn't a solution if I want to keep some or all of the data local, like in a browser, or if I want to synchronize between multiple instances. It doesn't seem to have an "offline" story. In that case, I'd look to something like PouchDB or CouchDB. Now, if you don't need local synchronization, then MongoDB is a solid option. Let me show you some of the cool things it can do."
That, to me, doesn't feel like I'm being hard on MongoDB. I mean, if it's a feature that the software simply doesn't have, I feel it's important to address it and offer alternatives.
Geertjan Wielenga: What would you say are the advantages or disadvantages of being a developer advocate working for a company versus working for yourself?
Scott Davis: I ran ThirstyHead—my own software consultancy—for a decade before joining ThoughtWorks. What I enjoyed about working for myself was the freedom to talk authentically about the tech that was really exciting to me.
Thankfully, ThoughtWorks encourages me to continue talking about what I'm most passionate about. It doesn't exert any editorial control at all over what I say on stage or in my writing.
"The upsides to working for a large organization in a product advocacy role are that you get a steady paycheck and deep insider knowledge."
—Scott Davis
The upsides to working for a large organization in a product advocacy role are that you get a steady paycheck and deep insider knowledge. You can talk about the cool, new, upcoming features that no one else knows about.
Geertjan Wielenga: How did this all begin for you? If you go right back to the very beginning, was there anything in your family life or in your past that led you to where you are now?
Scott's path to advocacy
Scott Davis: Yes, absolutely. My parents met at IBM in the 1960s. My dad was a software engineer and my mother was an IBM Selectric (an early programmable typewriter) consultant.
I literally grew up surrounded by tech in the house—the first IBM PC came out while I was still in elementary school. My dad taught me how to put together spreadsheets, and my mother showed me how to crack open the computer case to add more RAM. I'm not sure that I could've ended up anywhere else than where I am right now, given the parents that I had.
Geertjan Wielenga: Initially, were you purely into programming?
Scott Davis: I actually started out studying architecture at the University of Nebraska. I was doing fine except for all of my architecture classes, so I dropped out for a year to figure out what I wanted to study next.
I got a job answering phones at a call center for a long-distance phone company. On my own, I put together a spreadsheet that had the names of the operators down one column and the days of the week across the top. I used this magical @sum function to total up the number of calls each operator answered every day. I showed it to my boss and it blew her away. I got into software development very quickly after that.
What I was doing at work wasn't sophisticated, but it was a real game changer in terms of what my boss had to do. Having software take those mundane, repetitive tasks out of your life really adds value.
When I went back to school, I ended up with a degree in Information Systems and Quantitative Analysis (ISQA)—half statistics and half software development.
Geertjan Wielenga: How did your career progress from there?
Scott Davis: My first job out of college was teaching software classes to business professionals. I started out teaching DOS classes—things like Lotus 1-2-3, WordPerfect, dBase, and Harvard Graphics. Not too long afterward, I started teaching classes for brand new Microsoft products like Windows 3.1, Word, Excel, PowerPoint, and Access.
As we installed networking in the classrooms, I got certified in Novell NetWare 3.11 and began teaching those classes. Over the next couple of years, I ended up with 15 Microsoft certifications in Windows NT 3.51 and 4.0, Exchange, SQL, TCP/IP, and Internet Information Server (IIS), the web server included with the operating system. That was in the early- to mid-1990s, when the first web browsers like Mosaic, Netscape Navigator, and Internet Explorer were introduced to the general public.
What teaching allowed me to do was take a deep dive into different, competing software packages in the same category. Each of those applications was stronger in certain areas and weaker in others. It gave me a more democratic view of software in general—there isn't "one ring to rule them all" when it comes to software. There isn't one true way to do things. There isn't one true programming language, or one true web framework, or even one true operating system.
Tech really is a world of strengths and weaknesses. Advocacy, I think, is where you honestly say, "If we balance out the pluses and the minuses, I'm going to send you down the path where there are more strengths than weaknesses. But I also want to make sure that you are aware of the sharp, pointy edges that might nick you along the way."
I spent eight years in the classroom as a software instructor and that has really informed my entire career. It's one thing to sit down and kind of understand how something works when you're cowboy coding on your own. It's another thing altogether when you're standing up in front of an audience of tens, or hundreds, or thousands of people.
Geertjan Wielenga: How did you get from that classroom setting where you were teaching Windows and DOS to being on these public stages?
Scott Davis: My mother, in addition to working for IBM, was also in theater. Thanks to her, I've been on the stage since I was five or six years old, so I've always had that confidence that comes from being a performer.
"I know my lines and the audience doesn't; it's not a fair fight."
—Scott Davis
It boils down to this: I know my lines and the audience doesn't; it's not a fair fight. They aren't going to know when I make a mistake unless I stumble. The audience is there for the performance, not for a line check of every last word and syllable. Honestly, they want you to succeed—they want to be entertained and informed.
A great stepping stone on your way to presenting on the "big stage" at professional software conferences is giving a talk at a local meetup or user group. I've spent over 20 years in the user group community.
I was the president of the Denver Java Users Group in the early 2000s, and after that I ran the Boulder Java Users Group for years. I just wrapped up the HTML5 Denver Meetup after running it for over a decade.
If you don't feel ready to give a 60-minute talk on a topic, look for lightning talks. They are typically only 10 minutes and 10 (or so) slides. It is literally just long enough to say, "Hey, have you heard of this framework? Here's how you install it, and here's a quick 'Hello, World!' example." But in that quick 10 minutes, you still have the basic elements of an effective 60 minute talk: introduce the topic, pique the audience's curiosity, and give them enough to explore it further after the talk.
Geertjan Wielenga: How did you get to an international stage? What was that process?
Scott Davis: It was through the Denver Java Users Group. I started attending that and then thought, "There are a lot of really great advanced talks here, but could we have a series of talks that would be a gentler introduction to Java?"
Starting a "Basic Concepts" series of talks at the Denver Java Users Group led to a writing opportunity—my first book, JBoss at Work. Then, as an author, you start getting invited to local and regional software conferences. From there, it grew to national conferences within the U.S., and later, I was able to broaden out to the international stage.
Geertjan Wielenga: Developer advocacy isn't a common career path. Why is this?
Getting up on stage
Scott Davis: Public speaking continues to be one of the number one fears that many people have. There's that common nightmare where you're standing up in front of your classmates at school giving a report and, all of a sudden, you're naked or you've forgotten what you wanted to say next. It takes a real act of courage to stand up and present yourself as an authority, especially to a group of your peers.
On the flip side, I really try to be mindful about not appearing arrogant. I try to turn each presentation about software into a personal journey—a "hero's journey" if you're familiar with the literary concept. I don't want to stand up and say, "I know this and you don't, so why don't you sit back and listen to me talk about how much I know." I like standing up and saying, "Hey, I'm a Java developer and I just discovered this new language, Groovy. Let me show you what I've learned so far."
"No one can call you a liar for sharing your personal experience."
—Scott Davis
It's fantastic being able to come from a very personal place to say, "This appeals to me and let me tell you why." It's the best cure for imposter syndrome I know of because you're talking about your journey and your experience with the software. No one can call you a liar for sharing your personal experience.
Even if being on the stage holds no appeal for you, you can still contribute to the conversation through writing blog posts or an article series; starting a podcast or screencasts; or even posting code to a public Git repository. These are all low- or no-cost ways for you to find your voice and share it with the public. You don't need to ask permission—just do it!
Geertjan Wielenga: Would you say that you need to be a complete expert on a particular tech or on a topic before you can be a speaker or author in this developer advocacy domain?
Scott Davis: Getting back to that voice of authenticity, I tend to enjoy blog entries and articles where people are very honest about what they struggle with. In that way, the writer says, "This is a concept that really didn't make sense to me at first, but here was my breakthrough moment."
I had an experience like that most recently when dealing with RxJS, a reactive library for JavaScript. It wasn't the syntax that I was struggling with: it was the underlying concepts, the reactive/declarative mindset, and the worldview, if you will. I've been dipped in imperative programming my whole life, so I was really struggling to get into that reactive mindset. But once it happened, that lightbulb went on and I thought, "Oh, now I get it!" It was like staring at that duck/rabbit optical illusion and finally being able to see the rabbit.
Now when I'm giving presentations on RxJS (or reactive programming in general), I always tell that story. It humanizes me and more than a few people in the audience are probably fighting that very same battle.
I give an imperative example and then a declarative one right afterward: "See how the declarative example is doing the same thing in far less code? That's the rabbit I was telling you about!" That's the "hero's journey" in a nutshell right there. It's not the solution alone that's important: it's the journey leading up to the solution as well.
Geertjan Wielenga: What are some things that you wish you had known at the start of your career, especially as an advocate?
Scott Davis: My little brother also went into software as a career. Just as he was getting ready to graduate from college, one of his professors said, "There's a good chance that you're never going to use the programming languages that you learned here in class out in the real world."
It's true! I had two semesters of COBOL in school and never once got a paying gig writing COBOL after graduation. The idea that you can learn a single language that will carry you through to the end of your career is probably setting you up for a lot of heartache and disappointment. You have to be prepared to be constantly learning, constantly adjusting, and constantly evolving over time. You need to be prepared to be a polyglot programmer, which is Greek for "many tongues" or many languages.
When I call a plumber, they don't show up with a single wrench in hand and ask, "Okay, where's the leak?" They show up with a whole truck full of tools, some of which might only be used once or twice a year. But when the job calls for a specific tool, that plumber is prepared to use the best tool for the job.
Geertjan Wielenga: What have you been advocating recently? I've seen you talking about conversational user interfaces (UIs) and responsive progressive web apps. How do you choose which tech to advocate?
Scott's hot topics
Scott Davis: The iPhone is now over a decade old. I vividly remember when it came out thinking, "Wow, this is a game-changer: a full-fidelity web browser in my pocket!" That was before the App Store was even a glimmer in Apple's eye.
That was also the timeframe when Google Maps was first released. I was working on a pre-release version of Google Maps for a satellite imaging company, and I could viscerally feel how AJAX-based websites changed the whole user experience for the better. The iPhone and Google Maps forever changed the way we do web development.
"You can actually use your voice to communicate with the device in your hand in a meaningful way."
—Scott Davis
I'm feeling that same way right now about conversational UIs. We're hearing devices actually speak to us in realistic voices, not like the primitive chatbots of the past that used robotic speech synthesis like Stephen Hawking or in the movie WarGames. You can actually use your voice to communicate with the device in your hand in a meaningful way. We're seeing this show up on our smartphones, on our watches, and even on our television remote controls.
I used to laboriously tap out Breaking Bad one letter at a time on an onscreen keyboard using the left/right/up/down arrows on the remote. Now I hold up my remote control and say, "Breaking Bad."
I really feel that conversational UIs have got to the place now where the software, hardware, and bandwidth are all there. It's that perfect storm where it's all come together. This idea of talking to computers is really breaking down barriers once again. There's something very natural about walking in and talking to a computer. I'm really fascinated by that.
Where this really shines is when we start talking about accessibility. I walk into the kitchen in the morning and say, "Hey Alexa, play some Bob Marley." It's a novelty for me, but imagine if I had low vision or full blindness. All of a sudden, it's not a novelty—it's my whole user experience.
In both the U.S. and worldwide, the literacy rate is only about 85%. For 15% of the world, a conversational UI is their whole user experience. If you have dyslexia or another cognitive impairment that makes reading hard, conversational UIs can help. If English is your second language, perhaps it's easier to hear it than read it. Heck, if you're driving or have a baby in your arms, a conversational UI can make your life easier.
We're on the cusp of the "next big thing" with conversational UIs, and I'm having a blast exploring all of the possibilities.
Geertjan Wielenga: How do you stay up to date and in touch with the latest tech developments?
Scott Davis: I read incessantly. I think the biggest sources for me are my Twitter feed and going on websites like Ars Technica, A List Apart, Wired, TechCrunch, and the like.
When you visit those different sites and see the same story told from different perspectives, you really begin to see the trends emerge.
You have to have a love of learning. I get itchy and do everything I can to not get bored from a tech perspective. I'm like a shark that has to keep swimming to stay alive. Much of that motivation has to come from within.
"Find a job that lets you do what you love."
—Scott Davis
What can make that hard is when the tech that interests you is not what you're working with for your day job. So, in an ideal world, you have to find a tech that you love and then find a job that lets you do what you love. I think that's the perfect model.
Moving away from pure programming
Geertjan Wielenga: What would you say is the advantage of developer advocacy over spending your life being a pure computer programmer?
Scott Davis: Look, not everyone needs to be an advocate. I've got lots of friends whose real passion is rock climbing or snowboarding. For them, programming is an interesting, exciting, and innovative job, but more importantly, it's a well-paying job; it's something they do as a means to an end.
For me, I've got Alexa at home in several rooms. My family members all have iPads and iPhones. My advocacy, once again, comes from a place of authenticity—this is how we live; we live these digital lives.
My iPad is the first thing I see when I wake up in the morning and it's the last thing I see when I go to bed at night. A device, to me, is not just a computer that you sit down at and walk away from—it's something that you develop a kind of relationship with.
In terms of advocacy, it should be personal. You should be talking about something that you're passionate about. Advocacy is something that you feel compelled to do. You're almost not choosing the tech: the tech is choosing you and you can't help talking about it. If you can find something like that, then it's easy because you're doing what you love.
Geertjan Wielenga: You travel frequently and you come across developer advocates everywhere. What would you say are some commonalities among them?
Scott Davis: What I love most about going to software conferences is meeting the other speakers. I love sitting down at the end of the day and having a drink with them or waking up in the morning and having coffee and a masala dosa with them.
There is something about being a conference speaker that draws us all together, regardless of the language we speak, the company we're working for, or our platform of choice. I love hearing iPhone developers talk passionately about Objective-C and Swift, and I love hearing Android developers talk passionately about Java and Kotlin.
"I'm attracted to passion. Honestly, the particular focus of that passion is less important to me."
—Scott Davis
I'm attracted to passion. Honestly, the particular focus of that passion is less important to me. I just love hearing someone else be really passionate about something they love; it makes for great conversation.
Geertjan Wielenga: Have you been in situations where your audience or a client was more knowledgeable? How did you handle that?
Scott Davis: You just described the life of a consultant! I find myself in that situation all the time, whether it's in the classroom or on a new software project. I try to establish some ground rules early on to help to nip it in the bud.
For example, if I come into a pharmaceutical company, I say, "Hey, you know much more about pharmaceuticals than I do, but I know a thing or two about software development. Let's sit down together. You have an idea of what you want the app to do. I have the software skills to help translate your vision into running software and make it come to life." So, rather than setting up an adversarial relationship from the start, I try to respect and acknowledge their strengths. In turn, hopefully, I give them a way to respect my strengths as well.
Geertjan Wielenga: In the life of a conference speaker, technical glitches happen all the time up on stage. How can they be avoided and how do you react to these situations?
When technical glitches hit
Scott Davis: Resiliency is something we always talk about in software. I think resiliency is something you have to strive for as an instructor or as a conference speaker.
It's not avoiding technical glitches that makes you a pro: it's the grace and humor you use in reacting to the glitches when they inevitably happen. I've had a number of people come up to me after a talk that went badly and say, "I'm sorry that you had trouble up there on stage, but I probably learned more from watching you debug it in real time than if everything had gone right in the first place."
Nowadays, I take a screenshot of every website that I'm going to mention in my presentation and put it in my slides with a hyperlink. If I'm at a conference with good Wi-Fi, then I can click on the screenshot and seamlessly scroll around the live website as I talk about it.
If, on the other hand, I end up in a hotel conference room in the basement with crummy Wi-Fi, then I just discuss the static screenshots in my slide deck. I never apologize for not having a live Internet connection—that's part of the theater experience. You silently adapt to the presence or absence of good bandwidth, and the audience never knows the difference.
I love to give live coding examples in my presentations, but I always have a working, finished copy of the example saved in a parallel directory. If I get stage-blind and can't find the bug while I'm live coding, I don't spin my wheels for too long. I say, "Okay, let me show you what I was trying to demonstrate here." I then pull up the working code and make some trivial edit, like changing "Denver" to "Frankfurt" or "Oslo" (wherever I happen to be at the time), which gives the illusion of live coding.
I might then take that working code and purposely insert a syntax error to illustrate a point: "See how easy it is to miss a semicolon here? Let's look at the error message so that when you find yourself in a similar situation back at the office, it won't be nearly as scary."
Geertjan Wielenga: What about the laptop-not-connecting-to-the-projector scenario? What then?
Scott Davis: Years ago, I did all of my presentations in PowerPoint. Later, I graduated to Keynote. PowerPoint was, for better or worse, the least common denominator. It was something you could assume would be available if your personal laptop wouldn't work with the audio/visual setup at the conference.
Sadly, most of my legacy presentations are now trapped in an outdated, proprietary nut that is harder to crack than you might think. Apple and Microsoft are far less concerned about backward compatibility and legacy support than I am, apparently.
What I've started doing now is writing all of my slides in HTML and posting them on the web. I call it "Talk-o-Vision." It's pure HTML5, CSS, and JavaScript, with zero external dependencies. Just as every Jedi must build their own light saber, as a professional presenter, I take great pride in building my own slide decks from standards-based tech that should stand the test of time.
As a result, if I get into a conference situation where my laptop won't connect, I know that any device with a browser and an Internet connection will allow me to pull up my slides and proceed.
If the overhead projector isn't working, that's an entirely different kind of problem. You can laugh about it and offer to do an interpretive dance in lieu of your prepared slides!
Not having a projector is a more difficult challenge to overcome, but if your slides are publicly available on the web, everyone in the session could still potentially pull them up on their own device and you could proceed with the presentation.
Geertjan Wielenga: How do you deal with the whole area of jet lag, missed flights, and the typical problems of the world traveler?
Travel management tips
Scott Davis: I optimize less. I used to be really aggressive about it, saying, "Alright, my first talk is Monday morning at 9 a.m. I'm going to get in on Sunday at midnight because that is the least amount of time I need."
Unfortunately, that strategy doesn't leave any margin for error, as all professional travelers learn. Nowadays, I try to give myself a full 24 hour buffer coming in.
When traveling to India from the U.S., that 24 hour buffer is almost a requirement. There's a 12 and a half hour time difference between the two countries and around 18 hours of flight time depending on how many hops it takes to get there. At that point, night is day, left is right, and up is down. That kind of time shift can be brutal if you don't anticipate it and make accommodations.
"Trying to live in one time zone while being physically located in another is a recipe for disaster."
—Scott Davis
Whether I'm traveling across the world or just to one of the coasts in the U.S., what helps me best adjust to the new time zone is simply eating breakfast when the clock on the wall tells me I should, instead of when my internal clock tells me I should. Trying to live in one time zone while being physically located in another is a recipe for disaster. If I can get one solid "wake up when the sun comes up, go to bed when the sun goes down" cycle in, that's typically enough to get me through the next day of presentations.
Geertjan Wielenga: With these topics we're discussing now, coupled with the passion of this profession, do you think that there's a risk of burnout?
Scott Davis: Sustainability is a really important topic that we don't often talk about. Here's one way to think about it: an introvert is someone who can interact with other people—and maybe even enjoy it—but it drains their battery. It's crucial that they get some quiet/alone time to recharge.
I know a number of conference speakers who have this great, outgoing stage persona, but they self-identify as introverts. They are absolutely wrecked once they get off the stage and need time to recuperate.
I'm an extrovert, so I find that being on stage is what actually charges my battery. If I haven't been on stage in a while, if I'm not giving presentations, wildly gesticulating with my hands, or talking loudly and passionately about something, that drains my battery. I almost always come off the stage with more energy than when I started.
Whichever camp you fall into, be sure that you take care of yourself. It's far too easy to plan for your presentation and forget to plan for your recovery.
Geertjan Wielenga: When you're at a party or speaking to people who are not at all in the tech field, how do you explain what you do?
Scott Davis: Rather than saying, "I do responsive web design," "I write progressive web apps," or "I'm really into offline-first web development," I say, "I make sure that websites look good on your iPhone or Android."
I might also ask, "Have you heard of Alexa? Have you heard of Siri? Cortana? That's what I do: I do conversational UIs. I do my best to make sure that your devices make sense when they talk to you."
"Put yourself in the shoes of your end users."
—Scott Davis
I think that it's far too easy for us to focus on the tools we use rather than the people who use our apps. Step one in design thinking is "empathy"—put yourself in the shoes of your end users for a moment and view your app through their eyes. I'm fairly sure that if you ask a typical software developer what step one is, they'll say, "Download a framework or set up a code repository."
Mozart wrote symphonies. If you asked him what he did for a living, I doubt that he would have said, "I write notes on a musical staff with a quill pen."
Many times, when I'm talking to a customs agent or someone in passport control, saying that I'm an author helps. I'll say, "I'm speaking at a software conference about this book that I've written." It establishes what you do in a common language that everyone understands.
Geertjan Wielenga: What talks are you working on right now?
Scott Davis: I'm working on a keynote called "The Ship of Theseus." It's an ancient Greek paradox about a wooden ship that belonged to one of the first kings of Athens.
Theseus sailed over to the island of Crete and killed a vicious monster called the Minotaur. When he returned, the citizens of Athens preserved his ship out in the harbor as a memorial to this momentous victory. Every year, they'd take Theseus' ship out for a victory lap to commemorate the event. According to the story, this went on for centuries after Theseus' death.
Here's the paradox: as you'd expect, various wooden parts of the ship rotted away over years. The citizens of Athens dutifully kept the ship in working order, replacing all of the parts necessary to keep the vessel seaworthy. Therein lies the question: since the ship was no longer made up of the original wood from Theseus' time, was it still truly Theseus' ship? If not, when did it cease being Theseus' ship? Is there a specific percentage, threshold, or milestone that we can point to and say, "There! Right there! That's when this thing technically stopped being the Ship of Theseus."?
Isn't that a lovely thought experiment? It really forces you to consider what the true essence of something is versus the raw materials used to build it. What a perfect metaphor for web development!
If you did an archeological dig on my website, you'd find 30 years of then-current, now-abandoned web technologies: ASP pages; JSP pages; Prototype and Scriptaculous; Groovy and Grails; jQuery; Backbone; Angular; Node.js; and Express. And yet, despite all of that churn, not once have I ever considered it anything other than "my website."
When you ask a typical web developer what they do, they'll often say, "I'm a React developer. I'm an Angular developer. I'm a VueJS developer." As far as I'm concerned, that's like saying, "I'm a spoon chef," or "I'm a hammer carpenter."
These tools that feel so important to us right now—that define us—are, in fact, ephemeral. The average lifespan of a website's design is typically less than two or three years. So, all of our efforts are spent on the surface of the water, being buffeted by the waves and dodging the flotsam and jetsam of last year's "gotta-have-it" framework.
Did you know that the original web page that Tim Berners-Lee published is still available on the web today? It still renders in 100% of modern browsers. Talk about the Ship of Theseus, right?
This is why I'm really focusing my efforts these days on standards-based techs like HTML, CSS, and JavaScript. Their longevity is measured in decades, not years or months. The deeper you go into the water, the slower the currents run, and the longer you can reap the benefits of your return on investment.
Geertjan Wielenga: We've established that you're not a traditional developer advocate, but you do promote particular techs. There's a whole range of people who one year are promoting tech A and then a couple of years later are promoting tech B. How do you feel about that? Should we look kindly upon that and be forgiving or be harsh and questioning?
Changing your mind about tech
Scott Davis: I think that it's important to be able to change your mind professionally. You have to ensure that you never get so dug into a position that you can't back out or make an opposing argument later.
One thing that I try to do, whenever I'm advocating a tech, is point out its shortcomings as well as its strengths. That kind of balanced approach is what I look for in conference speakers too. If they aren't able to say one nice thing about another tech, or one bad thing about their own, that's when I get suspicious and my spidey senses start tingling.
Neal Ford popularized the "Suck/Rock Dichotomy." This is when people say, "This framework is the best thing ever! That framework is the worst thing ever! Mine rocks! Yours sucks!"
"Since we're programmers, it's easy to slip into a purely binary mindset: 1 or 0, true or false, black or white, good or bad, and so on."
—Scott Davis
Since we're programmers, it's easy to slip into a purely binary mindset: 1 or 0, true or false, black or white, good or bad, and so on.
The real world, of course, is a wee bit more nuanced than that. I like reminding developers who use the binary argument as a rhetorical crutch that it takes 8 bits to make a byte. Every single character that you type on the screen is a healthy mix of 1s and 0s.
Geertjan Wielenga: Thank you, Scott Davis.
