Book Image

Developer, Advocate!

By : Geertjan Wielenga
Book Image

Developer, Advocate!

By: Geertjan Wielenga

Overview of this book

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.
Table of Contents (36 chapters)
34
Other Books You May Enjoy
35
Index
36
Packt

Honesty when doing a demo

Geertjan Wielenga: If you're doing a session and you're doing a demo, do you avoid the areas that you know don't quite work the way they should, or do you talk about that very openly?

Ray Tsang: I think it's important to talk about things that don't work well. I always add in a caveat if something's not production-ready, for example, because we've got to make that clear.

I think it's very important to call all things out: saying what works and doesn't work. I try to do that as much as I can. I may say, "Don't use that for now." Say, for example, that we're talking about databases. If you have object-relational mapping, you have these complicated graphs of objects relating to each other. Is it right to always use those things? It depends on the use case. So rather than saying yes or no, when I get the time, I want to make sure I understand what the use case is and figure out if it's something that...