If you’re in Paris this coming Monday night, please join us at Unpacking Developer Experience. A panel discussion hosted by the team at Five by Five, we will be exploring the ideas and increasing focus of the developer as a user. That’s right devs, it’s our time to shine as technical end-users in as much detail as a traditional customer segment.
I’ll be joining and David Zuckerman (Head of Developer Experience at Wix) for a discussion Moderated by Alex Poole (Senior UX Strategist at Five by Five). Check out the Eventbrite listing and please feel free to tweet me or the team (or email) to introduce yourself before (or after) if you’re coming along.
You mean that 1980’s Synthesiser?
No, we don’t mean DX but DX! And why this is an interesting topic to our whole team here at Corilla is no great mystery. I can simply say that good developer experience is utterly reliant on good documentation. This is obvious for anyone that has ever put cursor to command line, and recent news like Stack Overflow’s Warlord’s of Documentation announcement show we’re not alone.
Why this is “new” enough to earn a topic of discussion and debate is something we will dig into on the night. But let’s just say that working in open source at a company like Red Hat forces you to observe exactly how fast we’ve evolved from standing on the shoulders of giants (remember inputting programs from pages of a magazine?) to standing on the platforms of giants (hello, APIs). And that’s without even previewing the incredible diversity of what we do as developers, plus what we’ve learned about the ways we learn and the cognition involved in doing those things at scale.
And in comes the API
In many of these conversations, the rise of the API is a fascinating focal point. I really like how some documentation companies focus on APIs. A few are even betting the farm on developer documentation as a subset of the developer’s experience working around an API. Automation and a realtime connection to both maintenance and unit testing are the holy grails – if unrealised. I can’t wait to see how they tackle this and look forward to using it myself.
How we approach the documentation side of developer experience is the collaborative workflow in generating that content across the full range of stakeholders. That includes technical writers, developers, QE and product managers. Having worked all of these roles, we know those experiences very well, and reducing the complexity and cognitive load of them is utterly essential before we can tackle the REALLY interesting stuff like what’s we’re doing with machine learning. But what’s the point of the long view aspirations if we’re still so frustrated by the tools at hand?
All of this just simply can’t be done in isolation for the kinds of advanced content customers that we work with (and spoiler alert: technical writers do indeed hate the tools they are so often forced to use). I often wonder if that’s the biggest differentiator between Corilla and some of the developer-specific documentation companies. We’re not building to an end-point, but a critical path. Under this lens, DX gets even more important to champion lest it be downplayed under customer-only UX methodologies. And being open source, the community will sure let us know if we stray off that path.
Come eat some croissants
We’ll explore these topics with better clarity and depth than a single post here (haha, trust me), but I’ll also capture a summary in a post afterwards. And again, if you’re in the region, stop on by. While we have some experience on this topic, it’s the other David and Alex that will be dropping science. And for the record, no, I don’t know if there will be croissants, but there will be a fascinating night of conversation.