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.