Camunda has always been developer-friendly. When I joined on November 1st, 2020, it was right on the homepage.

This, among many other things, made Camunda a no-brainer for me to join the Developer Relations team as the Head of Developer Experience and build out Camunda’s first Developer Experience team, focusing on developer enablement under Mary Thengvall’s 3 pillar Developer Relations program—awareness (developer advocacy), engagement (community), enablement (developer experience). There was no need to “sell” the company on the value of developer-friendliness. Being developer-friendly was already deeply ingrained in the company culture.

I made our first hire almost immediately, our first Technical Community Builder, and got to work getting the Zeebe docs crafted into the Camunda Cloud docs, which you know now as the Camunda 8 docs. We were on our way to live our team mission:

Developer Experience (DevEx) focuses on external developer enablement for products through documentation and product-adjacent tools at Camunda.

Our mission is to lower barriers for all developers working programmatically in and around the Camunda ecosystem to get what they need to be effective with Camunda efficiently.

Who we are

We are a group of highly empathetic, opinionated, independent people, past and present. Maybe you’ll recognize our GitHub handles:

  • celanthe, former Technical Community Builder
  • christinaausley, Technical Writer
  • pepopowitz, Developer Experience Engineer
  • xomiamoore, Senior Technical Community Builder (now part of Camunda DevRel)
  • jwulf, Developer Experience Engineer (former Developer Advocate in Camunda DevRel)
  • 1nb0und, Senior Developer Experience Engineer
  • akeller, Engineering Manager, Developer Experience (your blog author)

I am so thankful for each and every one of these people and their contributions to our Developer Experience team. I’m proud of our accomplishments. You are the artisanal crafters of the Camunda developer experience.

What we work on

We do a lot of glue work—reducing friction and increasing productivity, internally and externally. Most of the feedback we hear is negative, par for the course. Most people don’t enjoy friction, particularly developers.

There is always room to improve and evolve, so while we can’t promise to fix or update things immediately, know that we hear you and have it in our backlog. As Daniel Meyer says, Always Progress.

Sometimes, the work is… not so glamorous, but there is power in the quiet moments. No feedback is sometimes the best feedback! It just works. And that’s the sign of a good experience—intuitive, seamless, and gets the job done.

I’ll spare you all the details (we mostly work in public, so you are welcome to find those details if you wish), but let’s hit some highlights, past and present, and future projects with this notable project list:

  • Hired Camunda’s first Technical Community Builder
  • Launched the Camunda Community Hub
  • Hired Camunda’s first Technical Writer
  • Consolidated the forums
  • Co-created the Camunda Writing Style Guide, in partnership with Marketing Communications
  • Hired Camunda’s first DevEx Engineer
  • Launched the Writing Center of Excellence
  • Supported each and every product release and everything in between
  • Moved from DevRel to Engineering
  • Introduced formatting and linting, like prettier and vale, to our docs workflow to make authoring and maintenance easier
  • Fixed many-years-long-degraded Camunda 7 SEO issues, impacting search
  • Building out fully supported SDKs in priority languages, launching in April 2023

I drew inspiration from Sarah Drasner’s Developer Experience Team at Netlify, mixing documentation and integration engineers, so for the foreseeable future, the team is focused on documentation and post-API experiences (API reference, clients, and SDKs)—all the pieces developers need to just work while they focus on their solution or problem domain.

Coming Soon—SDKs!

It’s simply impossible for me to write a blog without a shameless plug, so here we go!

Camunda 8 is a polyglot-enabled product. We offer public APIs to our core components, and in any language you can call a third-party API, you can call Camunda 8.

We’ve heard from customers and community members alike that you have three priority languages you’d like to see fully supported—Java (Spring), Node.js, and C#/.NET. So we are going to make that happen.

1nb0und and jwulf are working on bringing this to reality, working on Java (Spring) and Node.js, respectively. You can follow their progress on the Camunda Community Hub before they move into the Camunda org. For more on the Node.js SDK, check out this blog post from jwulf.

How can we make it easier to work with Camunda programmatically? How can we enable you and your development team? Let us know in the forum.

How far we’ve come

Our enablement journey started with documentation and contributor experience. In our first year, we launched the Camunda Community Hub, co-locating many of our community-supported projects into one space, and brought a dedicated focus to technical writing.

In May 2021, we launched Camunda Cloud and were excited to see 20… wait (!!) 220… users hitting the docs site. We were officially live! Fast forward to today, we have thousands of users a day (just call us 10x developers!).

We see a significant decrease in traffic on the weekends, which we love because that means you are (hopefully) enjoying some time away from your computer.

As of writing this, we have over 5.6 million page views across our docs site.

On Oct 2nd, 2023, I received an unsolicited DM from christinaausley with the following stats:

2021: 284 contributions from you and 189 from me = 473 contributions
2022: 708 from you and 755 from me = 1,463 contributions
2023: 796 from you and 827 from me = 1,623 contributions (and we still have an entire quarter left in the year!!)

Since I started at Camunda, that’s about 3500 contributions between the two of us.

“I should do less IC work,” I thought.

This is basically 3000 contributions stress testing the documentation infrastructure and contributor/authoring experience pepopowitz works so hard to nurture. Two large renaming projects, multiple massive restructuring projects, countless relocated docs pages, an unimaginable number of failed builds, and more.

While numbers are vanity metrics, not measures of success, it’s certainly a great opportunity to reflect on where we started. Maybe you were one of the 20 original users we welcomed to the docs!

How you can help us, help you!

From low code to pro code, Camunda’s developer persona is an enormous spectrum, and in the documentation space, we can’t just limit our focus to developers. Documentation is for every persona our product touches! SDKs, however, are a little more specific.

If something doesn’t work as you would expect it, let us know. We work closely with other engineering teams, product management, support, DevRel, and other teams to triage bugs, feature requests, and anything else that is raised. A great place to start is the forum.

We accept issues and PRs for our documentation on docs.camunda.io. We have /next/ as a preview of our next minor version, including alphas and in-flight work.

The DevEx team is also present in the Camunda Community Hub, transforming those existing community-supported clients into the fully-supported SDKs I mentioned earlier. These projects will eventually move into the Camunda GitHub org, but we’ll likely continue accepting issues and PRs.

Consider it a challenge to reach out and say hi in the Camunda forum now that you know who we are and what we are working on!

Happy 3rd Birthday (or Anniversary!) DevEx—may the docs page views be abundant, feedback actionable, errors meaningful, and Always Progress.

Ready to get started?

Still have questions?