I just finished attending DevXcon in San Francisco at the beginning of the week before last. It’s the way the DataStax crew welcomed me into the family. It was a solidly awesome time, a great way to get started, and I’ve rated it “would do again!” Tamao (@mewzherder), Matthew (@matthewrevell), and fellow organizers did a great job putting things together!
The DevXcon is kidn of a sibling or parallel of sorts to the DevRelCon presented by Github. These events are organized by Hoopy, a consultancy of Matthew’s that specializes in helping companies around developer relations and marketing. Both of these conferences focus around this, the developer relations of software companies and how to improve that relationship companies have with their prospective developers.
UX Practices for Developers
This DevXcon a big focus of the event was on and around user experience (UX) practices. I found it interesting this was brought up in this context. User experience being a key practice of any good application, CLI or API end point, web interface, or physically the interaction in using devices, or even a weed wacker for that matter is really unquestionable. If a company designs poor interfaces, their products will suffer at market or in the case of an ongoing user experience fail, injure the person using the device.
Other Topics Around Relations
The conference had a range of topics covered, including; working with email newsletters that developers actually want to receive, DevRel’s role in product feedback, and others. I’m going to skip that and point you instead to check out Adam Duvander’s write up “DevXcon SF 2018: where UX, DX, and product came together with dev rel“.
DevRel, the practice of effectively coordinating, creating, and building content, coding, and communicating the benefits of products and services of a company, and open source project, or other organization has grown into something a bit more than merely marketing. Even though much of the work of DevRel could fall into the marketing category if by no means fits into that realm, but more closely – when effective – to engineering, support, and the technical side of the spectrum.
The biggest issues I see are the age old problem of maintaining integrity and reputation in the industry once moving into DevRel from engineering. It’s a difficult step when one has engineering or related work experience their reputation is built on and then delves into DevRel. The myth goes that we aren’t developing anymore, that we lose our coding chops. But seriously, good DevRel build products, services, and expands on what they’re advocating and showing to their respective community just as engineering is building that product or service. Good, emphasis on good, DevRel teams advocate, code, and build still, which is fundamental in my opinion to building a solid community base around any project, product, or service offering.
Advances for DevRel, Advocacy Not Evangelism
It does appear, as seen with many groups, at least we’re frequently starting to drop the misnomer title of Evangelist and pushing toward titles like Advocate, such as Microsoft has done with their Cloud Developer Advocates (or CDAs as they call them in short, because Microsoft gotta TLA like they’ve always TLA’ed). Their focus has always been on their ecosystem, etc, but they’ve refocused around a wide spectrum of tooling, many times tooling that isn’t even from Microsoft. This refocus around an advocacy approach versus and evangelism approach is a pretty big deal, especially for the end user. It’s a positive reflection that DevRel as a working group in companies is moving in a positive direction to benefit the community that uses the products and services of an organization.
Anyway, that’s just a quick summary, more on many of these topics in the future. For now, happy coding, conferencing, and cheers!
